Attackers Turned FortiGate Into a Pivot Server. CISA Just Started the Clock.
A FortiGate firewall is supposed to stop hostile traffic at the perimeter. Attackers exploiting CVE-2025-25249 are using that trusted position for the opposite purpose: as a shell, scanner, proxy and route into the network behind it.
CISA added the vulnerability to its Known Exploited Vulnerabilities catalogue on 9 September and gave US federal agencies until 12 September to remediate it. That unusually short deadline turns an old patching decision into a current incident-response problem.
SOCRadar says it identified exploitation dating back to at least July 2026. Its researchers found a purpose-built Node.js remote-access tool called PivotC2 on compromised devices. The malware can harvest FortiGate configuration files, decrypt stored credentials, scan internal address ranges, create SOCKS5 and HTTP proxies and forward traffic through the firewall.
The security appliance became post-exploitation infrastructure
The vulnerability is a heap-based buffer overflow in the cw_acd daemon used for wireless-controller functions. A remote unauthenticated attacker can send crafted requests and execute arbitrary code or commands. The daemon listens for CAPWAP control traffic on UDP port 5246 by default.
That location matters. A compromised edge appliance sits between the internet and networks that may trust it. PivotC2 uses an outbound TLS connection to its command server, then multiplexes interactive shells, file transfers and forwarding channels across that connection. Inbound filtering does little to help when the trusted device initiates the session.
SOCRadar says the tool can collect the global and virtual-domain configuration archives, obtain the device secret used for protected values and decrypt stored FortiGate credentials. Its automatic mode can immediately harvest configuration, extract credentials and scan newly discovered internal ranges after a device connects.
This is more consequential than a generic remote shell. The attacker gains a durable network vantage point on an appliance that defenders may monitor less like a server and trust more like infrastructure.
What is confirmed, and what remains a researcher assessment
CISA’s catalogue establishes that malicious exploitation is occurring. It does not identify the campaign, victim count, attacker or malware.
The more detailed figures come from SOCRadar. The company says attacker files contained more than 30,000 target IP addresses and 178 confirmed PivotC2 victim sessions. It also reports evidence of two complete intrusions against US organisations that reached data exfiltration.
SOCRadar assesses with high confidence that the activity is associated with a Russian-speaking, financially motivated operator. It also believes detailed comments and usage guidance in the Node.js code indicate AI-assisted development. Those are evidence-based researcher assessments, not independent government attribution.
The affected versions have been patchable for months
Fortinet published its advisory on 13 January 2026. The vulnerable ranges include FortiOS 7.6.0 through 7.6.3, 7.4.0 through 7.4.8, 7.2.0 through 7.2.11, 7.0.0 through 7.0.17 and every FortiOS 6.4 release. FortiSwitchManager 7.2.0 through 7.2.6 and 7.0.0 through 7.0.5 are also affected.
Organisations should follow Fortinet’s upgrade table for their supported branch. FortiOS 6.4 users must migrate to a fixed release rather than look for a corrected 6.4 build.
Fortinet’s workaround is to disable the fabric service on external interfaces when it is not required, or use a local-in policy to block UDP ports 5246 through 5249 from untrusted sources. A workaround reduces exposure. It does not remove an implant or reverse activity that occurred before the control was applied.
Patching is only the first half of the response
- Identify every FortiOS and FortiSwitchManager instance, including standby appliances, lab systems and devices outside central management.
- Upgrade vulnerable branches using Fortinet’s current fixed-version guidance.
- Restrict CAPWAP and fabric-service exposure at internet-facing interfaces where operationally possible.
- Look for unexpected Node.js processes, scripts and files in temporary directories, outbound TLS sessions from the appliance and unexplained proxy or forwarding behaviour.
- Review firewall configuration archives, administrative accounts, local secrets and credentials stored on the device. Rotate credentials that may have been harvested.
- Investigate internal scanning and connections that originated from the firewall, especially activity that normal monitoring may have treated as trusted infrastructure.
- Preserve relevant logs and appliance evidence before rebooting or rebuilding. A clean current process list does not prove the device was never used as a pivot.
The critical question is no longer whether the vulnerable service was reachable. It is whether a reachable device was exploited during the months between patch availability and confirmed campaign disclosure.
The BlackTree view
Edge-device incidents repeatedly expose the same monitoring gap. Organisations inventory the firewall’s firmware but do not always collect the process, file and outbound-connection evidence needed to detect post-exploitation activity on the appliance itself.
PivotC2 makes the consequence visible. The perimeter did not simply fail open. It became attacker infrastructure with a trusted route to everything behind it. CISA’s deadline should start patching, but the campaign evidence should start a hunt.
Sources
- Fortinet PSIRT advisory FG-IR-25-084, initially published 13 January 2026. The public advisory provides no publication time.
- CISA Known Exploited Vulnerabilities catalogue, entry added 9 September 2026 with a 12 September remediation deadline. The catalogue provides no publication time.
- SOCRadar: CVE-2025-25249 Exploitation Delivers PivotC2, published 8 September 2026. The page provides no publication time.
