Cloudflare patches Pingora flaws that can enable request smuggling and cache poisoning

Cloudflare has released Pingora 0.8.0 to fix three vulnerabilities that can allow HTTP request smuggling and cache poisoning in exposed standalone deployments of its open-source proxy framework. Cloudflare said its own CDN and customer traffic were not affected because it does not use Pingora in this exposed ingress pattern.

The three issues are CVE-2026-2833, CVE-2026-2835, and CVE-2026-2836. Cloudflare said users of the open-source framework should upgrade as soon as possible, because the bugs can let attackers bypass proxy-layer security controls, poison caches, and interfere with traffic handled by vulnerable self-managed deployments.

The report came from security researcher Rajat Raghav through Cloudflare’s bug bounty program. Cloudflare’s write-up describes the flaws as request smuggling and cache key issues that mainly matter when Pingora sits directly in front of backend services as an ingress proxy.

What the Pingora vulnerabilities do

The first flaw, CVE-2026-2833, involves premature handling of HTTP Upgrade requests. Cloudflare said versions before 0.8.0 could forward bytes that followed a request with an Upgrade header to the backend before the backend actually returned 101 Switching Protocols, which allowed request smuggling and proxy-control bypass.

The second flaw, CVE-2026-2835, affects the way Pingora parsed HTTP/1.0 requests and certain Transfer-Encoding combinations. Cloudflare and the advisory records say this could desynchronize Pingora’s request framing from the backend server’s framing, creating another request smuggling path.

The third flaw, CVE-2026-2836, is a cache poisoning issue in Pingora’s default cache key construction. Advisory records say the default implementation used only the URI path and ignored important values such as the host header and upstream scheme, which could let attackers force cache collisions and cause responses to bleed across origins.

Why Cloudflare customers were not affected

Cloudflare said its own managed infrastructure was not exposed to these bugs in the same way because Pingora was not deployed there as a directly exposed ingress proxy. The company made a similar distinction in its earlier 2025 Pingora disclosure, where it separated OSS framework users from its own managed service posture.

That distinction matters because the article sample overstates the risk if it treats every Pingora use case the same. Based on Cloudflare’s own description, the highest risk falls on standalone internet-facing Pingora deployments, especially those using vulnerable parsing behavior or the insecure default cache key.

Pingora flaws at a glance

What admins should do now

Cloudflare’s main recommendation is simple: upgrade Pingora to version 0.8.0 or later. The 0.8.0 release includes fixes and hardening for the parsing bugs, and it removes the insecure default CacheKey implementation.

If you cannot upgrade immediately, Cloudflare said you should reject requests with an Upgrade header as a temporary workaround for CVE-2026-2833. For CVE-2026-2835, admins should reject non-HTTP/1.1 requests and malformed Content-Length handling paths until they can patch.

For caching, Cloudflare and the GitHub advisory both say you should not rely on the old default cache key. At minimum, a safe custom cache key should include the host or :authority, the upstream TLS scheme, and the URI path, plus any other fields your deployment needs for isolation.

Why this matters

Request smuggling bugs are dangerous because they can create a mismatch between what the proxy thinks it forwarded and what the backend thinks it received. Cache poisoning bugs are dangerous because they can cause one user to receive content generated for another host or request context. In internet-facing proxy deployments, those two classes of bugs can turn a parsing mistake into a real traffic isolation problem. This is an inference from Cloudflare’s technical descriptions of the vulnerabilities and their impact.

The good news is that Cloudflare shipped the fixes quickly and documented the mitigations clearly. For most teams, the priority now is to identify exposed Pingora deployments, patch to 0.8.0 or later, and review any custom cache behavior before returning the service to normal operation. This is an inference based on the published release and advisory guidance.

FAQ