CVE-2025-25249: Fortinet Heap Overflow and Remote Code Execution Risk

CVE-2025-25249 is a critical heap-based buffer overflow vulnerability affecting Fortinet products including FortiOS, FortiSwitchManager, and certain FortiSASE releases. The vulnerability exists in the cw_acd daemon and can allow a remote, unauthenticated attacker to execute unauthorized code or commands by sending specially crafted network packets.

That description alone makes CVE-2025-25249 serious. What makes the vulnerability substantially more urgent today, however, is that it is no longer merely a theoretical remote code execution risk.

On September 9, 2026, the U.S. Cybersecurity and Infrastructure Security Agency added CVE-2025-25249 to its Known Exploited Vulnerabilities Catalog after finding evidence of active exploitation. CISA set September 12, 2026 as the remediation deadline for affected U.S. federal civilian agencies. As of September 15, that deadline has already passed. (dejavu.org)

Independent threat research provides additional context. SOCRadar reported a campaign in which exploitation of CVE-2025-25249 was used to deploy a FortiGate-focused remote access tool called PivotC2. The researchers said observed exploitation could be traced back to at least July 2026 and described attackers using compromised FortiGate appliances not simply as isolated footholds, but as infrastructure for credential collection, tunneling, network discovery, lateral movement, and data theft. (SOCRadar® Cyber Intelligence Inc.)

For defenders operating Fortinet infrastructure, the practical conclusion is straightforward:

CVE-2025-25249 should now be treated as an actively exploited perimeter-device RCE vulnerability, not as a routine firmware issue.

CVE-2025-25249 at a Glance

Item	Details
CVE	CVE-2025-25249
Vendor	Fortinet
Primary affected products	FortiOS, FortiSwitchManager, FortiSASE
Vulnerability type	Heap-based buffer overflow
CWE	CWE-122, CWE-787
Vulnerable component	cw_acd daemon
Attack vector	Network
Authentication required	No
User interaction required	No
Potential impact	Unauthorized code or command execution
Important protocol	CAPWAP
Commonly relevant port	UDP 5246
CAPWAP control range referenced in mitigation	UDP 5246–5249
Current NVD CVSS v3.1	9.8 Critical
CISA KEV	Yes
KEV added	September 9, 2026
CISA remediation date	September 12, 2026
Known ransomware use	Unknown
Active exploitation	Confirmed

The current NVD assessment uses the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, producing a CVSS v3.1 score of 9.8 Critical. Other historical assessments remain visible in vulnerability databases, which explains why some older pages still identify CVE-2025-25249 as a 7.4 or 8.1 vulnerability. (CVE.report)

What Is CVE-2025-25249?

CVE-2025-25249 is a memory corruption vulnerability affecting the Fortinet cw_acd process.

Fortinet originally disclosed the issue through advisory FG-IR-25-084. The CVE record describes the bug as a heap-based buffer overflow capable of allowing unauthorized code or command execution through specially crafted packets.

The affected component handles CAPWAP-related communication. CAPWAP, or Control And Provisioning of Wireless Access Points, is used by controllers and network infrastructure to discover, configure, and manage wireless access points.

In affected Fortinet deployments, the cw_acd daemon processes this traffic. According to analysis of observed exploitation, the service can listen for CAPWAP control traffic on UDP port 5246. (SOCRadar® Cyber Intelligence Inc.)

The security problem occurs when maliciously constructed input reaches vulnerable packet-processing logic and corrupts heap memory.

That distinction matters.

This is not fundamentally a stolen-password vulnerability, a weak authentication mechanism, or a web administrator login bypass. Attackers can potentially interact directly with a network-facing service before any legitimate Fortinet user authenticates.

Once reliable memory corruption has been converted into controlled execution, the attacker can move from:

malicious network packet
        ↓
vulnerable CAPWAP processing
        ↓
heap memory corruption
        ↓
control-flow manipulation
        ↓
attacker-controlled execution

The consequence can be remote code execution on a device that often occupies one of the most privileged positions in an enterprise network.

Why a Fortinet Heap Overflow Is Especially Dangerous

Heap-based buffer overflows occur when software writes more data into a dynamically allocated memory region than the program intended that region to hold.

A simplified representation looks like this:

Heap memory

+-----------------------+
| Expected packet data  |
| 256-byte allocation   |
+-----------------------+
| Adjacent heap object  |
+-----------------------+
| Function/data state   |
+-----------------------+

If vulnerable code assumes that input will fit into the original allocation but copies a larger attacker-controlled structure, memory beyond the intended buffer can be overwritten:

Attacker-controlled input
              |
              v

+-----------------------+
| Expected data         |
+-----------------------+
| OVERFLOW DATA >>>>>>> |
+-----------------------+
| Corrupted heap state  |
+-----------------------+

A crash is one possible result.

Remote code execution is the more dangerous one.

