Is CVE-2025-64446 (Fortinet FortiWeb Path Traversal) being exploited in the wild?

Yes. CISA added CVE-2025-64446 to its Known Exploited Vulnerabilities catalogue on 14 November 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Fortinet FortiWeb contains a relative path traversal vulnerability that may allow an unauthenticated attacker to execute administrative commands on the system via crafted HTTP or HTTPS requests.

What CVE-2025-64446 means for exposure and response

This is an actively exploited edge appliance vulnerability, so the first question is not whether the flaw exists but whether your FortiWeb instances are reachable and still in service. For internet-facing appliances, exploitation often begins before a security team notices unusual logs, especially when management surfaces, administrative functions, or reverse-proxy features are exposed.

A practical response starts with inventory and placement. Confirm which FortiWeb systems are deployed, whether they are externally reachable, and whether they protect production traffic or administrative workflows. If an appliance is no longer needed, removal is safer than prolonging exposure while waiting for maintenance windows or business sign-off.

When you need a broader playbook for appliance exposure, hardening, logging, and patch prioritisation, use the Edge Device Security Guide as the baseline for externally exposed infrastructure.

Why this vulnerability is high priority even before patching

Path traversal on a security appliance is dangerous because it can turn a perimeter control into a control surface. In this case, the issue is not just unauthorized file access. The direct answer indicates the flaw can allow administrative commands via crafted HTTP or HTTPS requests, which raises the stakes from simple information exposure to device-level control and possible policy tampering.

The reason CISA KEV matters here is that active exploitation changes the decision model. A KEV listing means defenders should assume opportunistic scanning, repeatable exploit attempts, and short time-to-compromise across exposed targets. That is the point where ticketing the issue is no longer enough; teams should treat it as a live exposure that can become an incident quickly.

For a structured triage path on exploited issues, the Zero-Day and Exploited Vulnerabilities Guide helps frame emergency mitigation, hotpatching, and post-patch hunting. For prioritisation discipline, the Vulnerability Management Guide is the right companion for KEV-driven remediation and exception handling.

What to check if patching cannot happen immediately

If you cannot patch at once, reduce reachability first. Restrict who can talk to the appliance, remove direct internet exposure where possible, and constrain administrative access to tightly controlled management paths. If the device must remain online, assume the vulnerable request path may already have been probed and tighten monitoring around HTTP and HTTPS requests that touch admin-related functionality.

Then look for compromise, not just failure. Review logs for unusual traversal-like request patterns, abnormal administrative activity, configuration changes, new accounts, unexpected command execution, and signs that the appliance was used as an initial foothold. If the device stores or passes credentials, sessions, or operational secrets, review whether those should be rotated after exposure is confirmed or strongly suspected.

Because path traversal and appliance exploitation are common against edge systems, the Web Application Attacks Guide is useful for understanding request patterns and post-exploitation behaviour. If the appliance is part of a broader remediation programme, the Zero-Day and Exploited Vulnerabilities Guide also supports compromise assessment after emergency containment.

Risk and Threat Considerations

Exploited edge appliances are attractive because they sit at a high-trust boundary and often see broad traffic, which gives an attacker a durable foothold if compromise succeeds. Once an administrative command path is available, the likely failure mode is not just service disruption but control-plane abuse, persistence, and the ability to stage follow-on access.

Failure mechanism: A crafted request reaches a vulnerable path traversal condition on the appliance, allowing an unauthenticated attacker to reach or invoke administrative behaviour that should have been inaccessible.

Impact: The attacker may alter device configuration, interfere with traffic handling, or use the appliance as a launch point for broader network compromise, especially if monitoring and segmentation are weak.

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 SP 800-53 Rev 5 and NIST CSF 2.0 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 exposed vulnerable systems a continuous management issue.
Recommendation — Prioritise, track, and remediate KEV-listed exposures before routine backlog items.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The question hinges on identifying and responding to an actively exploited vulnerability.
	SI-2 — Flaw Remediation	KEV-listed exploitation requires urgent flaw remediation and compensating controls.
	CM-7 — Least Functionality	Reducing exposed services and admin reachability limits attack surface on the appliance.
Recommendation — Scan exposed FortiWeb assets and verify remediation status for the listed CVE. Apply vendor remediation or compensating controls as soon as operationally possible. Disable unnecessary interfaces and restrict management access paths on the device.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerability Identification	Exposure assessment starts by identifying whether vulnerable FortiWeb assets are present and reachable.
Recommendation — Identify all FortiWeb instances and confirm whether each is externally exposed.

Practitioner Guidance

What to verify: Confirm whether any FortiWeb instance is internet-facing, whether it is covered by current vendor guidance, and whether the system can be patched or isolated without breaking critical traffic flows. If you cannot confirm version status and exposure quickly, treat the system as an active-risk asset until proven otherwise.

Decision rule: If the appliance is exposed and you cannot immediately remediate, prioritise isolation, access restriction, and compromise assessment before lower-value maintenance work. If logs or configuration checks show suspicious activity, escalate to incident handling and rotate any credentials or tokens that could have been reachable through the appliance.

Practitioner takeaway: For a KEV-listed edge flaw, the right response is exposure reduction plus compromise hunting, not waiting for a routine patch cycle to decide whether the device was targeted.