In a recent security advisory, Cloudflare disclosed multiple HTTP request smuggling and cache poisoning vulnerabilities in its open-source Pingora framework.
Tracked under the identifiers CVE-2026-2833, CVE-2026-2835, and CVE-2026-2836, these flaws specifically impact standalone Pingora deployments that are exposed directly to the internet as ingress proxies.
Cloudflare has explicitly confirmed that its own Content Delivery Network and customer traffic are completely safe.
Because Cloudflare does not use Pingora as an ingress proxy on its edge network, the vulnerabilities could not be exploited against their internal infrastructure.
How the Request Smuggling Vulnerabilities Work
Request smuggling occurs when a front-end proxy server and a backend application server disagree about where a single HTTP request ends and a new one begins.
This confusion allows an attacker to hide a malicious request inside a normal one. When the proxy forwards the data, the backend processes the hidden request as if it belonged to the next unsuspecting user.
Security researcher Rajat Raghav discovered three distinct ways to trigger these severe desynchronization attacks in Pingora:
Premature Protocol Upgrade
When an attacker sent an HTTP ‘Upgrade’ header, Pingora immediately switched to a direct passthrough mode.
It did this before the backend server officially accepted the upgrade with a ‘101 Switching Protocols’ response.
An attacker could exploit this premature action by pipelining a second, malicious HTTP request immediately after the upgrade request.
Pingora would blindly forward this smuggled request to the backend, bypassing critical access controls and security checks.
Misinterpretation of HTTP/1.0 Framing
Pingora exhibited dangerous leniency when processing older HTTP/1.0 requests that contained conflicting headers, such as both ‘Content-Length’ and ‘Transfer-Encoding’.
Instead of safely rejecting these poorly formed requests as required by strict internet standards, Pingora treated the request body as close-delimited.
This flawed interpretation allowed an attacker to attach partial HTTP headers to the end of a request, causing a severe desynchronization with the backend server.
Insecure Default Cache Keys
The third vulnerability involved how Pingora stored cached data for its users. The default code implementation for creating a cache key only looked at the URL path, ignoring the website host and the HTTP protocol scheme.
Because of this oversight, different websites using the exact same path could collide in the proxy cache.
An attacker could exploit this to poison the cache, ensuring that visitors to a legitimate site received malicious or altered content instead.
Exploitation Impact
Organizations using standalone Pingora deployments as front-line reverse proxies face severe risks if these flaws are left unpatched. Successful exploitation allows an attacker to:
- Bypass proxy-layer security controls, including custom rules and web application firewalls.
- Hijack active user sessions and steal sensitive credentials by desynchronizing requests between the proxy and shared backends.
- Poison proxy caches, forcing the server to distribute malicious payloads to normal users.
Cloudflare engineering rapidly investigated the bug bounty reports and introduced comprehensive fixes.
The framework now strictly enforces internet standards for request framing, properly validates chunked encodings, and waits for backend confirmation before upgrading connections. The insecure default cache key has also been completely removed.
Security teams managing Pingora deployments should take immediate action:
- Upgrade all Pingora framework instances to version 0.8.0 immediately.
- Verify that custom cache key designs include the host header and HTTP scheme to prevent cache poisoning collisions.
- Monitor ingress proxy logs for abnormal HTTP/1.0 requests or unexpected upgrade headers.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
