On 16 October 2026 CISA added CVE-2025-61624 to its Known Exploited Vulnerabilities catalog, with a federal remediation deadline of 19 October. The bug sits in the command line of FortiOS, the operating system on FortiGate firewalls, a firewall line that many small and mid-size offices run. Fortinet scores it CVSSv3 6.0, Medium, and NVD gives it 6.5. A Medium score with a fix out since April is easy to push down the list.
They should look again. The flaw needs an administrator login, and in the intrusion that put it on CISA's list the attackers already had those logins, decrypted from stolen firewall configuration files. So this article is less about one patch and more about what happens after it: which versions are affected, how to check your FortiGate, what Unit 42 says to hunt for, and why every password, pre-shared key and certificate in the config has to change once you suspect it left the building.
What Fortinet and CISA published
Fortinet's advisory FG-IR-26-122, first published on 14 April 2026, describes a path traversal in the command line interpreter of FortiOS, FortiPAM, FortiProxy and FortiSwitchManager that "may allow a privileged attacker to achieve arbitrary write or delete files via specifically crafted arguments to existing commands." The advisory now marks it "Known Exploited: Yes", lists the impact as escalation of privilege, and notes a virtual patch, FG-VD-59270.0day, in FMWP database update 25.120.
The context arrived on 14 October, when Palo Alto Networks' Unit 42 published its investigation of a telecom intrusion in which this bug was used to load a memory-only FortiGate implant it calls PEERSTITCH. CISA's KEV listing followed two days later.
Affected and fixed versions
From FG-IR-26-122:
| Product | Affected | Fix |
|---|---|---|
| FortiOS 7.6 | 7.6.0 through 7.6.4 | 7.6.5 or above |
| FortiOS 7.4 | 7.4.0 through 7.4.9 | 7.4.10 or above |
| FortiOS 7.2, 7.0, 6.4 | All versions | Migrate to a fixed release |
| FortiProxy 7.6 | 7.6.0 through 7.6.4 | 7.6.5 or above |
| FortiProxy 7.4 | 7.4.0 through 7.4.11 | 7.4.12 or above |
| FortiProxy 7.2, 7.0 | All versions | Migrate to a fixed release |
| FortiPAM 1.7 | 1.7.0 | 1.7.1 or above (1.8 not affected) |
| FortiPAM 1.0 to 1.6 | All versions | Migrate to a fixed release |
| FortiSwitchManager 7.2 | 7.2.0 through 7.2.7 | 7.2.8 or above |
| FortiSwitchManager 7.0 | 7.0.0 through 7.0.6 | 7.0.7 or above |
The row that will catch most small offices is the third one. A FortiGate still on 7.2, 7.0 or 6.4 gets no fix on its current branch, so "patching" means a branch upgrade, with the testing and maintenance window that implies. If your model is not supported on 7.4 or 7.6, this becomes a hardware replacement conversation.
How the attackers used it
Unit 42 says the intrusion happened in September 2024 at a telecommunications organization and tracks the group as CL-STA-0954, also known as UNC5820. The chain, as Unit 42 describes it, went like this:
- The attackers exploited CVE-2024-47575 (FortiJump) on the company's central FortiManager and exfiltrated an archive with running configurations for "more than 500 managed FortiGate firewalls", including devices that protected the provider's clients.
- Those configurations held "ciphertext administrative, local and SSL/VPN credentials". Unit 42 writes: "We confirmed that the credentials were recoverable by successfully brute-forcing administrative and SSL/VPN passwords from the exfiltrated configuration files."
- With those passwords the attackers opened SSL VPN sessions to perimeter firewalls, then used CVE-2025-61624 to go from FortiOS administrator to root on the underlying operating system. They did it by creating a
system.auto-scriptobject named../../../../setup, because the auto-script engine does not sanitize object names. - From there they injected PEERSTITCH into the
miglogdlogging daemon and theikedVPN daemon. Unit 42 says it "leaves no persistent binary on disk, opens no listening ports and initiates no outbound network connections."
They also covered their tracks. Unit 42 lists killall -9 miglogd and killall -9 syslogd before running scripts, diagnose debug crashlog clear to wipe crash logs, and automatic deletion of rogue admin accounts, VPN groups and auto-script objects shortly after use. On some firewalls they pushed packet captures aimed at RADIUS (UDP 1812 and 1813), LDAP (TCP 389) and TFTP (UDP 69). That is credential collection, not curiosity.
The lesson for a 40-person company is not about telecoms or nation-state attribution. It is that a Medium-rated, authenticated-only bug became root on hundreds of firewalls because the admin passwords were already out. If you have ever lost a config backup, exposed a management interface, or reused the FortiGate admin password somewhere else, "requires authentication" protects you less than the score suggests.
Check your version and exposure
In the FortiGate web interface the firmware version is on the dashboard status widget. From the CLI, get system status prints the version and build on the first lines. Compare it with the table above. Do the same for any FortiProxy, FortiPAM or FortiSwitchManager you run.
Then check who can reach the admin interface. Run show system interface and look at the set allowaccess line on every internet-facing port. If it includes https, ssh or http, your management login is on the internet. Fortinet's own recovery guidance tells you to disable administrative access on external interfaces and restrict logins to trusted hosts, and its June 2026 PSIRT blog ranks the options: trusted hosts is good, a local-in policy is better, no internet administration at all is best.
Finally, ask where your config backups live. A FortiGate config file exported to a shared drive, emailed to a contractor, or stored in a FortiManager you have not patched is the same kind of material Unit 42 saw stolen.
Patch, or migrate off old branches
Upgrade FortiOS 7.6 to 7.6.5 or later and 7.4 to 7.4.10 or later, following Fortinet's upgrade path tool rather than jumping several builds at once. If you are on 7.2, 7.0 or 6.4, plan the move to 7.4 or 7.6 now. Fortinet's June blog adds a second reason: 7.4, 7.6 and 8.0 "support PBKDF2 hashing of administrator credentials", and it recommends removing legacy password settings via set login-lockout-upon-weaker-encryption.
The virtual patch named in FG-IR-26-122 can buy time where a maintenance window is days away. It is not a substitute for the upgrade, and it does nothing about credentials that already leaked.
What to hunt for
Unit 42 published a detection table. These are the checks a small IT team can actually run or hand to its provider:
- Configuration: search current config and stored revisions for
system.auto-scriptobjects with../../in the name.show system auto-scriptlists the current ones. Unit 42 saw../../../../setupand../../tmp/apache2/conf/md-acme.conf. - Crash logs: run
diagnose debug crashlog readand look for Signal 11 crashes involvingmiglogd,ikedorsyslogd. An empty crash log on a box that has been up for months is worth a question too, since the attackers cleared it. - Memory: anonymous 16,384-byte regions with
rwxppermissions in the memory maps of/bin/miglogdand/bin/iked. You need Fortinet TAC or an incident responder for this, because a normal admin has no shell. - Files and network: filenames
lldprx,pM.js,ipssem.js,index.jsandindex.wasm, and the IP addresses 23.240.77[.]233, 47.18.167[.]159, 45.32.41[.]202 and 198.199.122[.]22, plus the SHA-256 hashes and YARA rule in the report's IOC section. - Accounts and VPN: an admin account named
FortiGateCloudthat you never provisioned, admin or VPN users that appeared and disappeared, and SSL VPN logins from unfamiliar addresses. Fortinet's June blog also says to look for unrecognized accounts "such as forticloud, fortiuser, fortinet-support, fortinet-tech-support".
Capture logs, a config backup and diagnostic output before you reboot, reflash or factory reset anything. An implant that lives only in memory leaves very little else to find, and Fortinet's recovery article says to preserve these first.
Why patching is not the end
A patched FortiGate with the same admin password, the same VPN user passwords and the same IPsec keys is still open to whoever decrypted the old config. Unit 42's conclusion puts it plainly: trust material taken from a management platform "leaves with the attacker and remains valid until it is rotated." We made the same argument about appliances in Citrix NetScaler: rotate secrets after patching, and the pattern has not changed.
Fortinet's guidance for unauthorized access to a device configuration, applied after upgrading, comes down to this order:
- Restore configuration from a known good backup, or build a clean one and validate it.
- Reset all admin, local user and VPN user credentials.
- Reset RADIUS secrets and IPsec pre-shared keys.
- Replace certificates and revoke the ones that may have been stolen.
- Change the LDAP bind account password the FortiGate uses.
- Restrict admin logins to trusted hosts, remove admin access from external interfaces, and add two-factor authentication for administrators.
Fortinet's June 2026 blog adds two points: terminate all active admin and VPN sessions, and put MFA on every administrator and VPN account. Sessions matter because a password reset does nothing to a VPN tunnel that is already up. If the FortiGate authenticates users against Active Directory, the LDAP service account and any password typed through a captured RADIUS or LDAP flow should be treated as exposed, and your domain controller logs belong in the hunt. Stolen VPN logins are also how ransomware crews get in, as the agencies described in our SafePay ransomware write-up, and MFA that can be phished only goes so far, which we covered in our AiTM phishing piece.
If a provider manages your FortiGate
The victim in the Unit 42 case was a managed service provider, and the stolen archive covered its clients' firewalls too. Unit 42 notes it did not examine those client networks, so it does not claim they were breached. If an MSP runs your firewall through FortiManager or a similar console, ask them three things this week: what FortiOS version your unit runs, whether their management platform was ever exposed to CVE-2024-47575, and when your admin, VPN and IPsec secrets were last changed. If nobody can answer the third question, assume the answer is "at install time".
FAQ
Is CVE-2025-61624 exploitable without a password?
No. Fortinet lists the attack type as authenticated, and the NVD description requires "an authenticated attacker with admin profile and at least read-write permissions". The risk comes from how often those credentials are already exposed through config backups, reused passwords or an internet-facing login page.
We are on FortiOS 7.2. Is there a 7.2 fix?
No. FG-IR-26-122 lists every 7.2, 7.0 and 6.4 version as affected with "Migrate to a fixed release" as the solution. You need 7.4.10 or later, or 7.6.5 or later, if your hardware supports it.
Does a reboot remove PEERSTITCH?
Unit 42 describes it as memory-resident with no persistent binary, but the attackers held valid credentials and could return. Collect evidence first, then follow Fortinet's recovery steps, including a clean firmware install if compromise is confirmed, and rotate every secret.
Our FortiGate never had admin access on the WAN. Are we safe?
Less exposed, not safe by default. In the Unit 42 case the attackers got configs from the management server and logged in over SSL VPN. Patch anyway, check where config backups are stored, and confirm MFA on VPN accounts.
Which credentials do we change first?
Admin accounts and VPN users first, since those give direct access, then IPsec pre-shared keys, RADIUS secrets and the LDAP bind account, then certificates. Terminate active sessions as part of the same change.
Need a second pair of hands for the upgrade, the hunt or the credential rotation? Our cloud and DevOps team does this work for small and mid-size companies.
Sources: Fortinet PSIRT FG-IR-26-122, CISA KEV alert, 16 October 2026, NVD CVE-2025-61624, Unit 42 PEERSTITCH report, 14 October 2026, Fortinet recovery guidance, Fortinet PSIRT blog, June 2026. Version data checked on 2 November 2026.
