PivotC2 uses the same CAPWAP port to get in and pivot

A firewall does not run an endpoint agent, which is most of the reason this campaign ran as long as it did: 178 FortiGate appliances compromised on production perimeters since July 2026, with little on the network able to name what was wrong. The detail that made me stop was narrower than the infection count. PivotC2, the Node.js implant that SOCRadar's Threat Research Unit recovered from those devices, does not bring its own tunnel. It picks up the one the firewall already runs, on the same UDP port that let the operator in.

Who is running this

The cluster has no state attribution and no assigned MITRE ATT&CK group ID, worth saying plainly before anyone reaches for a nation-state frame. SOCRadar describes a Russian-speaking cybercrime operation motivated by credential and configuration theft, the kind that gets resold or turned into a ransomware intrusion weeks later. Targeting is broad: a recovered list of more than 30,000 FortiGate IP addresses, 178 confirmed infections since July 2026, heaviest in the United States, and at least two intrusions ending in confirmed exfiltration. What put it on the board this week is the federal clock, since CISA added CVE-2025-25249 to the Known Exploited Vulnerabilities catalog on September 9, 2026 with a September 12 deadline.

The same port twice

CAPWAP is the Control and Provisioning of Wireless Access Points protocol, which a FortiGate speaks so it can act as a controller for the access points on the network. The daemon handling it, cw_acd, listens on UDP port 5246, and CVE-2025-25249 is a heap-based buffer overflow, CWE-122, in that daemon, reachable by a crafted CAPWAP request from an unauthenticated sender. One packet, and the operator has code execution on the device that terminates your VPN and enforces your segmentation policy.

That much is an ordinary edge-appliance bug. What the implant does next is not.

Once resident, PivotC2 holds a persistent outbound TLS session to its command and control server and drives the appliance's own CAPWAP tunneling subsystem as a relay into the VLANs behind the firewall. That subsystem exists so a controller can carry traffic to the access points it manages, and PivotC2 points it at internal hosts instead. Operator sessions leave on the inside sourced from the firewall's own address, so the traffic inherits the firewall's identity rather than merely passing through it.

Three controls fail at once, and each fails for a reason its owner would have defended in a design review.

• Egress filtering. The callback is outbound TLS on 443 from the network's own firewall, the one device whose outbound traffic nobody holds to an allowlist, because it is what does the filtering.
• Internal segmentation. An ACL is written in terms of source addresses, and the firewall's address is the one source every internal rule already trusts. A session reaching a domain controller from the firewall reads as the expected shape of a network.
• Endpoint telemetry. No agent installs on FortiOS, so the appliance produces nothing your EDR console will show, while internal servers see only an authenticated session from a trusted source. Coverage on edge devices is a known structural gap.

Let me be precise about the novelty claim, because the field is full of overstated ones. Relaying through a compromised host is old, and ATT&CK covers it generically under T1090 Proxy and T1572 Protocol Tunneling. What does not exist is a sub-technique for an appliance's own management protocol repurposed as the relay fabric. So the claim I will defend is narrow: a new mechanism inside a known class, not a new class, with no prior public reporting of CAPWAP driven this way that I can find.

The CVEs in play

One of these is the vector this operator uses. The other two landed in the same September 9 KEV batch against the same edge tier, so treat all three as one exposure window.

CVE	Product	How this actor uses it	KEV status	Source
CVE-2025-25249 CWE-122, CVSS 7.4 vendor / 9.8 NVD	FortiOS and FortiSwitchManager, cw_acd daemon on UDP 5246	Primary vector. Unauthenticated RCE from one crafted CAPWAP request, which stages PivotC2	Added September 9, 2026, deadline September 12. Exploited since July 2026	SOCRadar STRU
CVE-2026-20079 CWE-288, CVSS 10.0	Cisco Secure Firewall Management Center	Not used by this operator. Same KEV batch and edge tier, reported against other clusters	Added September 9, 2026	SecurityWeek
CVE-2026-19490 CWE-288, CVSS 9.3	Citrix NetScaler ADC and Gateway	Not used by this operator. Gateway authentication bypass, 56 attempts logged from September 3, 2026	Added September 9, 2026	CISA KEV

What a base-score queue does with this