An attacker who understands how objects, pointers, allocator metadata, executable code locations, and relevant runtime structures are laid out may be able to transform the corruption primitive into control over program execution.

This is why CWE-122 vulnerabilities vary dramatically in real-world severity. Some produce little more than denial of service. Others become highly reliable RCE chains.

CVE-2025-25249 has now crossed that boundary in operational terms: public threat reporting describes successful exploitation resulting in post-exploitation malware deployment.

Why the Vulnerability Matters More on a Firewall

The placement of the vulnerable software changes the security equation.

A compromised desktop is serious.

A compromised firewall can be considerably worse.

FortiGate appliances frequently sit between the Internet and critical internal services. Depending on configuration, they may terminate VPN sessions, contain network routing information, store authentication-related configuration, handle IPsec relationships, enforce segmentation policies, and observe or control traffic entering and leaving protected networks.

That means compromise of the perimeter device can undermine assumptions defenders normally rely on.

Instead of an attacker being outside the firewall attempting to bypass it, the attacker may effectively gain execution on the firewall itself.

The security model becomes:

Before compromise

Internet
   |
   v
[ FortiGate ]
   |
   | security boundary
   v
Internal Network


After firewall compromise

Internet
   |
   v
[ Attacker-controlled FortiGate ]
   |
   +------> Internal systems
   |
   +------> VPN infrastructure
   |
   +------> Network discovery
   |
   +------> Credential material

That makes edge-device RCE vulnerabilities particularly attractive for initial access operations.

Which Versions Are Affected by CVE-2025-25249?

Current vulnerability records identify the following FortiOS branches as affected.

Product	Vulnerable Versions	Fixed Version
FortiOS 6.4	6.4.0–6.4.16	6.4.17 or later
FortiOS 7.0	7.0.0–7.0.17	7.0.18 or later
FortiOS 7.2	7.2.0–7.2.11	7.2.12 or later
FortiOS 7.4	7.4.0–7.4.8	7.4.9 or later
FortiOS 7.6	7.6.0–7.6.3	7.6.4 or later
FortiSwitchManager 7.0	7.0.0–7.0.5	7.0.6 or later
FortiSwitchManager 7.2	7.2.0–7.2.6	7.2.7 or later

Fortinet-related vulnerability data also identifies affected FortiSASE releases, including the vulnerable 25.1 and 25.2 branches. Earlier mitigation guidance indicated that FortiSASE 25.2.b was remediated in 25.2.c, while affected 25.1 deployments should migrate to a fixed release. (Qualys ThreatPROTECT)

FortiOS 7.2.12 release notes specifically list CVE-2025-25249 among vulnerabilities for which that release is no longer vulnerable, providing an additional vendor release-level confirmation of remediation for that branch. (Fortinet Web)

Administrators should still verify their precise upgrade path through Fortinet’s current support documentation because supported release trains, hardware compatibility, and recommended upgrade sequences may differ by appliance model.

Why CVE-2025-25249 Has Several Different CVSS Scores

Anyone researching CVE-2025-25249 will quickly notice something confusing.

One source may say:

7.4 High

Another:

8.1 High

And another:

9.8 Critical

This does not necessarily mean one of them is fabricated.

The CVE has accumulated multiple assessments over time.

One Fortinet/CNA-oriented assessment treats exploitation as requiring high attack complexity:

AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

That results in an 8.1 base score before temporal adjustments. Some records also display a 7.4 temporal assessment.

The current NVD assessment instead assigns Low attack complexity:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

This produces:

CVSS 9.8 Critical

The difference centers heavily on AC:H versus AC:L. (CVE.report)

This disagreement is worth understanding, but defenders should not allow it to distract from the stronger operational evidence.

CISA says the vulnerability is being actively exploited.

A working exploit framework has been analyzed.

Actual compromised devices have been documented.

Once exploitation moves from hypothetical to observed, arguing about whether the base score should be 8.1 or 9.8 becomes much less important to patch prioritization.

CISA Has Confirmed Active Exploitation

The most important update to CVE-2025-25249 occurred on September 9, 2026.

CISA added the flaw to its Known Exploited Vulnerabilities Catalog, describing it as a heap-based buffer overflow affecting Fortinet FortiOS, FortiSwitchManager, and FortiSASE and capable of unauthorized code or command execution through specially crafted packets.

CISA only adds vulnerabilities to KEV when there is evidence that they have been exploited in the wild.

The agency assigned a remediation deadline of September 12, 2026 to federal civilian agencies and also calls for forensic triage as part of the response guidance. (Deja Vu)

That classification changes how organizations should prioritize the vulnerability.

A conventional vulnerability management queue might rank findings using:

CVSS
+
asset criticality
+
Internet exposure
+
EPSS

CVE-2025-25249 now adds another, much stronger signal:

confirmed exploitation

A better prioritization model is therefore:

