Pingora HTTP/1 and HTTP/2 Processing Flaws

Authorization bypass in Cloudflare Pingora before 0.9.0 can occur only in a chained HTTP/1 deployment where Pingora forwards to a downstream HTTP/1 intermediary that honors Connection-nominated headers and the origin trusts a header Pingora adds, such as X-Forwarded-For. A remote, unauthenticated attacker can use the client Connection header to nominate that trusted header; because the vulnerable HTTP/1 upstream path fails to strip hop-by-hop or nominated headers, the intermediary may remove it and bypass IP-based authorization. No public exploit was identified at time of analysis, Cloudflare CDN customers are explicitly unaffected, and 0.9.0+ default policy removes these headers, so the issue is conditional rather than broadly exploitable.

Memory exhaustion in Cloudflare Pingora's HTTP/2 server (versions before 0.8.1) lets a single remote, unauthenticated client drive the process into OOM termination by abusing HPACK header compression and HTTP/2 flow control. Because the h2 crate defaults were left in place, an attacker can emit tiny 1-byte indexed references to an almost-empty header and multiply them into hundreds of thousands of decoded header fields per stream, across an unbounded number of concurrent streams on one connection, exhausting memory (CVSS 3.1: 7.5, AV:N/AC:L/PR:N/UI:N/C:N/I:N/A:H, CWE-770). The reporter demonstrated a lone connection getting a Pingora process capped at 2 GiB OOM-killed; no public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV, but the barrier to entry is low for any internet-facing service that terminates h2 or h2c without explicit limits, while Cloudflare CDN customers were unaffected because its internal Pingora services do not front HTTP/2 clients.

A request-routing discrepancy in Cloudflare Pingora before 0.9.0 lets an unauthenticated remote attacker send a single HTTP/2 request that the proxy evaluates under one authority while the upstream receives a different Host, so Host-based filters, access controls, or cache keys can be applied to the wrong virtual host. Exploitation is conditional and moderate risk: the deployment must terminate client HTTP/2 in Pingora, make security or caching decisions from the request URI authority, and sit in front of an upstream that routes by Host and serves different content per Host. The outcome is limited-impact confidentiality and integrity exposure on the downstream component (possible cache poisoning or host-based access-control bypass); there is no public exploit code and no confirmed active exploitation at time of analysis, and Cloudflare's own CDN path was unaffected because its internal Pingora services do not accept HTTP/2 from clients.