CVE-2026-2833 is an HTTP request smuggling flaw in Cloudflare's Pingora proxy framework, in how it handles HTTP/1.1 connection upgrades. NVD scores it 9.1. Standalone Pingora proxies exposed to external traffic are the main concern. Upgrade to Pingora 0.8.0 or later, or apply the workaround in your request filter.
What's affected
Cloudflare's CNA description says the flaw affects Pingora's handling of HTTP/1.1 connection upgrades and that users should upgrade to Pingora v0.8.0 or higher. The description does not list a lower bound for affected versions, so treat any release before 0.8.0 as affected.
The impact is primarily on standalone Pingora deployments where a Pingora proxy is exposed to external traffic. Cloudflare states that its own CDN infrastructure was not affected, because its ingress proxies keep proper HTTP parsing boundaries and do not switch early to upgraded connection forwarding.
If you build a gateway, load balancer or API proxy on the pingora crates, this is a dependency issue in your Rust project. If you only use a service that is fronted by Cloudflare's CDN, the vendor statement says that path is not affected.
The weakness is CWE-444 (Inconsistent Interpretation of HTTP Requests), commonly called HTTP request smuggling.
How to check if you're exposed
Check whether your Rust projects depend on Pingora and which version is pinned.
cargo tree -i pingora
grep -A1 'name = "pingora' Cargo.lock
Look at the version on the pingora, pingora-core and pingora-proxy lines. Anything below 0.8.0 needs the upgrade.
Then check your deployment shape. Is a Pingora proxy facing the internet directly, or is it behind another layer that already normalises requests? The advisory says standalone, externally exposed deployments are the main concern. Also look in your request filter code to see whether requests carrying an Upgrade header are handled specially.
What to do now
- Upgrade pingora crates to 0.8.0 or later, update Cargo.lock and rebuild.
- Redeploy every service built on Pingora. A recompile is required, because Pingora is a library, not a running service you can patch in place.
- As a workaround before you can deploy, return an error for requests that include an Upgrade header in your request filter logic. Cloudflare says this stops processing bytes beyond the request header and disables downstream connection reuse.
- If your backends rely on legitimate protocol upgrades such as WebSocket, test the workaround first, because it will reject those requests.
- Review cache and session behaviour for signs of cross-user responses around the period you ran an affected version.
Why it matters
Request smuggling happens when two HTTP parsers disagree about where one request ends and the next begins. A proxy and its backend must agree on that boundary. If an attacker can make them disagree, bytes the proxy treats as part of one request can be read by the backend as the start of another.
Cloudflare's description of this bug is specific. When the proxy sees an Upgrade header, it passes the remaining bytes on the connection to the backend before the backend has accepted the upgrade. An attacker can put a second request in those bytes. The proxy never inspects it, so rules like access control lists and web application firewall logic do not apply to it.
The impact list in the advisory is useful to read as a threat model. It names bypass of proxy level controls, cache and connection poisoning, and cross-user attacks that look as if they came from the trusted proxy address. The shared theme is that the proxy's trust is borrowed by the smuggled request.
The fix is in the library, which means each downstream project has to rebuild. That is the part that is easy to miss with a framework crate: the vulnerable code is compiled into your binary. An accurate dependency inventory is what tells you which of your services need a new build.
The record does not flag exploitation in the wild, and the CVE is not in CISA's Known Exploited Vulnerabilities catalog.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is Cloudflare's CDN affected?
Cloudflare says no. Its ingress proxies maintain proper HTTP parsing boundaries and do not switch early to upgraded connection forwarding.
What is the interim workaround?
Return an error for requests with an Upgrade header in your request filter logic. That stops the proxy from processing bytes past the header and disables downstream connection reuse. It will also block legitimate upgrades, so test it.
Do I need to rebuild after upgrading the crate?
Yes. Pingora is a Rust library, so the fix reaches production only when you rebuild and redeploy your service.
Sources
Last reviewed: 19 October 2026.