Known exploited
        +
unauthenticated
        +
network reachable
        +
edge infrastructure
        +
RCE impact
        =
emergency remediation priority

Exploitation May Have Started Months Before the KEV Listing

The CISA KEV date should not be interpreted as the beginning of exploitation.

It represents the date CISA added the vulnerability to the catalog.

SOCRadar’s threat research says activity associated with CVE-2025-25249 could be traced to at least July 2026, approximately two months before the September KEV update. (SOCRadar® Cyber Intelligence Inc.)

That timing has important incident-response implications.

Organizations should not only ask:

Are we vulnerable today?

They should also ask:

Was this device externally reachable while vulnerable at any point since at least July 2026?

If the answer is yes, merely installing the latest firmware does not prove the appliance was never compromised.

Patching removes the vulnerability.

It does not retroactively remove persistence, stolen credentials, leaked configuration data, attacker-created tunnels, or access established elsewhere in the environment before the patch.

How the Observed CVE-2025-25249 Exploit Works

Threat researchers investigating the campaign recovered an exploit framework referred to as fortirun.bin.

According to SOCRadar’s technical analysis, it packaged a Python runtime and exploit modules used to attack vulnerable FortiGate systems through CAPWAP.

The observed exploit targeted the CAPWAP daemon on UDP 5246. It first fingerprinted the target to determine hardware and firmware information, then selected compatible exploitation parameters for vulnerable builds. (SOCRadar® Cyber Intelligence Inc.)

At a high level, the chain looked approximately like this:

1. Identify reachable FortiGate
             ↓
2. Send CAPWAP discovery traffic
             ↓
3. Determine hardware / firmware build
             ↓
4. Select compatible exploit profile
             ↓
5. Trigger heap corruption
             ↓
6. Gain code execution
             ↓
7. Launch post-exploitation payload
             ↓
8. Connect outward to attacker C2

This explains why exploitation may be reliable only against specific firmware and appliance combinations even though the underlying vulnerability affects a broader set of versions.

Reliable memory corruption exploitation often requires a detailed understanding of the exact binary being attacked.

Different firmware releases can alter:

• executable layouts;
• library addresses;
• compiler output;
• heap behavior;
• allocator structures;
• available code-reuse primitives;
• mitigations;
• function locations.

The exploit recovered in the campaign reportedly included a compatibility table for specific devices and vulnerable FortiOS 7.4 builds rather than treating every Fortinet device as identical. (SOCRadar® Cyber Intelligence Inc.)

That does not make unsupported vulnerable versions safe.

It only means the specific exploit analyzed by researchers had a finite set of supported targets.

Attack tooling evolves.

CAPWAP and UDP 5246 Are Central to the Attack Surface

CAPWAP is particularly important when evaluating exposure.

SOCRadar’s analysis states that the vulnerable cw_acd daemon listens on UDP 5246, which is the CAPWAP control port used by the observed exploit. (SOCRadar® Cyber Intelligence Inc.)

Fortinet mitigation guidance reproduced by multiple security vendors recommends restricting UDP 5246–5249 when administrators cannot immediately patch.

Shadowserver similarly notes that exploitation is believed to require one of these CAPWAP-related ports to be reachable. It therefore distinguishes between a device merely running vulnerable firmware and a device that is actually reachable through the vulnerable service. (Shadowserver)

That creates three useful risk tiers.

Vulnerable and Internet Exposed

Internet
   |
UDP 5246-5249 reachable
   |
   v
Vulnerable FortiGate

Highest priority.

These systems should be patched or isolated immediately.

Vulnerable but CAPWAP Restricted to Trusted Networks

Internet
   X
   |
CAPWAP blocked externally

Trusted management network
   |
   v
Vulnerable device

Risk is lower than direct Internet exposure but the underlying vulnerability still exists.

Compromised internal systems or misconfigured trust boundaries could potentially reach the service.

Patched

Internet
   |
   v
Fixed FortiOS release

This is the desired state.

Restricting reachability is useful defense in depth, but it should not replace patching where an update is available.

Why Security Fabric Configuration Matters

On FortiGate, Security Fabric functionality can expose relevant services on selected interfaces.

Fortinet’s own technical documentation explains that newer FortiOS releases combine FortiTelemetry and CAPWAP-related access under the Security Fabric Connection configuration and represent it through allowaccess fabric on an interface. (Fortinet Community)

For example, a configuration may conceptually contain:

config system interface
    edit "port1"
        set allowaccess fabric ssh https
    next
end

For CVE-2025-25249, administrators should pay particular attention to whether fabric access is unnecessarily enabled on externally reachable interfaces.

A quick configuration review can begin with commands such as:

show system interface

or filtering relevant configuration output:

show system interface | grep allowaccess

The goal is not simply to determine whether Security Fabric exists somewhere in the network.

The important question is:

