🔒 Closed beta: four products · 📉 Corrections record: AI mistakes, counted by class and fed back into the next run · 📢 New post: FedRAMP Release 2026.10.13.01 Added 279 Control Mappings and Has No Changelog Entry · 📝 Also fresh: Atlassian CVE-2026-21589 Added to KEV; CVE Record Rejected the Next Day · 🚦 Beacon — the FedRAMP 20x KSI emitter — see what it emits ✨ · 🆕 20x Hub: program reference, kept current · 🧪 KSI Quick Check: KSI Quick Check — paste, run, get the verdict
← Blog
FedRAMPConMonCISAIncident Response

FortiOS CVE-2025-61624 Added to KEV: Admin-Required Path Traversal to Root

On October 16 CISA added CVE-2025-61624 to the Known Exploited Vulnerabilities catalog as Fortinet Multiple Products Path Traversal Vulnerability, with a federal remediation due date of October 19. Three days.

The numbers around it do not look like a three-day item. NVD's primary score is 6.5 Medium (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H), Fortinet's own CNA score is 6.0 Medium with the attack vector marked local rather than network, and CISA's SSVC record calls exploitation active, automatable no. The weakness is CWE-22, path traversal. The description's most prominent clause is the precondition: it requires an authenticated attacker with admin profile and at least read-write permissions.

Read cold, that clause is reassuring. It is the part of a vulnerability record that lets you move on — the bug needs an administrator, administrators are trusted, therefore this is a hardening item rather than a fire. We have made the argument before that a Medium on the catalog outranks a Critical that is not on it, and that is true here too, so we will not spend the post on it.

What is worth the post is the precondition itself, because two days before the listing someone published exactly what satisfying it looked like.

What the administrator requirement actually cost

On October 14, Unit 42 published its analysis of an intrusion it tracks as CL-STA-0954 (also known as UNC5820) against a telecommunications organization. The intrusion itself occurred in September 2024. Initial access was CVE-2024-47575, the FortiManager authentication bug CISA listed on 2024-10-23. From that one management appliance the attackers took an archive of running configurations, cryptographic material, and database files covering more than five hundred managed FortiGate firewalls.

Then comes the part that matters for the precondition. Per Unit 42, the exfiltrated FortiGate configurations held credentials as reversible ciphertext, and the researchers confirmed recoverability by brute-forcing administrative and SSL/VPN passwords out of the configuration files themselves. The attackers logged back in with legitimate credentials, from external staging infrastructure, into network-management segments.

So PR:H was satisfied. Not by an insider, not by a phishing campaign against a named engineer — by reading a config file taken off a different box two years earlier.

That is the thing to carry out of this entry. "Requires administrative privileges" describes the cost of the second step, and tells you nothing about whether the first step already happened. On an appliance whose backups and configurations are routinely copied to a management platform, to a version-control repository, to a ticket attachment, the administrative credential is not a secret guarded by one control. It is a value that exists in as many places as the configuration does.

The privilege boundary was drawn, not enforced

Here is where the Medium score and CISA's assessment stop contradicting each other.

A FortiOS administrator — Unit 42 is specific that this includes super_admin — operates inside a restricted management command line. No shell. No direct control over the appliance file system or its running processes. Meanwhile the daemons that implement FortiOS run as root underneath that interface. The restricted CLI is the product's privilege boundary: it separates the person who configures the firewall from the operating system the firewall is.

CVE-2025-61624 removes it. Per Unit 42's analysis, the FortiOS CLI system.auto-script engine does not sanitize the auto-script object name, so a name containing traversal sequences places the script body at an arbitrary filesystem path, and the script executes with the auto-script engine's privileges. The attackers pushed ../../../../setup to a selected set of firewalls and used it to stage a loader.

Fortinet's advisory, FG-IR-26-122, describes this as a privileged attacker achieving arbitrary write or delete of files. Both CVSS vectors score confidentiality impact as none and scope as unchanged. CISA's SSVC record for the same CVE says technical impact: total.

Neither is wrong. The CVSS vector describes a file write. The SSVC field describes what a file write as root on a network appliance is worth. The gap between them is the gap between the mechanism and the privilege model it defeats, and it is exactly the gap a severity-sorted queue cannot see — which is the case BOD 26-04 makes for sorting by exposure and control instead.

For a system with an authorization boundary, the consequence is concrete and it is a documentation problem before it is a patching problem. Your SSP almost certainly treats appliance administrative access as a privileged role, and the appliance as a managed component with a vendor-maintained operating system underneath it that you do not touch. CVE-2025-61624 says the component and the host are the same reachable surface, and that anyone holding the privileged role holds root. If your least-privilege narrative for network devices leans on the restricted CLI as the thing that keeps an administrator out of the operating system, that sentence is describing a design intention rather than an enforced control.

What triage has to look for, and why the window is wrong

The KEV row carries forensicTriage: **Yes**. That is the structured field, not the boilerplate required-action prose that names the Forensics Triage Requirements on every entry since July — so the obligation genuinely attaches here.

