CISA confirmed exploitation of CVE-2025-25249 across FortiOS, FortiSwitchManager and FortiSASE, with federal remediation due September 12.2026-09-11T12:10:03.433Z5 min2026networkthreats
5 min read
Read format

Attackers Exploit Fortinet Flaw That Lets Crafted Packets Run Code

CISA confirmed exploitation of CVE-2025-25249 across FortiOS, FortiSwitchManager and FortiSASE, with federal remediation due September 12.

By Justin Howe
An abstract network appliance with a bright packet pulse crossing exposed memory layers, without product logos or interface text.

CISA added CVE-2025-25249 to its Known Exploited Vulnerabilities catalog on September 9, 2026, confirming that attackers are exploiting the Fortinet heap-buffer-overflow flaw. The agency set September 12 as the remediation deadline for covered federal systems and marked the vulnerability for forensic triage under Binding Operational Directive 26-04.

The affected products sit at sensitive network boundaries: FortiOS, FortiSwitchManager and the FortiSASE service. Fortinet’s CNA record says a remote, unauthenticated attacker can reach the flaw with a specially crafted packet. Organizations running affected releases should fold version discovery and internet-exposure review into immediate incident-response work.

Crafted Packets Reach Privileged Appliances

Fortinet describes CVE-2025-25249 as a heap buffer overflow. In practical terms, a packet can cause the vulnerable process to write beyond the memory region allocated for its data. Successful exploitation can redirect execution inside the appliance.

The Fortinet-authored CNA record says the issue “allows attacker to execute unauthorized code or commands via specially crafted packets.” Its CVSS 3.1 rating is 7.4 High, with a network attack vector, no privileges or user interaction required, and high potential impact to confidentiality, integrity and availability. Attack complexity is rated high, which describes the conditions needed for exploitation; CISA’s catalog entry establishes that exploitation has nevertheless occurred.

A vulnerable management or security appliance may inspect, route or control traffic for many downstream systems. An exposure review should therefore include the running release, the reachable interfaces and the management path for every applicable appliance, including devices already scheduled for an operating-system refresh.

Matrix showing published affected Fortinet release ranges and the remediated targets listed in the linked primary records.

Figure details

The matrix groups FortiOS, FortiSwitchManager and FortiSASE by remediation target. It pairs the published FortiOS and FortiSwitchManager affected ranges with their first fixed releases. For FortiSASE, the linked primary records name the service and remediated versions but do not publish an affected-version range. FortiOS 6.4 is marked for migration because the CNA description lists every 6.4 release as affected and does not name a fixed 6.4 build.

Affected Branches Need Different Fixes

The fixed target depends on the branch.

The vulnerable FortiOS ranges are 7.6.0 through 7.6.3, 7.4.0 through 7.4.8, 7.2.0 through 7.2.11 and 7.0.0 through 7.0.17. Every FortiOS 6.4 release is listed as affected. Fortinet identifies the first fixed builds as 7.6.4, 7.4.9, 7.2.12 and 7.0.18. It lists FortiOS 8.0.0 as an upcoming solution, but a planned version is not a remediation path for a currently exposed appliance.

FortiSwitchManager 7.2.0 through 7.2.6 should move to 7.2.7 or later. Releases 7.0.0 through 7.0.5 should move to 7.0.6 or later. For FortiOS 6.4, the CNA record gives no fixed build in that line, so the defensible path is migration to a supported branch with a listed fixed version.

FortiSASE uses its own service-version numbering. CISA includes FortiSASE in the affected products, but the linked Fortinet CNA data does not publish an affected-version range for the service. Its solution field lists 25.2.c and 25.1.b as remediated and says customers do not need to act after the service remediation. Administrators should still confirm that the tenant reports a remediated service version.

The scale statement is broad in product coverage but narrow in public victim detail. Five FortiOS release lines and two FortiSwitchManager branches are affected, while CISA also names FortiSASE without a published affected-version count. Neither primary source provides a device count, victim count or geographic distribution.

Attack details remain undisclosed

CISA’s catalog confirms active exploitation, but the public entry does not name an actor, describe a campaign or say whether ransomware is involved. The catalog marks known ransomware campaign use as unknown. Fortinet’s CNA record supplies the vulnerability mechanics and version boundaries, not indicators of compromise or a post-exploitation sequence.

Without published indicators, defenders cannot use these sources to determine whether an appliance is clean or identify logs, files or processes that would confirm exploitation. CISA’s forensic-triage flag raises the required level of scrutiny for covered federal systems, while the public record stops short of prescribing product-specific artifacts.

Start recognition with facts the sources do establish. Build an inventory of deployed FortiOS and FortiSwitchManager releases, record the FortiSASE tenant version, and map each device to its externally reachable and administrative interfaces. Flag every running build inside an affected range. Preserve available appliance and network telemetry before making changes so an incident-response team can investigate without losing the local evidence that the public advisories do not provide.

Check the Running Release

Prioritize internet-reachable appliances and any device whose management plane is exposed beyond its intended administration network. Apply the fixed release for the installed branch: FortiOS 7.6.4, 7.4.9, 7.2.12 or 7.0.18 and later; FortiSwitchManager 7.2.7 or 7.0.6 and later. Migrate FortiOS 6.4 systems to a supported branch with a listed fix. Confirm FortiSASE reports 25.2.c or 25.1.b after the provider remediation.

The verification test is deliberately simple: query the version from the running appliance or tenant after maintenance, then independently compare that value with Fortinet’s affected ranges. The expected result is that no production device reports an affected build and no FortiOS 6.4 system remains in service. Record the observed running version, device or tenant identity, observation time and comparison result; a change ticket that names the intended package is only a claim until the live system reports the fixed release.

A fixed running version confirms that the patch is active. Investigating earlier exploitation is a separate task. Systems that were exposed while vulnerable still need the forensic triage appropriate to their environment, especially where CISA’s directive applies. The public sources justify urgent remediation and investigation. They do not justify declaring an exposed appliance uncompromised.

Primary sources

Continue reading

Article figurePinch or double-tap to zoom, then drag to pan.