This CVE carries two base scores, and both point you the wrong way. Fortinet, acting as the CNA, scored it 7.4 with attack complexity high, reasoning that a working heap overflow depends on the specific model and build in front of you, while NVD scored the same flaw 9.8 with attack complexity low. Most scanners pull from NVD, so most queues show the higher of the two without anyone noticing the disagreement. Take the vendor number and the finding sits below every 9.x in your backlog, on a device class that is internet-facing by definition. Take the NVD number and it joins several hundred other 9.8s. Neither encodes the question that decides this one, which is whether UDP 5246 on that appliance answers a packet from an untrusted network.

The dates make the point more bluntly. Fortinet published the fix on January 13, 2026, exploitation began around July, and the KEV listing arrived on September 9, roughly eight months after a patch existed. Nothing in the CVSS vector moved across those eight months, and everything about the real risk did.

How TRIS ranks these findings

TRIS is the Threat and Risk Intelligence Scoring engine inside CVEasy AI, and four layers do the work here.

Exploitation status, stated honestly. In-the-wild abuse of CVE-2025-25249 is confirmed, by KEV listing and by implants recovered from live appliances. The companion flaws are weaker and TRIS keeps them separate, because logged attempts against CVE-2026-19490 are attempts rather than confirmed compromise, and a working proof of concept is not evidence of abuse either.

Reachability of the primitive. Not whether the appliance is internet-facing, which nearly every firewall is, but whether the vulnerable daemon answers.

Blast radius through stored credentials. A FortiGate configuration holds SSL-VPN accounts, IPsec pre-shared keys, wireless passwords, the LDAP bind secret, and local admin accounts. An appliance whose LDAP bind reaches a production directory carries far more risk than an identical build with a read-scoped account.

Position in the topology. Those layers combine into a band rather than a number. An internet-exposed FortiGate terminating SSL-VPN, with CAPWAP answering and a privileged LDAP bind, scores top band ACT, while the same build on a segmented management VLAN with CAPWAP confined to the wireless segment drops several bands. Same CVE, different real exposure.

What to run this afternoon

All of this runs against log sources you already have.

• Long-lived outbound TLS from the appliance. Query firewall session or netflow records for sessions sourced from a FortiGate address to port 443 on any destination outside your known update and telemetry endpoints, lasting well beyond a normal API call.
• Retrospective hunt on the published C2 addresses. Published indicators include 146.103.99.177 and 46.151.29.58. Run both against 60 days of proxy, netflow, and DNS records, and against current session tables on the appliances.
• Internal sessions sourced from the firewall. This is the rule that catches the pivot rather than the implant: alert on connections whose source is a firewall interface and whose destination port is 3389, 445, or 389. Your firewall has no business opening RDP, SMB, or LDAP sessions to internal hosts.
• On-device artifacts. Watch for reads of the device secret at /data/fsv_sync.dat, for full-configuration backups leaving to anything that is not your sanctioned backup target, and for a running Node process or script files in temporary directories.
• Prove the exposure from outside. Confirm externally whether UDP 5246 on each perimeter appliance answers. That one result is the input most inventories lack.

Fix, then rotate

Fortinet tracks this as advisory FG-IR-25-084. Fixed builds are FortiOS 7.0.18, 7.2.12, 7.4.9, and 7.6.4 or later, with FortiSwitchManager on 7.0.6 or 7.2.7 and later, and everything below those on their trains is affected. FortiOS 6.4 is affected in full and receives no fix at all, so a 6.4 appliance still carrying traffic needs a migration plan rather than a patch window.

Where an upgrade cannot happen immediately, cut the vector: restrict CAPWAP to the wireless segment that needs it and block UDP 5246 at the internet edge. Fortinet also documents removing fabric access from each interface.

Then rotate, assuming the configuration leaked: SSL-VPN and local admin accounts, IPsec pre-shared keys, wireless passwords, and the LDAP bind credential, plus a password reset for any account reachable through the recovered VPN. Rotation denies the operator the durable valid-account access that outlives the implant, and it is the step most often deferred because it is the one that touches users.

Where CVEasy AI fits

CVEasy AI is the number one local-first CTEM platform, and it ingests the sources this post cites, KEV entries, vendor advisories, and published research, then runs them through TRIS against your own inventory on your own hardware. The output is a band rather than a number: which appliances answer on the vulnerable primitive, what each holds in its configuration, and what that is worth against everything else in the queue. BASzy replays this actor's kill chain in authorized engagements, so you learn whether the path is reachable before somebody else measures it.

Sources: SOCRadar STRU, CISA KEV, SecurityWeek, MITRE ATT&CK, NHS England Digital