Organizations running Fortinet FortiWeb, the company’s web application firewall, face an immediate threat: a single crafted HTTP or HTTPS request can give an unauthenticated attacker the ability to execute administrative commands on the device. The flaw, tracked as CVE-2025-64446 and scored 9.1 out of 10 under CVSS v3.1, exploits a relative path traversal weakness that bypasses authentication entirely. No complete vendor patch has been published for affected FortiWeb versions, and a separate unauthenticated command-execution bug in FortiClientEMS, tracked as CVE-2026-35616, compounds the exposure across Fortinet’s product line.
Two unauthenticated Fortinet flaws and the pattern they reveal
The immediate danger is straightforward. An attacker who can reach a FortiWeb management interface over the network does not need credentials. A specially constructed request triggers a path traversal condition that the device fails to validate, handing over administrative-level command execution. The NVD entry for CVE-2025-64446 classifies the bug as a relative path traversal issue and confirms the attack vector works over both HTTP and HTTPS. FortiWeb appliances sit in front of web applications to filter malicious traffic, so a compromised unit does not just lose its own integrity; it becomes a vantage point for intercepting or manipulating every request that passes through it.
The second flaw affects a different product but shares a disturbing family resemblance. CVE-2026-35616 targets FortiClientEMS, Fortinet’s endpoint management server, and also allows unauthenticated code or command execution through crafted requests. The CVE record for this EMS vulnerability lists Fortinet PSIRT advisory FG-IR-26-099 as both a vendor advisory and a patch reference. That distinction matters: it suggests Fortinet has at least acknowledged the EMS flaw through its product security incident response team and issued remediation guidance for that product. No equivalent PSIRT advisory or patch reference appears in the NVD listing for the FortiWeb vulnerability, leaving administrators of that product without a clear fix.
The hypothesis that these two bugs share an underlying code pattern deserves scrutiny. Both allow unauthenticated remote command execution. Both exploit failures in input validation or authentication enforcement on HTTP-based management interfaces. Fortinet ships a broad portfolio of security appliances and management consoles that rely on similar web-based administration frameworks. If the root cause is a shared library or a common request-handling routine, other Fortinet products could harbor the same class of weakness. The company has not published a unified authentication framework review, and without one, the risk of recurrence within the next several product update cycles is real.
Government records and the CERT-EU precedent
The evidence trail runs through U.S. government infrastructure. The national standards agency that oversees the National Vulnerability Database provides the canonical records for both CVEs, including standardized CWE classifications, CVSS vector strings, and reference links. For CVE-2025-64446, the database confirms the attack requires no authentication, no user interaction, and can be launched remotely. For CVE-2026-35616, the same government system ties the flaw to Fortinet’s own PSIRT bulletin FG-IR-26-099, giving that entry a vendor-acknowledged patch status that the FortiWeb flaw lacks.
A precedent from 2024 sharpens the concern. CERT-EU, the European Union’s computer emergency response team, published Security Advisory 2024-113 covering CVE-2024-47575, a missing-authentication vulnerability in Fortinet FortiManager. That flaw allowed remote unauthenticated code execution against a critical management function. The advisory documented formal risk framing and remediation guidance for the FortiManager bug, including explicit upgrade paths and configuration recommendations. The pattern is consistent: Fortinet products that handle network or endpoint management keep surfacing authentication bypass conditions that let remote attackers gain control without credentials. Three products, three separate CVEs, and the same fundamental failure mode across FortiWeb, FortiClientEMS, and FortiManager.
Missing patch, missing timeline, and what administrators should do first
Several questions remain open. The NVD entry for CVE-2025-64446 does not include a Fortinet PSIRT advisory number or a patch release date. Affected version strings appear in the government database, but Fortinet itself has not issued a public disclosure document that matches the level of detail provided for the FortiClientEMS flaw. No government source in the current record documents active exploitation in the wild or the existence of proof-of-concept code, but the absence of evidence is not evidence of absence, especially for a 9.1-severity bug with a low attack complexity.
The gap between the two disclosures also raises questions about Fortinet’s internal triage process. FortiClientEMS received a PSIRT advisory and patch reference. FortiWeb, with a comparable severity and an even more exposed network position, has not yet been paired with a public fix timeline. That asymmetry may reflect differences in discovery dates, customer pressure, or engineering complexity, but from an operator’s perspective it translates into uneven visibility and uneven protection across the same vendor’s portfolio.
Until Fortinet publishes a formal advisory and software update for FortiWeb, administrators must rely on compensating controls. The first priority is strict network isolation of all FortiWeb management interfaces. These should never be reachable from the public internet and should be further restricted to a hardened management VLAN, accessible only via jump hosts with multifactor authentication. Organizations should audit firewall rules, VPN configurations, and cloud security groups to confirm that no unintended exposure exists.
Where possible, security teams should enable and review detailed logging on FortiWeb appliances. Unusual HTTP or HTTPS requests targeting administrative paths, especially those containing encoded traversal sequences or atypical headers, should be treated as potential exploitation attempts. Because the vulnerability is unauthenticated, failed-login metrics will not be a reliable signal; instead, defenders must look for anomalous request patterns and unexpected configuration changes on the devices themselves.
Given the history of similar Fortinet flaws, organizations should also assume that FortiWeb is only one potential entry point. A comprehensive asset inventory of all Fortinet products-firewalls, VPN concentrators, management servers, and endpoint controllers-is essential. Each system should be checked against current NVD records and vendor advisories, with patches applied promptly where available and access tightened for any component that handles web-based administration.
Incident response planning must take into account the possibility that a compromised FortiWeb appliance could be used to pivot deeper into the environment. Because FortiWeb sits in front of application servers, an attacker with administrative access could modify traffic, inject malicious payloads, or harvest credentials passing through the device. Organizations should consider segmenting back-end application networks, enforcing mutual TLS where feasible, and monitoring for configuration drift on both the WAF and the protected applications.
Longer term, the recurring nature of these authentication bypass issues suggests that customers should press Fortinet for architectural assurances, not just one-off patches. That means asking for independent security assessments of shared management frameworks, clear documentation of authentication and authorization models, and transparent disclosure when code reuse spans multiple products. Vendors that build security infrastructure bear a heightened responsibility to demonstrate that their own control planes are hardened against precisely the kinds of attacks they are meant to block.
For now, the operational guidance is clear even if the vendor roadmap is not. Treat CVE-2025-64446 as an active risk, minimize exposure of FortiWeb management interfaces, and prepare for rapid patch deployment once a fix is available. Apply the existing FortiClientEMS update associated with CVE-2026-35616 and verify that no vulnerable EMS instances remain exposed. And, informed by the FortiManager precedent, assume that other management-plane components may harbor similar flaws until proven otherwise. In an environment where a single crafted request can overturn the security guarantees of a critical appliance, cautious overreaction is preferable to waiting for confirmation that attackers have already moved in.
More from Morning Overview
*This article was researched with the help of AI, with human editors creating the final content.
