CVE-2025-61624: Fortinet Path Traversal and the PEERSTITCH Intrusion

CVE-2025-61624 is a Fortinet path traversal vulnerability that turns an existing administrative foothold into a more powerful file-access capability. Its relevance to the PEERSTITCH intrusion is the boundary it crosses: permission to administer an appliance through its supported interface does not automatically confer permission to modify arbitrary operating-system files. Treating those privileges as equivalent misses the security failure.

The immediate decisions are which product branches need correction, whether the management plane has been compromised, and what evidence can support recovery. Those questions require different records. A firmware upgrade can address vulnerable code; a clean disk scan cannot establish that process memory was clean before the upgrade, and a stolen configuration does not by itself prove that every managed customer network was breached.

Why this older CVE is receiving renewed attention

En Fortinet CNA record for CVE-2025-61624 was published on April 14, 2026. It describes arbitrary file write and deletion through CLI path traversal, requiring an authenticated administrative profile with at least read-write permissions. CISA’s enrichment in that same record records a Known Exploited Vulnerabilities addition on October 16. The newer attention should not be presented as a newly discovered unauthenticated firewall entry point.

Exploitation was already acknowledged earlier: the April 15 CERT-FR advisory says Fortinet reported exploitation of this vulnerability. That timeline distinguishes public disclosure, recognition of exploitation, and later technical reporting. A CVE’s year, its publication date, and the date a detailed intrusion analysis appears are not interchangeable.

The new technical context comes from Unit 42’s PEERSTITCH investigation. The researchers describe a September 2024 intrusion at a telecommunications managed service provider. Initial access involved the separate FortiManager vulnerability CVE-2024-47575. CVE-2025-61624 subsequently helped cross the restricted administrative CLI boundary on FortiGate devices. Keeping those stages separate prevents a misleading claim that this path traversal alone provided the initial unauthenticated access.

For incident prioritization, the meaningful connection is an attacker’s ability to combine access paths. A vulnerability requiring administrative permissions may be less accessible to a random internet visitor, but highly useful after a management service has been compromised. The prerequisite reduces the set of attackers who can use the flaw directly. It does not reduce the importance of the boundary once that prerequisite is satisfied.

Administrative control is not unrestricted root control

An appliance CLI is a mediated interface. Its commands are supposed to express a bounded set of configuration operations, even when the user can change powerful settings. An arbitrary file operation crosses into a different authority domain: the underlying filesystem and the software that depends on it. That distinction is useful when reviewing both the vulnerability and the response plan.

Consider the difference between changing a permitted configuration value and choosing a file outside the intended storage area. The former may be within an administrative role’s design. The latter can affect resources that the role was never intended to control. Path traversal matters because the application’s interpretation of a path can escape the boundary that its authorization model assumes. This explanation describes the security property; it is not a claim about an undisclosed payload or an instruction to reproduce it on a live appliance.

The response should examine each boundary independently. Who could reach the management plane? Which identities had the required rights? Which changes were accepted through the supported interface? Was there evidence of activity below that interface? A successful login only establishes one step in that sequence. It cannot explain every action attributed to the appliance afterward.

This also changes how “trusted administrator” is used in risk discussions. Administrators can make mistakes, their sessions can be stolen, and a management server may hold access to many devices. A product’s privilege boundaries still matter under those conditions. If the response assumes that an administrative account already implies total operating-system compromise, it becomes impossible to recognize or verify the boundary that the patch is supposed to restore.

Build the patch inventory by product and branch

En CNA remediation section lists the following fixed release targets. This is a selected matrix of explicitly named upgrade destinations, not a complete list of affected older branches. Check the record and current vendor guidance for the exact product, hardware, support status, and supported upgrade path before scheduling a change.

Do not infer that an unlisted branch is safe. The record includes affected older releases beyond the branches summarized here. A missing fixed target in a short operational table means that a supported migration decision is required, not that the vulnerability disappears. Similarly, a numerically larger version from another branch is not evidence that it is a valid upgrade destination for a particular appliance.

An actionable inventory needs more than firmware strings. Bind each row to the product, device identity, role, management owner, and configuration source. Include standby or replacement devices that can return to service with an older image. For clustered deployments, verify every member using the supported management procedure; a single management view can conceal an incomplete rollout if the operator records only the first successful result.

Plan how configuration will be restored and reviewed before the maintenance window. A correct image does not make every imported setting trustworthy. If the management plane is suspect, configuration provenance becomes part of recovery: which backup predates the suspected activity, which changes were legitimate, and which credentials it contains. Those questions deserve an owner before restoration becomes urgent.