Which interfaces accept that traffic, and from which source networks can those interfaces be reached?

The Real-World Attack Chain Goes Beyond Initial RCE

The observed campaign demonstrates why CVE-2025-25249 should not be understood as simply “an attacker might crash the firewall.”

Researchers reported that attackers used exploitation to deploy a Node.js-based remote access tool known as PivotC2.

SOCRadar describes PivotC2 as a FortiGate-focused post-exploitation framework supporting functionality including interactive command execution, file transfer, proxy tunneling, port forwarding, network scanning, configuration harvesting, and credential-related operations. (SOCRadar® Cyber Intelligence Inc.)

The resulting attack path resembles:

CVE-2025-25249
      ↓
FortiGate code execution
      ↓
PivotC2 deployment
      ↓
Outbound encrypted C2
      ↓
Configuration harvesting
      ↓
Credential access
      ↓
Internal network discovery
      ↓
Proxy / tunnel creation
      ↓
Lateral movement
      ↓
Data collection and exfiltration

This is much closer to a full intrusion platform than a simple proof of concept.

PivotC2 Turns the Firewall Into an Attacker Pivot Point

The name PivotC2 is appropriate because the malware is designed to turn the compromised appliance into a staging point for deeper network access.

SOCRadar reported that the malware establishes an outbound TLS connection to attacker infrastructure.

This architecture matters because enterprise firewall policies are usually much more restrictive for inbound connections than for outbound connections.

Consider the difference.

An inbound shell requires:

Attacker
   |
   | incoming connection
   v
Victim

A reverse connection works the other way:

Victim
   |
   | outbound TLS
   v
Attacker C2

Once the compromised appliance initiates the session, the attacker’s control channel can be substantially harder to distinguish from legitimate encrypted outbound traffic.

PivotC2 reportedly multiplexes functions over that connection and can provide proxying and port-forwarding functionality, making the edge appliance useful for reaching systems that were never directly exposed to the Internet. (SOCRadar® Cyber Intelligence Inc.)

Why Configuration Theft May Be as Dangerous as the Initial Compromise

A FortiGate configuration can contain highly sensitive operational information.

Depending on deployment, attackers may obtain or infer information relating to:

• administrators;
• VPN configuration;
• IPsec relationships;
• LDAP integrations;
• wireless credentials;
• internal network ranges;
• routing topology;
• authentication infrastructure;
• firewall objects;
• segmentation policies.

SOCRadar specifically recommends broad credential rotation when PivotC2 evidence is found because compromised configuration data may expose secrets beyond the appliance itself. (SOCRadar® Cyber Intelligence Inc.)

This is an important incident-response principle:

Reimaging the firewall does not automatically invalidate credentials that were already stolen.

If forensic evidence indicates compromise, response should include both device recovery and secret rotation.

Reported PivotC2 Campaign Scale

SOCRadar said files recovered during its investigation contained a list of more than 30,000 FortiGate IP addresses and identified 178 confirmed PivotC2 victim sessions.

Those figures belong specifically to the dataset and campaign analyzed by that research team. They should not be interpreted as a global count of all CVE-2025-25249 exploitation. (SOCRadar® Cyber Intelligence Inc.)

The distinction is important.

It would be inaccurate to claim:

CVE-2025-25249 compromised exactly 178 organizations.

A more defensible conclusion is:

One analyzed campaign contained evidence of 178 confirmed infected sessions among a much larger targeting dataset.

Other campaigns could exist independently.

How to Determine Whether Your FortiGate Is Vulnerable

Defenders should evaluate three separate questions.

1. Is the Firmware Vulnerable?

Begin by identifying the running FortiOS version.

For example:

get system status

Compare the result against the patched thresholds:

6.4  → 6.4.17+
7.0  → 7.0.18+
7.2  → 7.2.12+
7.4  → 7.4.9+
7.6  → 7.6.4+

A device running an older affected build is vulnerable regardless of whether it is currently Internet reachable.

2. Is the Relevant Service Reachable?

Review interface configuration:

show system interface

Look for interfaces permitting Security Fabric access.

Then review local-in policies and upstream ACLs to determine whether untrusted sources can reach CAPWAP-related services.

UDP ports deserving particular attention include:

5246
5247
5248
5249

Do not assume that because an administrative web interface is not reachable, the appliance is safe.

CVE-2025-25249 is not fundamentally an HTTPS admin-console vulnerability.

3. Was It Reachable Before You Patched?

This question is frequently overlooked.

Suppose an organization runs FortiOS 7.4.8 from June through September.

On September 10, it upgrades to 7.4.9.

Current vulnerability scanners now show:

Not vulnerable

That is good, but it does not answer whether exploitation occurred in August.

Because active exploitation has been reported dating back to at least July 2026, historically exposed devices deserve additional review. (SOCRadar® Cyber Intelligence Inc.)

Threat Hunting for CVE-2025-25249

