CVE-2025-32094: Akamai Ghost CSRF Vulnerability

CVE-2025-32094 Overview

CVE-2025-32094 is an HTTP request smuggling vulnerability [CWE-444] in Akamai Ghost, the server software used in the Akamai content delivery network (CDN) platform before 2025-03-26. The flaw stems from inconsistent HTTP parsing between two in-path Akamai servers when processing HTTP/1.x OPTIONS requests that include an Expect: 100-continue header combined with obsolete line folding. An attacker can leverage this parser discrepancy to smuggle a second request inside the body of the original request. Successful exploitation can poison downstream caches, bypass security controls, or redirect victim traffic to attacker-controlled responses.

Critical Impact

Request smuggling against an in-path Akamai server allows an attacker to inject hidden HTTP requests that bypass front-end security policies and compromise the integrity of responses delivered to other CDN users.

Affected Products

• Akamai Ghost server software
• Akamai CDN platform deployments prior to the 2025-03-26 fix
• Customer origins fronted by vulnerable Akamai edge servers

Discovery Timeline

• 2025-08-07 - CVE-2025-32094 published to the National Vulnerability Database
• 2026-04-15 - Last updated in NVD database

Technical Details for CVE-2025-32094

Vulnerability Analysis

The vulnerability is classified as HTTP Request Smuggling [CWE-444], a class of attack that exploits parsing inconsistencies between chained HTTP intermediaries. In this case, two Akamai servers sitting in the same request path apply different interpretations to the same HTTP/1.x message. The trigger is a specific combination of an OPTIONS method, an Expect: 100-continue header, and the use of obsolete line folding as described in RFC 9112. One server treats part of the byte stream as the request body, while the second server treats it as an additional, separate request. This desynchronization lets an attacker prepend a fully attacker-controlled request to whatever the next legitimate client sends through the same connection. The flaw is network-reachable with no authentication or user interaction, though it requires precise header crafting to align the two parsers, which reduces practical attack reliability.

Root Cause

The root cause is non-uniform handling of obsolete line folding inside HTTP headers when combined with an Expect: 100-continue interim response flow on OPTIONS requests. RFC 9112 deprecates line folding, but lenient parsers continue to accept it. When one Akamai server normalizes folded headers and another rejects or reinterprets them, the byte boundary between the request headers and the request body diverges between the two hops.

Attack Vector

The attack vector is purely network-based. An attacker sends a single crafted HTTP/1.x request to an Akamai edge endpoint. The request uses OPTIONS, declares Expect: 100-continue, and applies obsolete line folding to one or more headers. The attacker appends a second, fully formed HTTP request inside the body of the first request. The front-end server forwards what it considers a single message, while the back-end server parses the body as a new, independent request. Because verified exploit code is not published, no proof-of-concept is reproduced here. See the Akamai Blog CVE-2025-32094 and the BlackHat Briefing on HTTP Desync for technical details.

Detection Methods for CVE-2025-32094

Indicators of Compromise

• HTTP/1.x requests using the OPTIONS method that also carry an Expect: 100-continue header, which is an uncommon combination in legitimate traffic.
• Request headers containing whitespace at the start of continuation lines, indicating obsolete line folding per RFC 9112.
• Unexpected 100 Continue interim responses logged on connections that subsequently produce mismatched request and response counts.
• Cache entries serving content for hostnames or paths that the originating client did not request.

Detection Strategies

• Inspect HTTP/1.x traffic at the edge for the specific triple of OPTIONS method, Expect: 100-continue header, and folded headers, and alert on any match.
• Compare request counts versus response counts on persistent connections traversing CDN tiers, since desync attacks produce imbalanced ratios.
• Correlate cache poisoning symptoms such as response mismatches and unexpected Host header substitutions across edge logs.

Monitoring Recommendations

• Enable verbose HTTP request and response logging at both the edge and origin tier, including raw header bytes where policy permits.
• Forward CDN and reverse proxy access logs to a centralized analytics platform and retain them long enough to investigate cross-tenant cache anomalies.
• Establish a baseline for OPTIONS request volume per origin and alert on sudden spikes from a small set of source addresses.

How to Mitigate CVE-2025-32094

Immediate Actions Required

• Confirm that all traffic is served by Akamai infrastructure updated on or after 2025-03-26, as the fix is deployed platform-side by Akamai.
• Audit application origins for any custom HTTP/1.x handlers that accept obsolete line folding and disable that behavior at the origin.
• Where feasible, prefer HTTP/2 between clients, the CDN, and origin servers, since HTTP/2 framing eliminates this class of desynchronization.

Patch Information

Akamai addressed CVE-2025-32094 in the Ghost server software deployed across the Akamai CDN before 2025-03-26. The fix is applied at the platform level and does not require customer action on edge configuration. Customers should still validate that their origin servers reject obsolete line folding and unexpected Expect: 100-continue flows on OPTIONS requests. See the Akamai Blog CVE-2025-32094 for the vendor advisory.

Workarounds

• Reject inbound HTTP/1.x requests at the origin that contain folded header continuation lines, in line with the RFC Editor guidance on obsolete line folding.
• Drop or normalize Expect: 100-continue headers on OPTIONS requests at the web application firewall or reverse proxy layer.
• Disable HTTP/1.x keep-alive between CDN tiers and the origin where operationally acceptable, which limits the impact of any successful desync.

# Example NGINX origin hardening against folded headers and unexpected Expect flows
underscores_in_headers off;
ignore_invalid_headers on;

map $http_expect $block_expect_options {
    default 0;
    "~*100-continue" 1;
}

server {
    if ($request_method = OPTIONS) {
        set $check "${block_expect_options}";
    }
    if ($check = 1) {
        return 400;
    }
}