A request-smuggling bug in Pingora's cache path

Cloudflare has patched a request smuggling vulnerability in its open source Pingora framework after a researcher reported it through the company's Bug Bounty Program on April 11, 2025. The flaw, tracked as CVE-2025-4366, affected the caching functionality in the pingora-proxy and pingora-cache crates and was present in a component serving a subset of CDN free-tier traffic at the time of disclosure.

The company says it found no evidence of active exploitation and mitigated the issue within roughly 22 hours of the report, disabling traffic to the vulnerable component by April 12, 2025. Users of the Pingora OSS framework who rely on its caching features should upgrade to version 0.5.0 or later; Cloudflare CDN customers on the free plan require no action.

How the request smuggling worked

Request smuggling exploits inconsistencies in how different systems along a request path parse HTTP. Two components that disagree on where a request ends and the next begins can let an attacker craft traffic that one component treats as a complete request while another parses it into a subsequent malicious request on the same connection.

The Pingora bug stems from an HTTP/1.1 parsing issue that surfaced only when caching was enabled. HTTP/1.1 persistent connections allow multiple requests to reuse a single TCP connection, but each request must carry a self-defined message length through headers such as Content-Length or Transfer-Encoding so the connection can delimit one request from the next. Pingora normally handles this correctly, either consuming the downstream request body or refusing to reuse the connection on error.

With caching enabled, that validation was skipped on cache hits — requests served directly from the cache backend without an upstream call. After the response went downstream, any unread request body remaining in the connection could poison the next request. An attacker could form the unread body into a valid but incomplete header, which would then be misinterpreted as the start of the subsequent request. As a result, the smuggled request could inject its own headers and URL into a following legitimate request sent over the same connection.

Impact on CDN traffic

Cloudflare was rolling out a Pingora proxy component with caching enabled to a subset of free-plan CDN traffic when the report arrived. The researcher demonstrated an exploit that could modify request headers and URL sent to customer origins, and also showed a secondary effect: certain origins would respond to the rewritten Host header with a 301 redirect. When the visitor's browser followed that redirect to the attacker's hostname, a Referrer header revealed which URL the visitor had originally been trying to access, letting the attacker load a malicious asset and observe the victim's traffic.

After confirming the component was susceptible, Cloudflare disabled CDN traffic to it. Before re-enabling traffic, the company released a patched version of the component and invalidated all assets cached on its backend to guard against cache poisoning from injected headers.

Timeline

All timestamps are in UTC.

  • 2025-04-11 09:20 – Cloudflare notified of the CDN request smuggling vulnerability via the Bug Bounty Program.
  • 2025-04-11 17:16 to 2025-04-12 03:28 – Cloudflare confirms the vulnerability is reproducible and investigates which components need changes.
  • 2025-04-12 04:25 – Cloudflare isolates the issue to the Pingora proxy component rollout with caching enabled and prepares to disable traffic to it.
  • 2025-04-12 06:44 – Disable rollout complete, vulnerability mitigated.

Cloudflare credits researchers James Kettle and Wannes Verwimp for the responsible disclosure through its bug bounty program.