Fortinet FortiWeb Authentication Bypass – CVE-2025-64446

TL;DR: Bishop Fox researchers discovered an authentication bypass in FortiWeb that lets attackers add their own admin accounts, take over the device, and erase evidence. Fortinet fixed the issue with a configuration change that blocks access to the vulnerable component. Organizations can quickly check if they’re exposed using a new Bishop Fox scanner and should remove public access and update immediately.

Background

Last week, Bishop Fox researchers came across a proof-of-concept exploit for an unpublished vulnerability affecting Fortinet FortiWeb. It was originally posted in early October by Defused Cyber from what appears to be a honeypot capture, then reposted by Florian Roth with a claim that the vulnerability is under active exploitation. The next day, Fortinet confirmed both the existence and exploitation of the vulnerability with an official advisory, and CISA added it to their Known Exploited Vulnerabilities (KEV) catalog.

The payload consists of a single HTTP POST request designed to bypass authentication and create a new user with administrative privilege in the web management interface, which allows an attacker to log in and take full control of a target appliance.

We tested the PoC against several different versions of FortiWeb and confirmed that the exploit works against older versions, but not the latest available updates. Here are the results of our tests:

We suspect that versions older than those listed here are vulnerable, but only versions 7.0 and above are actively supported by Fortinet at this time.

Exploit Analysis

The exploit can be sent as a single cURL request consisting of three parts:

1. A path traversal in the URL allows the request to reach an internal CGI handler.
2. A crafted payload in the custom CGIINFO authorization header allows the request to bypass authentication and be processed as if it had internal authorization.
3. The JSON POST body contains a standard payload to create a new administrator account.

Two server binaries are responsible for processing the malicious request:

• httpsd is a Fortinet-customized version of the Apache web server that handles all incoming HTTP requests.

• fwbcgi is an internal CGI handler that processes certain requests on behalf of the web server.

First, httpsd receives the incoming request, normalizes the URI path to /cgi-bin/fwbcgi, and routes the request directly to fwbcgi. The following lines in httpd.conf are responsible for this routing:

Second, fwbcgi validates that the original URI path references a valid REST API endpoint (/api/v2.0/cmdb/system/admin in this case). In reality, what appears to be a path traversal in the URI is actually part of the authorization bypass, as it allows the external request to masquerade as an internal one so that fwbcgi will process it.

Third, fwbcgi decodes the base64 value of the CGIINFO header, used for internal authorization, and interprets the resulting JSON object to indicate that the request should be executed with administrative privilege:

Finally, fwbcgi processes the JSON POST body using the root.system.admin permissions context, creating a new account in the web management interface with administrative privilege:

The attacker can then log in to the web management interface directly:

The System > Admin > Administrators view shows the new administrator account:

The malicious account creation is shown in the event logs under Log & Report > Log Access > Event:

With full administrative control, however, the attacker can clear the logs to erase these indicators of compromise.

Patch Analysis

Fortinet initially released new versions of FortiWeb without reference to this vulnerability. Bishop Fox researchers compared affected and patched versions of the firmware and determined a single change is responsible for mitigating the auth bypass.

In unpatched versions, access to the cgi-bin directory is permitted without any sanitization by httpd.conf:

In patched versions, access to the cgi-bin directory is denied by default, and access to fwbcgi is restricted to internal redirects:

Our researchers reviewed additional changes to httpsd and fwbcgi but determined they did not impact the vulnerability, leaving the change to httpd.conf as the sole mitigation. It is worth noting that a new log message was added to httpsd in version 8.0.2 that indicates when an IP address lockout occurs due to a specific number of failed REST API login attempts (log type 10000017).

Evaluating Impact

To test if a particular instance of FortiWeb is vulnerable without causing any negative impacts, run the following cURL command:

A 200 OK response indicates that the target is vulnerable, while 403 Forbidden indicates the target is unaffected. Note that this command only exploits the initial path traversal/auth bypass without making any changes to the target system.

You can also download our open source Python scanner to test if you’re vulnerable: https://github.com/BishopFox/fortiweb-auth-bypass-check.

If you are running an affected version of FortiWeb with the web management interface publicly exposed, an attacker can fully compromise the system. To protect yourself, we recommend taking the following actions immediately:

• Remove the management interface from public access.
• Install the latest available FortiWeb update.

Our Cosmos customers were first notified about our research into this vulnerability, and continue to receive updates as we uncover more about it. If you’re interested in learning more about our managed services delivered through our Cosmos platform, fill out our Get Started form or download our visit: bishopfox.com/services/cosmos.