Organizations that operated exposed vulnerable appliances should move beyond version checking and perform targeted threat hunting.

Several areas deserve attention.

Search for Unexpected Outbound Connections

A firewall that suddenly initiates persistent TLS connections to unfamiliar Internet infrastructure deserves investigation.

Review historical traffic telemetry where available for:

FortiGate → unknown external IP
FortiGate → unusual high ports
long-lived TLS connections
new destinations first observed during the exposure window

The goal should not be to block only currently published indicators.

Attackers can move C2 infrastructure.

Behavioral anomalies are more durable.

Inspect Running Processes

Researchers specifically observed Node.js-based post-exploitation tooling.

Where appropriate within an approved investigation, administrators can review process information for unexpected Node-related execution.

For example:

diagnose sys process list | grep node

The absence of Node.js is not proof of safety, but unexplained Node processes on affected infrastructure warrant investigation.

Inspect Temporary Files

The researched PivotC2 chain used temporary filesystem artifacts, including a path identified as:

/tmp/.i.js

SOCRadar recommends examining temporary directories and this artifact when hunting the observed campaign. (SOCRadar® Cyber Intelligence Inc.)

A defensive check can include:

fnsysctl ls -la /tmp/

and, where appropriate:

fnsysctl ls -la /tmp/.i.js

Again, an attacker can change filenames.

A missing known artifact should never be treated as a clean bill of health.

Examine Configuration Changes

Review for unexplained modifications involving:

• administrators;
• interfaces;
• routes;
• firewall policies;
• VPN configuration;
• local-in policies;
• Security Fabric settings;
• automation;
• certificates;
• authentication sources.

Any unexplained configuration modification occurring while the vulnerable service was externally reachable should be investigated.

Look Beyond the Firewall

Because PivotC2 supports proxying and internal reconnaissance, defenders should also review adjacent infrastructure.

Look for:

FortiGate
   ↓
internal scanning

FortiGate
   ↓
unexpected SMB/RDP/SSH connections

FortiGate
   ↓
administrative access to internal systems

The edge device may only represent the first stage of the intrusion.

Indicators From the Reported PivotC2 Campaign

SOCRadar published several network indicators associated with the campaign it analyzed, including:

46[.]151[.]29[.]58
146[.]103[.]99[.]177

and additional infrastructure associated with tunneling activity. (SOCRadar® Cyber Intelligence Inc.)

Indicators of compromise are useful for historical searches, but defenders should avoid building their entire detection strategy around two IP addresses.

The ideal process is:

Known IoCs
    +
behavioral detection
    +
device forensics
    +
configuration review
    +
identity review
    =
higher-confidence assessment

A sophisticated attacker can replace infrastructure quickly.

The exploitation behavior and post-exploitation consequences matter more than any single IP.

Patch CVE-2025-25249 Immediately

The strongest remediation is straightforward:

Upgrade affected Fortinet systems to a fixed release.

The primary fixed FortiOS versions are:

FortiOS 6.4.17+
FortiOS 7.0.18+
FortiOS 7.2.12+
FortiOS 7.4.9+
FortiOS 7.6.4+

For FortiSwitchManager:

7.0.6+
7.2.7+

These remediation thresholds are consistently reflected across Fortinet advisory-derived security guidance and FortiOS release information. (Kudelski Security)

Administrators should follow Fortinet’s supported upgrade path for their hardware rather than blindly jumping between major FortiOS branches.

Before upgrading production perimeter devices, teams should also ensure they have:

• current configuration backups;
• tested recovery procedures;
• maintenance-window approval;
• console or out-of-band access;
• HA failover planning where relevant;
• rollback procedures;
• monitoring during and after the upgrade.

However, normal maintenance conservatism should be balanced against the fact that CVE-2025-25249 is already actively exploited.

Delaying remediation for weeks in pursuit of a perfectly convenient maintenance window may create a larger business risk than the upgrade itself.

What If You Cannot Patch Immediately?

Fortinet provided mitigations for environments that cannot immediately update.

The first option is to remove unnecessary fabric access from exposed interfaces.

Conceptually, an interface configured like:

set allowaccess fabric ssh https

can be changed, when Security Fabric connectivity is not needed there, to exclude fabric:

set allowaccess ssh https

Security vendors reproducing Fortinet’s advisory guidance also describe using local-in policy controls to restrict CAPWAP traffic on UDP ports 5246–5249 to explicitly trusted systems and deny other sources. (Qualys ThreatPROTECT)

The design should resemble:

Trusted CAPWAP devices
        |
        | UDP 5246-5249
        v
     ALLOW
        |
   FortiGate

All other sources
        |
        | UDP 5246-5249
        v
      DENY

This is much safer than:

Internet
   |
   | UDP 5246-5249
   v
 FortiGate

But mitigation should be treated as temporary.

It reduces reachability.

