HIGH: Fortinet FortiGate Firewalls Hit by Stealthy PEERSTITCH Implant

There is a special kind of dread that comes from realizing the box you bought to keep attackers out has been quietly working for them. That is the situation Palo Alto Networks Unit 42 laid out on October 14, when it published research on PEERSTITCH, a previously unreported implant that lives entirely in the memory of Fortinet FortiGate firewalls and teaches them to wave certain VPN sessions straight past their own security checks. Two days later CISA added the FortiOS flaw used to plant it, CVE-2025-61624, to the Known Exploited Vulnerabilities catalog with a federal remediation deadline of today, October 19, and a forensic triage requirement attached. When CISA asks agencies to go looking for evidence of compromise instead of just patching, that tells you how it reads the situation.

The victim in the Unit 42 case was a telecommunications managed service provider, and the intrusion did not start last week. It began in September 2024, which means the actor Unit 42 tracks as CL-STA-0954, also known as UNC5820, had a very long runway before anyone wrote it up. Unit 42 says some of the post-exploitation activity overlaps with suspected nation-state intrusions, and it assessed parts of the tradecraft with a medium degree of confidence. Nobody is pinning a flag on it publicly yet, but the patience and the engineering on display are not what you get from a crew chasing a quick ransom.

FortiManager was the front door

The way in was not the firewall at all. It was the FortiManager appliance that managed the firewalls. The attackers exploited CVE-2024-47575, the FortiJump flaw that made headlines in October 2024. That bug is a missing authentication issue in the fgfmd daemon, rated CVSS 9.8, and it lets a remote, unauthenticated attacker execute arbitrary code or commands on FortiManager. CISA put it in KEV back on October 23, 2024, so anyone who has been paying attention has had nearly two years to close it. The trouble is that closing the hole does nothing about what already walked out through it.

What walked out here was enormous. From the compromised FortiManager the actor pulled an archive containing the central management SQLite databases, running configurations for managed FortiGates, the FortiManager serial number and its management relationships, network topology, routing tables, interface configurations, certificates and private keys, and an inventory of more than 500 FortiGate serial numbers and their public IP addresses. The configurations also carried administrator, local user, and SSL VPN credentials stored as reversible ciphertext. Unit 42 confirmed that those passwords could be recovered by brute force, and the attackers then used them to open SSL VPN sessions into internal management segments. If you have ever wondered why we keep telling people that a management plane compromise is a whole fleet compromise, this is the case study to forward to your boss.

How PEERSTITCH actually works

With valid credentials in hand, the attackers needed a way to get from a restricted administrator session to root on the firewall itself. That is where CVE-2025-61624 comes in. Fortinet published it on April 14, 2026, under advisory FG-IR-26-122, describing a path traversal weakness in the FortiOS CLI that lets a privileged, authenticated attacker write or delete arbitrary files through crafted arguments to existing commands. Unit 42 places the bug in the CLI auto-script engine. Fortinet scores it 5.4 and NVD rates it 6.5, which is exactly why it probably sat at the bottom of a lot of patch queues. The prerequisite is an admin account with read and write rights, and attackers who already own your credentials meet that bar easily. The attackers used a traversal object named along the lines of ../../../../setup to drop their loader, and CISA notes the same bug affects FortiPAM, FortiProxy, and FortiSwitchManager as well.

The delivery chain is a little unusual. Files pulled from a staging server at 23.240.77[.]233 on port 8085 included a preparation script called pM.js that deletes itself, an Emscripten JavaScript runtime saved as index.js, a WebAssembly module saved as index.wasm, an orchestrator saved as ipssem.js, and finally the real payload, an ARM64 ELF binary saved as lldprx. That last file is PEERSTITCH proper, a statically linked C program that works as a one shot injector. After a deliberate delay it attaches to the running /bin/miglogd and /bin/iked processes with ptrace, pauses them, allocates executable memory inside each one, writes its code, and redirects execution. Then it gets out of the way.

The clever part is what the injected code does next. Instead of opening a port or calling home, PEERSTITCH builds a covert bridge between the two daemons in memory. The hook inside miglogd, the logging daemon, watches traffic data for two markers, the value 8550 embedded as a TCP port and the link local address 169.254.0.1, and at no point does it open a listener of its own. When it sees one, it hands the session token across to the hook living inside iked, the IKE and IPsec daemon. The iked hook then checks later VPN sessions for that tag, and when it finds one it sends the session down an alternate code path that skips the default FortiOS security validations. In plain terms, the attacker can mark a session as friendly and the firewall agrees. Unit 42 summed it up neatly, noting that the implant "leaves no persistent binary on disk, opens no listening ports and initiates no outbound network connections." Your external scan will look perfectly clean.

