Skip to content
RESEARCH INDEX BREACHROAD / INTELLIGENCE NOTE

FortiWeb CVE-2025-64446: critical authentication bypass

CVE-2025-64446 (CVSS 9.4) lets unauthenticated attackers run FortiWeb admin commands. Public PoC, KEV, versions, hunting and fixes.

PUBLIC RESEARCH
AUTHOR
/ Penetration Tester (OSCP, PNPT)
PUBLISHED
14 November 2025
READING TIME
20 min read
TOPIC
Critical Vulnerabilities
FortiWeb CVE-2025-64446: critical authentication bypass

CVE-2025-64446 is a critical FortiWeb vulnerability that lets a remote unauthenticated attacker execute administrative commands through crafted HTTP or HTTPS requests. Fortinet rated it CVSS 9.4 and confirmed real-world exploitation. The path-confusion / relative-path-traversal flaw in the appliance GUI may enable creation of an unauthorised administrator and complete WAF takeover.

Immediate recommendation: install the fixed release for the deployed FortiWeb branch, disable HTTP/HTTPS management on Internet-facing interfaces and review administrator accounts and configuration. A compromised WAF undermines trust in both logs and the policies protecting downstream applications.

CVE-2025-64446 versions and fixes

FortiWeb branchVulnerable releasesMinimum fixed release
8.08.0.0–8.0.18.0.2
7.67.6.0–7.6.47.6.5
7.47.4.0–7.4.97.4.10
7.27.2.0–7.2.117.2.12
7.07.0.0–7.0.117.0.12
6.4not affected according to the advisoryn/a

This scope comes from Fortinet PSIRT FG-IR-25-910. FortiAppSec Cloud is not affected. The advisory was published on 14 November 2025.

How path confusion bypasses authentication

The FortiWeb management plane combines an HTTP server, route handling and a backend that performs administrative operations. Every path reaching privileged functionality must pass the same session and authorisation checks.

CVE-2025-64446 exploits inconsistent path normalisation between layers. A crafted address containing relative traversal elements can be interpreted differently by the frontend and backend. The access-control layer treats the request as an unprotected path or different function, while the backend routes it to an administrative operation.

The effect is not limited to reading a page. Fortinet says an attacker can execute administrative commands, while public research demonstrates creation of a new administrator. Control of the appliance may allow an actor to:

  • change WAF policy and permit later attacks;
  • read backend configuration, certificates and credentials;
  • redirect or inspect application traffic;
  • disable logging and hide activity;
  • move laterally through the management network;
  • persist through accounts and configuration changes.

Public PoC and safe confirmation

watchTowr released a FortiWeb Authentication Bypass detection artefact generator. It demonstrates user creation and can change device state. Use it only on a laboratory instance or within a written penetration-test scope, never on a production appliance.

Safe validation includes:

  1. reading the system version from CLI and central management, not only an HTTPS banner;
  2. inventorying every HA node—the cluster version does not prove identical member state;
  3. checking which interfaces permit HTTP/HTTPS administrative access;
  4. mapping NAT rules, load balancers and historical GUI exposure;
  5. exporting configuration, administrator logs and events before updating;
  6. validating the fix on a test appliance and conducting a passive post-deployment retest.

A public scanner may create a configuration artefact. Deleting that account afterwards neither reverses the risk nor replaces an investigation.

Fortinet remediation and workaround

Install at least the release listed in the table or a newer supported release recommended for the hardware. In HA, use the vendor procedure, confirm synchronisation returns and verify each member.

If immediate upgrade is impossible, Fortinet recommends disabling HTTP/HTTPS on Internet-facing interfaces. The GUI should be reachable only from a dedicated management network or jump host. Local-in policy, an upstream firewall ACL and absence of public NAT provide independent layers.

Also:

  • require MFA for every administrator;
  • use named accounts rather than a shared admin identity;
  • stream logs to an external SIEM in near real time;
  • restrict appliance egress;
  • manage through a dedicated interface and VRF/VLAN;
  • compare configuration against an approved baseline;
  • maintain encrypted, tested configuration backups.

Exploitation and KEV

Fortinet states that it observed exploitation in customer environments. CISA included the issue in Known Exploited Vulnerabilities. Internet-edge devices are scanned automatically, and the path bypass needs no credentials or operator interaction.

Response cannot stop at the upgrade. If the GUI was reachable while vulnerable, confirm that accounts and policies were not changed before patching.

FortiWeb threat hunting

Fortinet recommends reviewing unexpected configuration changes and administrator creation. Extend the review to:

  • accounts created outside the IAM process and unusual roles;
  • administrator logins from new addresses or outside change windows;
  • GUI requests carrying traversal sequences or abnormal path normalisation;
  • server-policy, protected-host, routing, certificate and backend changes;
  • disabled signatures, logging or SIEM integration;
  • new scripts, automations and local files;
  • management-plane outbound connections;
  • configuration differences between HA members;
  • reboots, GUI process failures and logging gaps.

An unauthorised administrator means the appliance should be treated as compromised. Preserve configuration for analysis, isolate management, rotate passwords and certificates available to the device, validate backends, and consider rebuilding from clean firmware and a trusted baseline.