It does not remove the vulnerable code.

Why Blocking Only UDP 5246 Is Not the Best Strategy

The observed exploit described by SOCRadar uses UDP 5246.

However, Fortinet’s broader mitigation guidance references CAPWAP-related UDP ports 5246–5249. (Qualys ThreatPROTECT)

Therefore defenders should avoid making their mitigation unnecessarily narrow.

Instead of:

block UDP/5246

evaluate whether the network legitimately requires any untrusted access to:

UDP/5246-5249

A default-deny approach with explicit trusted source allowlisting is generally safer.

Patch Management Is Only Half the Response

Because exploitation is confirmed, organizations should divide response into two tracks.

Track A: Vulnerability Remediation

inventory
   ↓
identify vulnerable versions
   ↓
restrict CAPWAP exposure
   ↓
upgrade firmware
   ↓
verify version

Track B: Compromise Assessment

historical exposure review
   ↓
network telemetry search
   ↓
filesystem/process review
   ↓
configuration audit
   ↓
credential review
   ↓
internal lateral movement hunt

Organizations often perform Track A and stop.

That is appropriate for vulnerabilities with no evidence of exploitation when exposure was minimal.

It is less appropriate for an actively exploited edge-device RCE.

If You Find Evidence of Compromise

Evidence of PivotC2 or suspicious execution should trigger a broader incident-response process.

The appliance should no longer be treated as trustworthy simply because a malicious process was terminated.

Attackers may have obtained configuration data or credentials and established access to other systems.

A reasonable response sequence is:

1. Contain the affected appliance
2. Preserve evidence where possible
3. Identify attacker activity
4. Determine the exposure window
5. Recover or rebuild from trusted state
6. Upgrade to a fixed release
7. Rotate potentially exposed credentials
8. Review VPN/IPsec secrets
9. Hunt internal systems
10. Monitor for re-entry

SOCRadar specifically recommends rotating administrative passwords, SSL-VPN credentials, LDAP-related secrets, wireless pre-shared keys, and IPsec pre-shared keys where compromise is suspected because the observed malware included configuration-harvesting functionality. (SOCRadar® Cyber Intelligence Inc.)

Do Not Trust a Clean Vulnerability Scan as Proof of No Compromise

This distinction is critical.

After upgrading from:

FortiOS 7.4.8

to:

FortiOS 7.4.9

a vulnerability scanner should correctly report CVE-2025-25249 as remediated.

But the result means:

The currently installed software should no longer be vulnerable.

It does not mean:

This appliance was never exploited.

Those are completely different questions.

Vulnerability management answers the first.

Incident response answers the second.

Why Edge Devices Are Valuable Initial-Access Targets

CVE-2025-25249 fits a broader attacker strategy that defenders should understand.

Firewalls, VPN gateways, routers, load balancers, and other edge appliances share several characteristics.

They are frequently:

• Internet reachable;
• always online;
• highly privileged;
• centrally trusted;
• capable of reaching multiple internal networks;
• poorly instrumented compared with workstations;
• excluded from normal EDR coverage.

A typical endpoint may run:

EDR
application control
PowerShell logging
Sysmon
identity telemetry
email security

A network appliance may expose far less endpoint-level telemetry.

Attackers therefore gain a useful asymmetry.

Publicly reachable
      +
privileged location
      +
limited EDR visibility
      +
valuable credentials
      =
high-value intrusion target

CVE-2025-25249 demonstrates this dynamic particularly well.

Why the Heap Overflow Matters to Exploit Reliability

Modern memory corruption exploitation is rarely as simple as sending an oversized string and immediately receiving a shell.

Operating systems and compilers commonly deploy mitigations such as:

• ASLR;
• non-executable memory;
• stack protections;
• hardened allocators;
• control-flow protections.

Attackers must therefore construct exploitation chains around the exact runtime environment.

The recovered CVE-2025-25249 tooling reportedly fingerprinted firmware and hardware before exploitation and used target-specific information for compatible builds. (SOCRadar® Cyber Intelligence Inc.)

This tells defenders something important.

The attacker invested in exploit engineering, not just vulnerability scanning.

Once that engineering has been performed, however, the operational cost of attacking additional matching devices can fall dramatically.

The economics change from:

Research each target manually

to:

fingerprint
   ↓
match profile
   ↓
attempt exploitation
   ↓
deploy payload

That is why reliable exploit automation against edge appliances can quickly turn one vulnerability into a campaign.

CVE-2025-25249 Exploitation Can Be Automated

SOCRadar reported that the observed operation used Bash and Python tooling around the exploit and performed repeated exploitation attempts. (SOCRadar® Cyber Intelligence Inc.)

This matters because exploitation at scale does not require an operator to manually interact with every firewall.

A campaign architecture can conceptually be:

Target list
    |
    v
Reachability check
    |
    v
Firmware fingerprint
    |
    v