The implant it attaches to is unkind to the exercise. PEERSTITCH, as Unit 42 names it, is a statically linked ARM64 binary that acts as a one-shot process-memory patching injector. It leaves no persistent binary on disk, opens no listening ports, and initiates no outbound connections of its own, communicating instead through traffic generated by legitimate processes. Its two targets are /bin/iked, the IKE/IPsec daemon, and /bin/miglogd — the central system and traffic logging daemon.

Sit with the second one. The triage CISA requires asks you to examine evidence from the appliance. The documented post-exploitation patches the process that produces that evidence.

Which puts a short list of questions in front of anyone running an affected build:

  • Is there a record of a system.auto-script object being created, and does its name contain traversal sequences? Unit 42 shows FortiOS log entries capturing the creation of ../../../../setup and of ../../tmp/apache2/conf/md-acme.conf, the latter weaponizing the appliance's native Apache mod_md ACME module into a command channel. Those log lines are the cleanest indicator available, and they come from the daemon the implant modifies.
  • Are administrative authentication events retained far enough back, and are appliance logs shipped off the appliance to somewhere the appliance cannot rewrite? Log integrity stops being an audit checkbox at the point where the attacker's first action is root on the log daemon.
  • When were the running configurations of these devices last copied anywhere, and do any of those copies still exist? The credential path in this campaign ran through configuration archives, not through the firewall's login page.

And the window. The KEV date is October 16. The SSVC assessment is dated October 15. The vendor advisory and the NVD record both published 2026-04-14, a hundred and eighty-five days before the listing. The intrusion the listing reflects was September 2024 — roughly nineteen months before the CVE identifier published at all, and twenty-five before it acquired a due date.

A retention window measured from the catalog date looks at the wrong period by about two years. We have watched this gap between public knowledge and federal deadline open before, but not this wide, and not with the exploitation evidence sitting this far back behind the CVE's own publication.

Two notes on scoping, because the remediation is not uniform

The fix exists on some branches and not others. Fortinet's table names upgrades for FortiOS 7.6.5 and 7.4.10, FortiProxy 7.6.5 and 7.4.12, FortiSwitchManager 7.2.8 and 7.0.7, and FortiPAM 1.7.1, with FortiPAM 1.8 not affected. For FortiOS 7.2, 7.0 and 6.4, for FortiProxy 7.2 and 7.0, and for every FortiPAM branch at 1.6 and below, the solution column reads "Migrate to a fixed release." There is no patch for the branch you are on. Inside an authorization boundary that is a major-version migration of a boundary-protection device, under change control, with a deadline of October 19 — and the required-action text has an answer ready for that case, which is to discontinue use of the product if mitigations are unavailable.

Worth checking your scanner against the advisory before you trust either. NVD's CPE data collapses the FortiOS lines into a single range starting at 6.4.0 and ending below 7.4.10, which reads to a version-matching tool as fixed in 7.4.10 for a 6.4 appliance whose branch the vendor says has no fixed release. Same shape as the PaperCut off-by-one: the structured data that feeds the tooling and the prose that states the remediation do not agree, and the prose is the one you have to file evidence against.

And the affected asset may not say Fortinet on it. The CVE's own CPE list includes siemens:ruggedcom_ape1808 — a utility-grade industrial application-hosting platform that runs FortiGate NGFW as a hosted workload. Siemens ProductCERT published SSA-975644 covering this CVE among others, with its CVE-2025-61624 entry in the version dated 2026-05-12, five months ahead of the listing. Its remediation is not a download: update the Fortinet NGFW to V7.4.10 or later, and contact customer support to receive patch and update information.

That is a different three days. The KEV row says Fortinet / Multiple Products; the asset tag in a substation cabinet says Siemens; the remediation path runs through an OEM support queue rather than a vendor portal. A query over your inventory for vendor Fortinet does not return it, and the question that follows every one of these — is it in the boundary — cannot be answered until the asset is named correctly in the first place.

The part that keeps repeating

The facts that decide what you owe on this CVE are scattered across sources that do not reference each other. The privilege boundary the bug defeats is described in a threat-research blog published by a competitor of the affected vendor. Whether your branch has a fix at all is in a table most of the way down a PSIRT page. Neither is in the KEV row, and the KEV row is what starts the clock.

That is the gap the Novaprospect audit engine is built to close — asset context that travels with the asset, including who sold you the box, what is actually running inside it, which advisory names your branch, and whether the remediation for your branch exists at all. A remediation record that says upgraded to 7.4.10 is a different artifact from one that says migrated off 6.4, because 6.4 was never going to get a fix, and only the second one survives being asked about in eighteen months.

The question this one leaves behind is not about Fortinet. For every privileged role in your system description, do you know whether the thing that confines it is a control you enforce or a boundary the product draws for you? The two read identically in an SSP. They diverge the first time someone writes a file with a name that starts with ../.

Reference