Yes. CISA added CVE-2025-32756 to its Known Exploited Vulnerabilities catalogue on 14 May 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Fortinet FortiFone, FortiVoice, FortiNDR and FortiMail contain a stack-based overflow vulnerability that may allow a remote unauthenticated attacker to execute arbitrary code or commands via crafted HTTP requests.
How KEV listing answers the “exploited in the wild” question
CISA’s Known Exploited Vulnerabilities catalogue is a strong operational signal because it is reserved for vulnerabilities with reliable evidence of active exploitation. For this Fortinet issue, the practical takeaway is that the question is no longer theoretical: you should treat exposure as an incident-response priority, not a routine patch queue item. The KEV entry is the best public confirmation point for exploitation status.
When a vulnerability lands in KEV, the issue is usually not just the code flaw itself but the likelihood that opportunistic scanning, targeted exploitation or follow-on abuse is already underway. For internet-facing security appliances and mail or voice infrastructure, that means defenders should assume the vulnerable service may be probed quickly and repeatedly, especially if it is reachable from the public internet.
For asset owners, the first step is to confirm whether any FortiFone, FortiVoice, FortiNDR or FortiMail deployment is exposed, internet reachable or operationally dependent on legacy interfaces. If the product is present but isolated from direct external access, the urgency is still high, but the immediate attack surface is narrower than for a directly exposed device.
Edge Device Security Guide is the right internal reference when you are validating appliance exposure, management-plane reachability and logging expectations for devices that sit on the network perimeter.
What the vulnerability type changes for defenders
A stack-based buffer overflow in a network-facing product is more dangerous than a narrow logic bug because exploitation can be triggered remotely and, in this case, without authentication. That combination raises the chance of full compromise, since the attacker does not need stolen credentials or an existing foothold before sending crafted HTTP requests.
In practice, this kind of flaw can lead to arbitrary code execution or command execution, which means the attacker may be able to use the device as a launch point, intercept traffic, tamper with mail or voice workflows, or pivot deeper into adjacent systems. The exact outcome depends on the appliance role, network placement and the privileges available to the compromised service.
Zero-Day and Exploited Vulnerabilities Guide helps frame the operational difference between “known issue” and “actively exploited issue,” including why emergency handling and post-fix hunting matter even when the vendor patch is available.
CWE Top 25 Guide is useful here because stack-based overflow is a classic weakness class, and it reinforces why input handling failures on exposed services remain high-value targets for attackers.
What to do before, during, and after remediation
If patching is available, apply it according to the vendor advisory and CISA KEV guidance rather than waiting for a normal maintenance window. Where patching must wait, reduce exposure immediately by removing internet reachability, restricting management access, segmenting the appliance and increasing logging around the affected service.
Do not stop at installation status. Validate whether the product is still reachable on the affected interface, whether it has been scanning or crashing unexpectedly, and whether there are signs of web request abuse, unusual child processes, or unexpected configuration changes. If the device handled sensitive mail, telephony or NDR data, review whether compromise could have exposed tokens, credentials or administrative sessions.
Vulnerability Management Guide supports the practical sequence after KEV notification, particularly around prioritisation, exception handling and verification that remediation actually reduced exposure.
CISA Known Exploited Vulnerabilities Catalog, CVE Program and NIST National Vulnerability Database are the authoritative places to confirm the record, trace the identifier and find the vendor-linked remediation details.
Risk and Threat Considerations
Once a remote unauthenticated overflow is publicly exploited, the main risk is not just service disruption. The larger concern is that the appliance may become an entry point for persistence, command execution or further internal reconnaissance, especially when it sits close to email, voice or security workflows that many users trust.
Failure mechanism: The attacker sends crafted HTTP traffic that triggers memory corruption in the vulnerable service, which can convert a parsing flaw into code execution or command execution before normal access controls have any chance to intervene.
Impact: A compromised appliance can expose adjacent systems, disrupt communications, undermine trust in mail or voice handling, and create a beachhead for broader internal compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Applies to urgent remediation of a KEV-listed exploitable vulnerability. |
| RA-5 — Vulnerability Monitoring and Scanning | Applies to confirming exposure and validating whether the vulnerable products are present. | |
| IR-4 — Incident Handling | Applies when KEV evidence suggests active exploitation and compromise assessment is needed. | |
| Recommendation — Prioritise remediation of the affected Fortinet services and verify exposure is removed. Scan for affected Fortinet assets and confirm whether the vulnerable interface is exposed. Invoke incident handling to investigate possible exploitation and preserve evidence. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Applies because KEV-driven prioritisation and remediation are core vulnerability management tasks. |
| CIS-12 — Network Infrastructure Management | Applies to limiting exposure of internet-facing appliances and controlling access paths. | |
| Recommendation — Prioritise the KEV-listed Fortinet flaw and verify remediation on all exposed systems. Restrict external reachability and manage appliance interfaces to reduce exploit exposure. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Applies to the underlying memory corruption weakness class and robust input handling. |
| Recommendation — Treat exposed parsing and buffer-handling defects as high-risk architectural weaknesses. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Applies because the flaw is remotely exploitable through crafted HTTP requests. |
| T1068 — Exploitation for Privilege Escalation | Applies when exploitation yields higher privileges or execution on the appliance. | |
| Recommendation — Hunt for exploitation of the public-facing Fortinet service and related follow-on activity. Look for privilege escalation or code-execution outcomes after successful exploitation. | ||
Practitioner Guidance
What to verify: Confirm whether the affected Fortinet products are deployed, externally reachable, and actually running the vulnerable service path. If the answer is uncertain, treat that uncertainty as exposure until inventory and reachability are proven.
Decision rule: If the asset is internet facing or supports a critical business function, prioritise emergency remediation and compromise assessment before broader optimisation work. If patching is delayed, reduce exposure first, then hunt for signs of exploitation.
What good looks like: You have a verified asset list, a clear view of exposed interfaces, a completed patch or mitigation status, and post-remediation checks that confirm the service is healthy and not showing signs of abuse.
Practitioner takeaway: For a KEV-listed appliance overflow, the important question is not whether the vendor has published a fix, but whether the device has already been reachable long enough to be abused and whether you can prove it was not.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2025-32756 (Fortinet Multiple Products Stack-Based Buffer Overflow)?
- Is CVE-2025-25249 (Fortinet Multiple Products Heap-based Buffer Overflow) being exploited in the wild?
- CVE-2025-32756 (Fortinet Multiple Products Stack-Based Buffer Overflow)
- How do you patch or mitigate CVE-2025-25249 (Fortinet Multiple Products Heap-based Buffer Overflow)?