Compatible?
 /       \
No       Yes
|         |
skip      v
      exploitation
          |
          v
        payload
          |
          v
        C2

This is precisely the sort of automation that makes Internet-facing infrastructure dangerous to leave unpatched after public exploitation becomes available.

EPSS Should Not Override Known Exploitation

At the time of writing, public vulnerability intelligence sources place the EPSS probability for CVE-2025-25249 around 2.4%, roughly in the 83rd percentile. (PatchCVE)

Someone looking only at the percentage could conclude that 2.4% sounds relatively small.

That interpretation would be misguided here.

EPSS estimates the probability of exploitation activity using its statistical model.

CISA KEV gives us something stronger:

Exploitation has already been observed.

Once a vulnerability is confirmed exploited in relevant threat activity, organizations should not downgrade it because a probabilistic model produces a lower-looking number.

The correct hierarchy is closer to:

Confirmed compromise evidence
        >
Known exploited status
        >
credible exploit availability
        >
exposure
        >
EPSS prediction
        >
CVSS alone

All of these signals are useful.

They answer different questions.

Risk Prioritization for Different Environments

Not every Fortinet deployment carries identical risk.

Critical Priority

Patch immediately if all of the following are true:

affected FortiOS
+
CAPWAP/Fabric reachable from Internet
+
production perimeter appliance

Very High Priority

Also patch immediately where:

affected version
+
reachable from semi-trusted networks
+
critical internal routing/security role

High Priority

Even a device whose CAPWAP interfaces appear isolated should still be updated because the vulnerable code remains present.

Internal compromise can turn trusted network access into an attack path.

Already Patched

If the device was previously exposed while vulnerable, consider historical threat hunting despite the current fixed version.

Defensive Exposure Validation

External vulnerability assessment can help determine whether an Internet-facing appliance appears to be running an affected FortiOS version.

However, active testing against network appliances should always be authorized and designed to avoid service disruption.

For most production environments, defenders should prefer a combination of:

configuration inspection
+
authenticated version inventory
+
network reachability analysis
+
passive telemetry

over blindly sending exploit-like packets.

The objective is to answer:

1. What version is running?
2. Is fabric access enabled?
3. On which interface?
4. Who can reach UDP 5246–5249?
5. Was this true historically?
6. Is there evidence of suspicious post-exploitation behavior?

Those questions provide far more value than simply receiving a scanner result reading “CVE detected.”

How to Validate Remediation

After patching, defenders should verify each layer.

Verify Firmware

Confirm the appliance is running the intended fixed release:

get system status

Verify Interface Exposure

Review interface permissions:

show system interface

Unnecessary Security Fabric access should remain disabled even after patching.

Patching should not become an excuse to preserve unnecessary attack surface.

Verify Network Controls

From appropriate authorized test points, confirm CAPWAP-related ports are unreachable from networks that do not require them.

Recheck HA Members

High-availability clusters introduce a common operational mistake:

node A patched
node B overlooked

Inventory every member rather than assuming the cluster reflects one software state.

Check Management Inventory

Compare:

CMDB
FortiManager inventory
vulnerability scanner
network inventory

Disagreement often reveals forgotten appliances.

Recommended Incident Response Decision Tree

A practical CVE-2025-25249 response can be summarized as:

Is Fortinet product affected?
            |
       +----+----+
       |         |
      No        Yes
       |         |
   monitor       v
          Is it patched?
              |
         +----+----+
         |         |
        Yes        No
         |         |
         |       PATCH NOW
         |
         v
 Was vulnerable system externally
 reachable before patching?
         |
    +----+----+
    |         |
   No        Yes
    |         |
 normal      v
monitoring  threat hunt
             |
             v
      compromise evidence?
             |
        +----+----+
        |         |
       No        Yes
        |         |
 heightened      IR +
 monitoring      credential
                 rotation

This approach avoids both extremes.

You do not need to assume every vulnerable FortiGate has been compromised.

But you also should not assume patching today proves compromise did not happen yesterday.

Frequently Asked Questions About CVE-2025-25249

Is CVE-2025-25249 a FortiGate vulnerability?

Yes. FortiGate appliances running affected FortiOS versions are among the primary systems at risk because the vulnerable cw_acd daemon exists in FortiOS.

The CVE also covers FortiSwitchManager and relevant FortiSASE releases.

Is CVE-2025-25249 remotely exploitable?

Yes.

The vulnerability involves network-accessible packet handling and can allow an unauthenticated remote attacker to execute unauthorized code or commands.

Does CVE-2025-25249 require authentication?

No authentication is required according to the published vulnerability characteristics.

That significantly increases its risk.

Does exploitation require user interaction?

No.

The CVSS assessments identify user interaction as UI:N.

What port does CVE-2025-25249 use?

The observed exploit targeted the CAPWAP control service on UDP 5246.

