Vulnerabilities
PEERSTITCH: a FortiGate implant that lives only in memory
Attackers used FortiOS flaw CVE-2025-61624 to hide PEERSTITCH inside FortiGate VPN and logging daemons. Fixed builds, checks and what to rotate.
Palo Alto Networks' Unit 42 has published its analysis of PEERSTITCH, an implant that runs inside two FortiOS processes on FortiGate firewalls: miglogd, which handles logging, and iked, which negotiates IKE and IPsec VPN tunnels. The attackers installed it through CVE-2025-61624, a path traversal flaw in the FortiOS command line that Fortinet fixed in April 2026. CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog on October 16, with a deadline of October 19 for US federal agencies.
The victim was a telecom managed service provider. The intrusion began in September 2024 through an older FortiManager flaw, CVE-2024-47575, and from that FortiManager the attackers took an archive with the configurations, credentials and certificate keys of more than 500 managed FortiGates. Unit 42 did not examine the provider's customer networks, so the figure measures exposure, not 500 confirmed break-ins. This applies to you if you run FortiOS 7.6 below 7.6.5, 7.4 below 7.4.10, any 7.2, 7.0 or 6.4 build, or a FortiManager that was reachable from the internet before it was patched for CVE-2024-47575.
How it works
FortiManager, Fortinet's central management console, talks to its FortiGates over the FortiGate to FortiManager protocol (FGFM) on TCP 541. CVE-2024-47575, known as FortiJump and rated CVSS 9.8, is a missing authentication check in the FortiManager service that handles FGFM, so an attacker with no account can register a device and run code on the manager. Unit 42 found a fake Virtual FortiGate named localhost, serial FMG-VMTM23017412, registered from 45.32.41[.]202, after which a configuration archive was generated and taken.
CVE-2025-61624 is the step from administrator to root, out of the restricted FortiOS command line. Fortinet describes the bug as a path traversal (CWE-22) in the command line interpreter that lets a privileged user write or delete arbitrary files by passing crafted arguments to existing commands. Unit 42 saw it abused through system.auto-script objects, which are scheduled CLI scripts. Naming one ../../../../setup or ../../tmp/apache2/conf/md-acme.conf puts the script body at a path the attacker picks, written with root's rights by an account that should only change configuration.
PEERSTITCH itself is a 64-bit ARM64 program written in C. It attaches to miglogd and iked with ptrace (the Linux debugging interface), makes each allocate a 16 KB block of readable, writable and executable memory, writes a 1,344-byte payload into it through /proc/<pid>/mem, patches three spots in the daemons' code with no-operation instructions, and deletes its loader. The hooks watch traffic for the strings 8550 and 169.254.0.1, pass tagged sessions between the two daemons by writing into each other's memory, and send tagged VPN sessions in iked down a branch that skips the usual validation.
Why file checks miss it
Firmware integrity checks compare files on disk against known-good hashes, and Security Affairs reports that Fortinet's Integrity Checker Tool works this way. The miglogd and iked binaries on disk stay genuine; only the running copies change. PEERSTITCH opens no listening port and makes no outbound connection of its own, so a port scan or egress log shows nothing new.
A reboot clears the implant, but it also destroys the evidence, and the attackers had another way back in. Unit 42 found an auto-script that rewrote Apache's mod_md module (which renews TLS certificates over the ACME protocol) to use an attacker-run certificate authority at 23.240.77[.]233:8084, with shell commands in the challenge step that opened an SSH reverse shell. Renewal was set to always, so Apache kept running it.
What attackers are doing
Unit 42 tracks the group as CL-STA-0954, which overlaps with UNC5820, the name Mandiant gave to FortiJump exploitation it traced back to June 27, 2024, with at least 50 FortiManagers potentially compromised. Unit 42 says the post-exploitation activity overlaps with intrusions attributed to suspected nation-state actors, without naming a country.
After the FortiManager compromise, the attackers pushed packet sniffer settings to downstream FortiGates, came back through SSL VPN with brute-forced credentials, used CVE-2025-61624 to reach root, and pulled configurations over TCP 541 under an admin account named FortiGateCloud. They killed miglogd and syslogd before running their scripts, cleared crash logs, and deleted the rogue admin accounts and VPN groups afterwards. Besides configurations, the archive listed every device's serial number and public IP and held credentials stored as reversible ciphertext, some of which the attackers brute-forced.
Some details do not line up. Fortinet published its advisory, FG-IR-26-122, on April 14, 2026, marked as found internally, about 19 months after the intrusion began, and Unit 42 does not say when CVE-2025-61624 was first used, so whether it was a zero-day at the time is unknown. Scores differ too: Fortinet gives CVSS 6.0 with a local attack vector, NVD gives 6.5 with a network vector, and some coverage quotes 5.4, which is Fortinet's temporal score. Any of these "medium" ratings understates the risk once admin credentials are in an attacker's hands.
What to do
1. Patch FortiOS and FortiManager
Upgrade FortiOS 7.6 to 7.6.5 or later and 7.4 to 7.4.10 or later. Branches 7.2, 7.0 and 6.4 get no fix and have to move to a fixed release. The same advisory covers FortiProxy (7.6.5 or 7.4.12), FortiPAM (1.7.1) and FortiSwitchManager (7.2.8 or 7.0.7). Confirm every FortiManager is patched for CVE-2024-47575 under Fortinet advisory FG-IR-24-423.
2. If you cannot upgrade today
Fortinet lists a virtual patch, FG-VD-59270.0day, in FMWP database update 25.120. Exploitation needs a read-write admin account, so also limit who can log in: set trusted hosts on each admin account (config system admin, edit <name>, set trusthost1 <subnet>), keep HTTPS, SSH and FGFM on TCP 541 reachable only from a management network, and require multi-factor authentication for admins and SSL VPN users.
3. Check before you reboot
- Run
show system auto-scripton each FortiGate and search FortiManager revision history for any auto-script name containing../. - Run
diagnose debug crashlog readand look for signal 11 (segmentation fault) in miglogd, iked or syslogd. Search admin event logs forkillall -9 miglogd,killall -9 syslogdanddiagnose debug crashlog clear. - List admins and VPN groups for
FortiGateCloudor anything unknown, review sniffer settings nobody asked for, and look for FGFM sessions on TCP 541 from outside your management range. - On FortiManager, look for unknown devices, such as
localhostwith serial FMG-VMTM23017412. - Search firewall and proxy logs for 23.240.77[.]233, 47.18.167[.]159, 45.32.41[.]202 and 198.199.122[.]22, and for traffic to ports 8084 and 8085. The staged files were
lldprx,index.js,index.wasm,ipssem.jsandpM.jsunder/data2/template/. - Unit 42's memory checks look for anonymous 16,384-byte
rwxpregions in the miglogd and iked memory maps and for no-operation bytes (0xAA0003E0) at the published offsets, which fit one sample and could change. That needs access below the admin CLI, so plan it with Fortinet support or an incident response team before any reboot.
4. Rotate and rebuild after a management-plane compromise
If a FortiManager was exposed and unpatched at any point, treat everything it stored as known to the attacker, patched or not. Rotate admin and local user passwords on every managed FortiGate, SSL VPN user credentials, the LDAP and RADIUS service accounts stored in configurations, and IPsec pre-shared keys on both ends of every tunnel. Replace and revoke the certificates and private keys used for the admin interface, SSL VPN and IPsec, then change FortiManager's own admin passwords and API keys.
Reload any FortiGate with signs of compromise from firmware downloaded fresh from Fortinet and a configuration reviewed line by line, because the latest backup may carry the attacker's auto-scripts, sniffer settings and accounts. Managed service providers should tell the customers whose secrets were on the manager.
Where FortiManager belongs
A central manager holds the secrets of every device it manages, so a breach there exposes the fleet without touching a firewall. Protect it like a domain controller: no internet exposure, separate managers per customer where practical, and logs sent to a collector these attackers could not have wiped.
Our network penetration tests check which management interfaces, FGFM and FortiManager included, can be reached from places they should not be, and our security operations team can run the checks above across a fleet. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.
Sources: Unit 42, Fortinet FG-IR-26-122, NVD CVE-2025-61624, CISA KEV catalog, The Hacker News, Security Affairs, Cloud Security Alliance research note, Rescana, SC Media, Security Affairs on FortiJump and UNC5820.