The actor did not rely on a single channel either. Unit 42 documented abuse of the Apache mod_md module, the component FortiOS uses for ACME certificate automation. The attackers used a traversal auto-script to write a malicious md-acme.conf, registered with an ACME server they controlled, mapped the DNS-01 challenge handler to /bin/node, and injected shell commands into the domain name field of the challenge. The result was an SSH-based reverse shell, and because MDRenewMode kept Apache polling for renewals, the payload kept executing on schedule. Using certificate renewal as a persistence mechanism is the kind of idea that makes defenders sigh and grudgingly admire the craftsmanship at the same time. The group also impersonated FortiManager over the FGFM protocol to pull data from other managed firewalls, which is a polite way of saying it borrowed the trust relationship and used it against everyone downstream.

Cleanup was thorough. The operators stopped syslog generation, cleared crash logs, disrupted logging telemetry, and removed the rogue administrator accounts, VPN groups, and auto-script objects they had created once those had served their purpose. They even replaced the ACME configuration with a harmless looking comment. If your plan for detecting this was going to rely on firewall logs, I have some bad news.

Who should be worried

Anyone running FortiOS that is not current should be paying attention, and anyone whose FortiGates are centrally managed by a FortiManager that was ever exposed to CVE-2024-47575 should be paying very close attention. The CVE record for CVE-2025-61624 lists FortiOS 7.6.0 through 7.6.4, 7.4.0 through 7.4.9, and the 7.2, 7.0, and 6.4 branches as affected. Fixed builds are FortiOS 7.4.10 and 7.6.5 or later. The 7.2, 7.0, and 6.4 trains have no direct fix, so organizations on those versions need to migrate to a supported release. Fortinet also shipped an interim virtual patch, FG-VD-59270.0day, in FMWP database update 25.120 for anyone who genuinely cannot upgrade this week.

The uncomfortable truth in this research is that patching ends the vulnerability but not the compromise. Unit 42 says it plainly. The intrusion "does not end when the platform is patched," and trust material from a compromised management platform should be treated as burned. Firewall configs, keys, and recoverable credentials for 500 devices do not become secret again because you upgraded firmware.

What to do this week

Start with the version check and the upgrade, because that part is easy. Move every FortiGate to 7.4.10, 7.6.5, or later, plan migrations for anything stranded on 7.2 or older, and confirm FortiManager has been on a FortiJump fixed build since 2024. If it was ever exposed before that fix, assume the configuration archive left the building and act accordingly.

That means rotating everything the management plane knew about. Reset administrator and local user passwords, reset SSL VPN credentials, reissue certificates and private keys, and rotate any preshared keys stored in the managed configs. Since the stored credential format proved recoverable, a password that has not changed since 2024 should be considered public.

Then go hunting, because PEERSTITCH will not announce itself. Unit 42 recommends inspecting /proc/PID/maps for both miglogd and iked and looking for anonymous 16,384 byte regions with rwxp permissions, which a clean daemon has no reason to carry. It also suggests verifying that the text segments have not been NOP patched at the offsets listed in its report, auditing open, lseek, and write calls against /proc/PID/mem between the two daemons, and running diagnose debug crashlog read to look for Signal 11 crashes in miglogd, iked, or syslogd. Search your auto-script objects for ../ traversal strings and review any ACME or certificate automation settings you did not personally configure. Unit 42 published a YARA rule named u42_apt_linux_PEERSTITCH_fortigate_implant that matches the ARM64 mmap shellcode template, the injection entry prologue, or a cluster of strings such as 169.254.0.1, /bin/miglogd, and /bin/iked. Block and hunt for the staging address 23.240.77[.]233 in perimeter and DNS telemetry while you are at it.

Finally, look at the architecture. Management interfaces for FortiManager and FortiGate should never face the internet, and Unit 42's main strategic recommendation is to wrap edge management under strict zero trust controls. Pull VPN session history for anything that connected into management segments from unusual sources, and compare admin account creation events against change tickets. If your logs from late 2024 onward have unexplained gaps, that gap is itself a finding.

PEERSTITCH is a reminder that the firewall is just a computer running daemons, and the management console that controls fifty or five hundred of them is the most valuable target on the network. Patch it, rotate it, hunt it, and stop assuming that a medium CVSS score means a medium risk when someone already holds the keys.

The MSP angle

Every MSP running FortiManager for multiple clients is wearing the exact shape of this victim, which makes a FortiGate compromise assessment with credential rotation and memory hunting an easy, urgent conversation to have with clients this week. It is also a natural opening to sell managed edge device monitoring and a management plane hardening review, since most clients have never once asked who can reach their firewall's admin interface.