The WAF as a critical trust component

FortiWeb commonly terminates TLS and sees complete user requests. It may hold private certificate keys, origin credentials and internal-address configuration. WAF management therefore deserves controls comparable to firewalls, hypervisors and identity platforms.

Regular application and infrastructure security testing should evaluate the management plane from Internet, corporate and administrator segments. Protecting other systems does not make the WAF’s own GUI secure.

Root cause and the complete management surface

Fortinet classifies the issue as relative path traversal leading to unauthenticated administrative-command execution. The security failure is inconsistent path interpretation before access control and within the GUI backend. This does not mean every traversal sequence succeeds or that one HTTP status proves execution. Detection and reporting must preserve that distinction.

Management surface includes more than the public panel address:

  • every physical interface, VLAN, VRF and HA address;
  • floating addresses and direct member addresses;
  • NAT, port forwarding, reverse proxies and local-in policy;
  • VPN, jump-host and vendor-network access;
  • IPv4 and IPv6;
  • DR, laboratory and spare appliances;
  • central managers and API-driven automation.

Validate these paths through an internal network segmentation penetration test. The tester can request the ordinary login page and confirm routing and logging without using a PoC sequence. “Not exposed to the Internet” should also be checked from partner and standard user networks.

Validate exposure and state without changing the appliance

Safe evidence comes from inventory and passive controls:

  1. record model, branch, build and HA role for each node;
  2. compare each version with the PSIRT table rather than trusting only a manager summary;
  3. inspect administrative-access settings on every interface;
  4. review upstream ACLs, NAT, routing and historical changes;
  5. perform a harmless TCP/TLS/HTTP check from representative zones;
  6. confirm the attempt reaches external logging;
  7. compare configuration with an approved backup predating exposure.

A PoC that creates an administrator is not a version scanner. Do not use it for bulk validation, health checks or production monitoring. A laboratory can use it to test a detection and artefact-removal workflow, but the result does not replace vendor patch inventory.

Telemetry and WAF-compromise triage

An appliance that may be compromised cannot be the sole evidence source. Export logs into an external security monitoring programme and correlate:

SourceReviewReason
upstream firewallsource, NAT, time and interfaceproves the real path to the GUI
external SIEMadmin login and configuration changeremains more trustworthy after local tampering
FortiWeb admin auditaccount, role, source IP and actionidentifies a change and claimed actor
backup/config diffadministrator, policy, certificate and backend changesexposes persistent modification
HA telemetrysynchronisation and node differencesfinds a stale or bypassed member
PKI/secret systemsuse of a key or credential stored on the applianceestablishes impact beyond the WAF
backend access logsunusual requests after policy changeshows whether application protection was weakened

Triage should answer in order: did a request reach the management plane, did an administrative operation occur, did configuration change, did HA replicate it and were reachable credentials used elsewhere? Missing local logs during a gap increase uncertainty; they do not prove safety.

CVE-2025-64446 decision tree

Does every node meet the fixed version for its branch?

  • Yes: review historical exposure, configuration integrity and off-device logs.
  • No or unknown: disable HTTP/HTTPS on low-trust interfaces and start emergency upgrade.

Was the GUI reachable while vulnerable?

  • Yes: assume possible misuse and inspect accounts, roles, policies, certificates and backends.
  • No: prove it using routes, ACLs and logs from several zones, then update all nodes.

Is there an unknown account, configuration change, logging gap or new egress?

  • Yes: isolate management, preserve configuration, rotate secrets and rebuild from trusted firmware and baseline under incident response.
  • No: complete retesting and maintain heightened monitoring for the agreed period.

Govern rotation through a secrets and certificate management process. A TLS private key, origin password and API identity have different dependencies and replacement order.

Remediation verification and hardening

After upgrade, record the build of every HA member, confirm synchronisation, interface state and correct application traffic processing. Verify that an emergency GUI-block rule was not accidentally removed and that no alternate NAT remains. A controlled Internet request should be denied and recorded by the firewall, while a jump-host request should enter the admin audit trail.

Harden according to Zero Trust principles: dedicated management zone, named identities, MFA, minimum roles, recorded sessions and no direct Internet exposure. Limit appliance egress to required update, SIEM, DNS, NTP and named backend destinations. Encrypt and test configuration backups, protecting them from modification by the same administrative identity.

Retesting does not run the PoC on production. It verifies versions, absent exposure, account and configuration integrity, logging health and the new access architecture.

Checklist

  • Every node runs the fixed release for its branch.
  • HTTP/HTTPS management is not Internet-facing.
  • Administrator accounts, roles and change history were reviewed.
  • Configuration was compared with a trusted baseline.
  • Certificates and credentials on a suspicious appliance were rotated.
  • Logs are exported off-device with adequate retention.
  • Every interface, HA address, NAT, VPN, DR site and node was checked separately.
  • Configuration was compared with a backup predating possible exposure.
  • A jump host, MFA and minimal roles protect management access.
  • Exposure was retested after remediation without altering production.

Sources

SHARE / COPY