What PEERSTITCH changes about the evidence search

Unit 42 describes PEERSTITCH as an ARM64 memory-resident implant operating within legitimate FortiOS processes. The reported implementation did not depend on its own persistent binary, a new listening socket, or a separate outbound communications channel. The report supplies indicators and YARA material, but those artifacts must be interpreted in the context of the data actually collected.

A disk-only scan answers whether the scanned files match the signatures used. It cannot establish that no malicious code was present in process memory earlier. Likewise, finding no new listener has limited value against an implant whose reported behavior did not require one. These are measurement limits, not reasons to abandon detection. They explain why an investigation needs multiple evidence types and a clear account of what each can observe.

The table is a defensive evidence model derived from the reported behavior, not a universal PEERSTITCH detector. The correct use of a published indicator depends on its scope: what object it matches, whether the collector can acquire that object, and whether the relevant activity was still present at acquisition time. A tool’s “no findings” message should retain those conditions when it enters the incident record.

Memory collection and low-level appliance inspection should follow vendor-supported or specialist forensic procedures. Unplanned debugging or a reboot can change the state being investigated. Decide what evidence is necessary, what can be acquired safely, and which containment steps cannot wait. Record the tradeoff if immediate isolation or restoration takes precedence over preserving volatile artifacts.

Management-plane exposure is not a customer breach count

En Unit 42 report describes theft of a configuration archive containing device information and cryptographic material associated with more than 500 managed FortiGates. It also explicitly says the researchers did not examine the client networks. The number therefore describes the scope of exposed management information, not a verified count of compromised customer networks.

That distinction should drive communications and investigation. Exposed secrets create a reason to identify where those secrets can be used. They do not establish that use occurred. The relevant next step is to map each credential or trust relationship to its destination, examine access records where available, and track replacement or revocation. Report the resulting findings separately from the original archive exposure.

For an MSP, this requires coordination across ownership boundaries. The management team may know which devices were represented in the archive, while a customer controls authentication logs or the systems behind the firewall. Assigning “customer notified” as the final state skips the technical question. A more useful handoff specifies the affected identity, its permitted access, the exposure interval, the evidence requested, and the action required to close the issue.

Avoid including secret values in broad incident tickets. Use controlled evidence storage and reference identifiers in coordination records. When a credential is shared, its replacement plan must include every legitimate consumer; otherwise, an incomplete rotation can leave an old access path active or interrupt service in ways that encourage rollback. These are consequences of the trust map, not assumptions that every exposed secret was exploited.

Decide remediation priority from the chain

Scoring a single vulnerability and prioritizing an incident are related but different tasks. A prerequisite such as administrative access belongs in the vulnerability’s accessibility assessment. An organization that already has evidence of management-plane compromise cannot rely on that same prerequisite as a reassuring barrier. For that organization, the prerequisite may already have been met.

Use three inputs together: whether the affected code is present, whether the required identity or management access could have been obtained, and what the device can reach or authorize. An affected but isolated spare appliance and an affected gateway managed by a compromised server should not receive identical incident handling merely because they share a firmware version. The difference should be documented in exposure and evidence terms, rather than expressed as an invented exploitation probability.

For the suspected-compromise case, organize the work so evidence collection, code correction, and trust restoration can proceed without being confused. Preserve the records needed to reconstruct activity, reduce attacker access, deploy the supported correction, and review configuration and credentials. The exact order depends on operational urgency and the forensic plan. Agree on the collection and containment sequence before changing volatile state.

For a case with no suspicious evidence, still record collection coverage. “No evidence found” is defensible when it names the logs, time interval, searches, and limitations. “Never compromised” is a much stronger claim that incomplete telemetry usually cannot establish. Keeping that difference explicit gives future investigators a useful starting point if new indicators appear.

Recovery acceptance should cover both code and trust

The final acceptance record should be small enough to maintain and specific enough to audit. Each control below addresses a different residual risk. A team may complete one while another remains open; recording those intermediate states is more accurate than one blanket remediation checkbox.

A firmware update is necessary for affected code, but the other rows do not follow automatically from it. Restoring an unreviewed configuration can restore an unauthorized account. Rotating an appliance password does not necessarily replace a credential used by another managed system. Rebuilding a device does not retroactively determine what was accessed before the rebuild.

The lesson of CVE-2025-61624 and PEERSTITCH is a concrete operational one: preserve the distinctions between management access, operating-system authority, volatile compromise, and downstream trust. Correct the vulnerable branch, investigate with evidence suited to the reported behavior, and close each remaining access path on its own merits. That produces a stronger recovery decision than either a clean file scan or a successful upgrade alone.