CVE-2025-25249 was published on January 13, 2026. It was added to the CISA KEV catalog on September 9, 2026 — eight months later — with a three-day remediation deadline.
It's a heap overflow in FortiOS, FortiSwitchManager and FortiSASE, allowing code or command execution via crafted packets. Rated 8.1, it wasn't at the top of priority queues in January. It is now, because it's being exploited.
That gap is the real subject of this article.
The Vulnerability
| Field | Value |
|---|---|
| CVE | CVE-2025-25249 |
| CVSS 3.1 | 8.1 (HIGH) |
| Vector | AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H |
| Type | Heap-based buffer overflow (CWE-122) |
| Authentication | None |
| NVD published | 2026-01-13 |
| CISA KEV added | 2026-09-09 |
| CISA deadline | 2026-09-12 |
Description:
A heap-based buffer overflow vulnerability in Fortinet FortiOS 7.6.0 through 7.6.3, FortiOS 7.4.0 through 7.4.8, FortiOS 7.2.0 through 7.2.11, FortiOS 7.0.0 through 7.0.17, FortiOS 6.4 all versions, FortiSwitchManager 7.2.0 through 7.2.6, FortiSwitchManager 7.0.0 through 7.0.5 allows attacker to execute unauthorized code or commands via specially crafted packets.
What "AC:H" means — and doesn't
The score is dragged down by a single element: AC:H, high attack complexity. Everything else in the vector is at maximum: network, no privileges, no interaction, full impact.
"High complexity" in CVSS doesn't mean "so hard it's improbable". It means exploitation depends on conditions the attacker doesn't fully control — a particular memory state, a configuration, a race. For an opportunistic attacker scanning the internet, that's a real brake. For a group targeting a specific organisation with time on its hands, it's an engineering obstacle, not a barrier.
The KEV listing says precisely that: someone did the work.
Affected and Fixed Versions
| Product | Branch | Affected versions | First version outside range |
|---|---|---|---|
| FortiOS | 7.6 | 7.6.0 → 7.6.3 | 7.6.4 |
| FortiOS | 7.4 | 7.4.0 → 7.4.8 | 7.4.9 |
| FortiOS | 7.2 | 7.2.0 → 7.2.11 | 7.2.12 |
| FortiOS | 7.0 | 7.0.0 → 7.0.17 | 7.0.18 |
| FortiOS | 6.4 | all | see below |
| FortiSwitchManager | 7.2 | 7.2.0 → 7.2.6 | 7.2.7 |
| FortiSwitchManager | 7.0 | 7.0.0 → 7.0.5 | 7.0.6 |
| FortiSASE | — | Fortinet-operated | 25.1.39 / 25.1.51 per NVD |
⚠️ These numbers are bounds taken from NVD. Check the Fortinet PSIRT advisory for the recommended release on your branch — Fortinet often recommends a later build than the first fixed one.
The FortiOS 6.4 case deserves a mention: the description says "all versions". The 6.4 branch is end-of-support. If you're still on it, the answer isn't a patch but a migration to a maintained branch.
FortiSASE is a Fortinet-operated service: the fix is theirs to apply, but confirm your tenant's status with support.
Check your version:
get system status
Why Eight Months of Delay Don't Mean Eight Months of Safety
The pattern recurs across network gear, and it catches organisations that prioritise by score:
- January: the CVE lands at 8.1 with no known exploitation. It joins the backlog behind the 9.8s.
- Months pass: FortiGate fleets aren't updated at the pace of publications, because a firewall update interrupts traffic.
- September: exploitation is observed. Every device that hasn't moved since January is exposed — and there are many.
The gap between publication and exploitation didn't protect those who waited: it simply gave the attacker time to find the conditions that lowered the score.
This is the third Fortinet KEV addition we've covered this summer, after FortiSandbox and FortiOS in July. For a Fortinet estate, update cadence has to be continuous, not a one-off project.
Detection
- Unexpected reboots or process crashes: a failed heap overflow often takes the targeted service down before an attempt succeeds
- Unknown administrator accounts:
show system admin - Undocumented configuration changes: policies, VPN, routes, DNS servers
- Unusual files or scripts — on FortiOS, post-exploitation persistence has historically used the filesystem; the anti-persistence bypass documented in July shows this isn't theoretical
- Outbound traffic initiated by the device itself to destinations unrelated to its services
diagnose debug crashlog read
execute log filter category event
execute log display
Mitigation
1. Update to a fixed release on your branch
The CISA deadline was September 12. If it isn't done, it's the priority.
2. Reduce interface exposure
- Administrative interface never exposed to the internet: restrict with
trusted hosts - Disable unused services on external interfaces
3. Get off FortiOS 6.4
No temporary measure replaces a maintained branch.
4. If you suspect a compromise
- Verify firmware integrity with Fortinet's tooling
- Assume an update alone doesn't remove persistence already installed
- Rotate credentials: admin accounts, VPN keys, certificates, LDAP/RADIUS shared secrets
- Compare configuration against a backup from before the suspect period
Why Continuous Monitoring of Your Fortinet Estate Matters
An 8.1 CVE with no known exploitation triggers no alert for most teams. Eight months later, its KEV listing should trigger one immediately — but only if someone knows which versions run on each device at that moment.
With cveo.tech, inventory your Fortinet devices with exact versions, and get automatic alerts whenever a CVE affecting them enters the CISA KEV catalog — including the ones you legitimately left in the backlog.