Is CVE-2025-25249 (Fortinet Multiple Products Heap-based Buffer Overflow) being exploited in the wild?

Yes. CISA added CVE-2025-25249 to its Known Exploited Vulnerabilities catalogue on 9 September 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Fortinet FortiOS, FortiSwitchManager, and FortiSASE contain a heap-based buffer overflow vulnerability that allows an attacker to execute unauthorized code or commands via specially crafted packets.

What the KEV listing tells you about real-world exploitation

CISA’s KEV catalogue is the key signal here: a listing means CISA has reliable evidence that the flaw is being exploited, not just that it is theoretically dangerous. For this CVE, the practical takeaway is that exposure is no longer a watch-list issue, it is an active response issue. If your environment uses CISA Known Exploited Vulnerabilities Catalog as a prioritisation source, this entry should move immediately to the top of remediation queues.

The vulnerable products are Fortinet FortiOS, FortiSwitchManager, and FortiSASE, and the weakness is a heap-based buffer overflow that can permit unauthorized code or command execution when an attacker sends specially crafted packets. That means the risk is not limited to administrative misuse or weak passwords, it is remote exploitation against exposed services. The question practitioners should ask first is whether those products are reachable from untrusted networks or used in a management role that widens the attack surface.

For an authoritative record of the vulnerability, keep the NIST National Vulnerability Database and the CVE Program in view alongside the vendor advisory, because KEV confirms exploitation status while those sources anchor the record itself. That distinction matters when you are validating asset scope, ticketing the issue, and documenting why this is not a routine patch-cycle item.

Why Fortinet edge and control-plane exposure matters

This is an edge-device and security-control-plane problem, so the blast radius can be large even when only a small number of appliances are affected. Products like firewalls, switch managers, and secure access services often sit on trusted paths, which makes a successful exploit especially valuable to an attacker. A compromised device can be used to observe traffic, alter policy, pivot deeper, or set up persistence if the underlying management plane is not tightly isolated.

Heap-based buffer overflows are especially concerning in appliance and network-security software because they can lead to code execution before higher-level controls have much chance to intervene. The relevant failure mode is not only crash or denial of service, but unauthorised execution on a device that may already hold sensitive network trust. That is why the combination of active exploitation and edge exposure should be treated as a high-priority containment and recovery scenario, not a simple software defect.

For teams responsible for internet-facing appliances, the Edge Device Security Guide is a useful companion because it frames the exact operational issues that make these products hard to defend: management exposure, logging minimums, firmware integrity, and end-of-life handling. Those are the same practical variables that determine whether a Fortinet appliance can be safely delayed, isolated, or rushed through emergency repair.

What to do before and after patching

If patching is available, the first decision is whether you can apply it immediately or whether the device must be handled as potentially compromised until then. When patching must wait, reduce exposure aggressively: restrict management access, narrow inbound reachability, and watch for anomalous command execution or unexpected configuration changes. Because this is a KEV-listed issue, waiting for the next normal maintenance window is usually the wrong risk decision unless the system is already isolated and the exposure is minimal.

After remediation, validate more than version status. Review logs for suspicious sessions, configuration drift, unexplained reboots, changed admin settings, and traffic that suggests the appliance was used as an execution foothold. If the device mediates privileged access or stores credentials, rotate any secrets, tokens, or administrative credentials that could have been exposed through the appliance. Where logging is sparse, treat the absence of evidence cautiously and lean toward containment plus forensic review rather than assuming no compromise occurred.

The most useful supporting reference for this workflow is the Zero-Day and Exploited Vulnerabilities Guide, because it ties KEV triage to emergency mitigation, hotpatching, and post-patch hunting. For vulnerability programme teams, the Vulnerability Management Guide is the broader operating model for handling prioritisation, exception handling, and verification when exploitation status changes the urgency.

Risk and Threat Considerations

When a network appliance flaw is already in KEV, the main risk is not just exploitation, but rapid exploitation against externally reachable devices that are often difficult to monitor deeply. An attacker who gains code execution on an appliance can use it as a trusted foothold to intercept traffic, manipulate policy, or move toward adjacent systems that rely on the appliance for security enforcement.

Failure mechanism: A specially crafted packet triggers heap corruption in the vulnerable service, which can be turned into unauthorised code or command execution on the device.

Impact: Successful exploitation can create device-level compromise, credential exposure, traffic manipulation, service disruption, or a pivot point into the protected network.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation makes prioritised vulnerability handling central.
Recommendation — Prioritise this KEV-listed flaw for immediate remediation and exception tracking.
NIST CSF 2.0	GV.RM-01 — Risk Management Strategy	KEV status changes remediation urgency and enterprise risk acceptance.
Recommendation — Escalate the issue into formal risk prioritisation and response decisions.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	This asks for identifying and prioritising a known exploited flaw in deployed products.
	SI-2 — Flaw Remediation	The question is about exploitation status and the need to remediate the flaw quickly.
	AU-6 — Audit Record Review, Analysis, and Reporting	Post-compromise hunting depends on reviewing logs for suspicious appliance activity.
Recommendation — Use vulnerability monitoring to find exposed Fortinet assets and validate remediation. Apply accelerated flaw remediation for the vulnerable Fortinet products. Review appliance logs for signs of exploitation and configuration tampering.

Practitioner Guidance

What to prioritise: Confirm whether any FortiOS, FortiSwitchManager, or FortiSASE instances are internet reachable, because exposure and exploitability matter more than inventory completeness in the first response window. If the device is exposed, treat it as urgent even if you have not observed abuse yet.

What to verify: Check whether the device has telemetry rich enough to support hunting after remediation, including admin logins, configuration changes, packet anomalies, and process or service instability. If those records are missing, increase the likelihood of a precautionary rebuild or deeper forensic review.

Decision rule: If you cannot patch immediately, reduce reachability first, then assess compromise, then decide whether rotating credentials or rebuilding the appliance is the safer path. Do not assume that “no alert” equals “no exploitation” on a KEV-listed edge product.

Practitioner takeaway: For an actively exploited vulnerability in a perimeter or control-plane device, the right question is not whether the product is still functional, but whether you can still trust it enough to leave it in place.