Fortinet mitigation guidance covers CAPWAP control traffic across UDP 5246–5249, so defenders should review the full range rather than only port 5246. (SOCRadar® Cyber Intelligence Inc.)

Is CVE-2025-25249 being exploited in the wild?

Yes.

CISA added CVE-2025-25249 to the Known Exploited Vulnerabilities Catalog on September 9, 2026 based on evidence of active exploitation. (Deja Vu)

When did exploitation begin?

CISA’s KEV addition occurred on September 9, but SOCRadar’s investigation says the activity it observed could be traced back to at least July 2026. (SOCRadar® Cyber Intelligence Inc.)

Is there a public exploit for CVE-2025-25249?

Detailed threat research has documented functioning exploit tooling recovered from real-world activity.

That is more operationally important than whether a polished public proof-of-concept repository exists.

What is PivotC2?

PivotC2 is a Node.js-based post-exploitation remote access tool identified in attacks involving CVE-2025-25249.

It includes capabilities for interactive command execution, file transfer, network tunneling, scanning, FortiGate configuration collection, and credential-related operations. (SOCRadar® Cyber Intelligence Inc.)

Is CVE-2025-25249 used by ransomware groups?

CISA currently lists known ransomware use as unknown.

That does not mean ransomware use is impossible; it means CISA has not classified the CVE as known to be used in ransomware campaigns in its KEV record. (Deja Vu)

Is CVE-2025-25249 Critical or High severity?

Both labels appear in historical databases because different CVSS assessments exist.

The current NVD assessment is CVSS 9.8 Critical, using low attack complexity. Other Fortinet/CNA-derived scoring records use high attack complexity and produce lower ratings such as 8.1. (CVE.report)

For operational prioritization, confirmed exploitation is more important than that scoring disagreement.

Does blocking UDP 5246 completely fix the vulnerability?

No.

Blocking or restricting CAPWAP traffic can reduce exposure, but the vulnerable code remains installed.

Patching to a fixed FortiOS or FortiSwitchManager version is the preferred remediation.

If my FortiGate was patched before September 9, am I safe?

Not necessarily based solely on the KEV date.

Threat research indicates exploitation may have existed since at least July 2026.

If the appliance was vulnerable and exposed during that period, historical review is advisable.

Should credentials be rotated after patching?

Not automatically for every patched firewall.

However, if there is credible evidence that the appliance was compromised, administrators should assume sensitive configuration data may have been accessed and rotate relevant credentials and shared secrets.

CVE-2025-25249 Changes the Risk Calculation for Fortinet Defenders

CVE-2025-25249 is a good example of why vulnerability management cannot stop at a CVSS score.

When the vulnerability was first disclosed in January 2026, organizations could reasonably evaluate it using the usual combination of severity, exposure, and upgrade planning.

By September, the situation had changed.

There is now:

an unauthenticated network vulnerability
        +
heap memory corruption
        +
remote code execution
        +
Fortinet edge infrastructure
        +
working exploit tooling
        +
post-exploitation malware
        +
documented victims
        +
CISA KEV confirmation

That combination warrants a different response.

The right question is no longer:

Should we patch CVE-2025-25249 in the next maintenance cycle?

For exposed affected systems, the better questions are:

Why is this appliance still vulnerable?

and:

Was it already attacked before we patched it?

Final Assessment

CVE-2025-25249 should be treated as a critical, actively exploited Fortinet remote code execution vulnerability.

The underlying flaw is a heap-based buffer overflow in the cw_acd daemon used for CAPWAP processing. Remote attackers can target vulnerable FortiOS and related Fortinet systems without authentication using specially crafted network traffic.

The risk is amplified by where FortiGate devices live in enterprise architecture. Compromise of an Internet-facing firewall can provide attackers with a powerful foothold for tunneling, configuration theft, credential access, internal discovery, lateral movement, and data exfiltration.

CISA’s September 9, 2026 addition of CVE-2025-25249 to the Known Exploited Vulnerabilities Catalog removes any remaining uncertainty about whether exploitation is merely theoretical. (dejavu.org)

Organizations should therefore prioritize three actions:

1. Upgrade every affected FortiOS, FortiSwitchManager, and relevant FortiSASE deployment to a fixed release.
2. Remove unnecessary Security Fabric/CAPWAP exposure, particularly from Internet-facing interfaces, and restrict UDP 5246–5249 to explicitly trusted systems where required.
3. Threat-hunt historically exposed appliances, particularly systems that remained vulnerable from July 2026 onward, and perform broader incident response and credential rotation if compromise indicators are discovered.

The broader lesson extends beyond this single Fortinet CVE.

Once a vulnerability affecting perimeter infrastructure moves from disclosure to reliable exploitation, defenders are racing against operationalized attacker tooling rather than against a theoretical vulnerability score.

For CVE-2025-25249, that transition has already happened.