Cache Poisoning Reloaded: Deep Dive into CVE-2025-4366 and Pingora's Request Smuggling Flaw

A single HTTP request that can poison a CDN cache or silently leak user data to an attacker raises the stakes for edge security considerably. CVE-2025-4366 made that possible in Cloudflare's Pingora proxy framework. It is a high-severity request smuggling vulnerability that could have let attackers manipulate traffic for millions of users, with real consequences for data integrity and privacy.

Introduction

Pingora is not a household name, but a huge amount of traffic runs through it. Cloudflare developed it, and it powers the proxy infrastructure behind one of the world's largest CDNs and security providers, handling over a trillion requests per day. Since it was open-sourced in 2024, Pingora has quickly gained traction for its performance and security features, and it has become a critical component for organizations that want scalable, modern HTTP proxying. A vulnerability in infrastructure this foundational can reach well beyond a single vendor, to any service built on the same codebase.

Technical Information

CVE-2025-4366 is a textbook example of how a subtle protocol-handling bug can have an outsized security impact. The flaw is in how Pingora handles HTTP/1.1 persistent connections, specifically in the pingora-proxy and pingora-cache crates when caching is enabled. On a cache hit, Pingora would serve the cached response but would not fully drain the request body from the connection buffer. That violates HTTP/1.1 semantics and opens the door to request smuggling.

An attacker can exploit this with an HTTP request that carries both Content-Length and Transfer-Encoding: chunked headers, which makes it ambiguous where the request ends. Here is a representative malicious payload:

GET /foo.jpg HTTP/1.1
Host: victim.com
Content-Length: 79
Transfer-Encoding: chunked

0

GET /malicious HTTP/1.1
Host: attacker.com
Bogus: foo

If /foo.jpg is a cache hit, Pingora serves the cached content and leaves the undrained body, smuggled GET /malicious request included, in the connection buffer. When the connection is reused, Pingora reads the leftover data as a new HTTP request. From there the attacker can execute unauthorized actions, poison the cache, or leak sensitive information. In practice this can mean cache poisoning (serving attacker-controlled content to future users), header manipulation (for example, leaking Referer data through redirects), or web cache deception attacks.

The root cause is a violation of HTTP/1.1 connection-reuse semantics. Pingora did not consume the full request body before reusing the connection, which led to inconsistent interpretation of HTTP requests (CWE-444). The vulnerability is present only when caching is enabled, and only on HTTP/1.1 connections. HTTP/2 is not affected, because its protocol design is frame-based.

Patch Information

Before the fix, Pingora could reuse an HTTP/1.1 persistent connection after a cache hit without draining the request body. An attacker could append requests to that undrained body and inject them into the connection, which made request smuggling and cache poisoning attacks possible.

The Pingora team's fix makes draining the request body mandatory before any HTTP/1.1 connection is reused, so residual data from one request cannot interfere with the next. The change is in commit fda3317ec822678564d641e7cf1c9b77ee3759ff and has two parts:

1. Pingora now drains any remaining bytes in the request body automatically before it considers a connection for reuse. The drain is built into the session's lifecycle, so it is applied consistently.

2. A configurable timeout governs the drain. If draining runs into trouble, the timeout prevents delays or hangs, so performance and reliability hold up.

This snippet from the commit shows the draining step:

// Ensure the request body is fully drained before reusing the connection
if let Err(e) = self.drain_request_body().await {
    log::warn!("Failed to drain request body: {:?}", e);
    // Handle the error appropriately
}

The code clears any residual request-body data before the connection is reused, which mitigates the risk of request smuggling.

Users are strongly encouraged to update to version 0.5.0 or later to get the fix.

Patch reference: Pingora commit fda3317ec822678564d641e7cf1c9b77ee3759ff

Detection Methods

Detecting HTTP request smuggling, including the flaw in Pingora's proxying framework (CVE-2025-4366), takes several methods used together. (nvd.nist.gov)

1. Analyzing HTTP Traffic for Anomalies

Watch HTTP traffic for irregularities that may indicate request smuggling attempts, such as:

• Uncommon or malformed HTTP methods, which could suggest manipulation.

• Discrepancies between Content-Length and Transfer-Encoding headers, which attackers can exploit to smuggle requests.

• Request sequences that deviate from typical behavior, such as multiple requests on a single connection that don't match standard usage.

2. Implementing Intrusion Detection Systems (IDS)

An IDS can identify and alert on possible request smuggling. Snort, a widely used IDS, provides rules that can be tailored to detect these anomalies. (snort.org)

3. Reviewing Application Logs

Check server and application logs regularly for:

• Unexpected 4xx or 5xx status codes, which may mean the server is processing malformed requests.

• Unusual latency, since delays in processing requests can be a symptom of smuggling attempts.

4. Conducting Security Testing

Use security testing tools to simulate request smuggling attacks and see how well the application resists them. Testing this way finds vulnerabilities before attackers can exploit them.

Detection references: NVD, Snort Talos Rules

Affected Systems and Versions

CVE-2025-4366 affects:

• Products: Cloudflare Pingora proxying framework, including the pingora-proxy and pingora-cache crates
• Versions: All versions prior to 0.5.0
• Configuration: Vulnerable only when HTTP/1.1 caching is enabled. HTTP/2 deployments are not affected
• Patch: Fixed in version 0.5.0 (release notes)

Vendor Security History

Cloudflare has a strong record of fast incident response and transparent disclosure. It patched CVE-2025-4366 within 22 hours of the initial report and published a detailed technical analysis shortly after. Previous vulnerabilities in Cloudflare's infrastructure have been fixed with similar speed. The company works with the security research community through its bug bounty program, and its open-source projects are regularly audited for security issues.

References

• NVD: CVE-2025-4366
• Official CVE Entry
• Pingora Patch Commit
• Cloudflare Blog: Resolving a Request Smuggling Vulnerability in Pingora
• The Cyber Express: Cloudflare Fixes CVE-2025-4366 in Pingora OSS
• Vulert: Pingora-core Request Smuggling Vulnerability
• Snort Talos Rules

Source: This report was created using AI

If you have suggestions for improvement or feedback, please contact us at [email protected]