CVE-2026-2835 is an HTTP request smuggling flaw in Cloudflare's Pingora proxy framework, in how it parses HTTP/1.0 requests and multiple Transfer-Encoding values. NVD scores it 9.1. Standalone Pingora proxies in front of backends that accept HTTP/1.0 are most at risk. Upgrade to Pingora 0.8.0 or later.
What's affected
Cloudflare's CNA description says the issue is in Pingora's parsing of HTTP/1.0 and Transfer-Encoding requests, and that users should upgrade to Pingora v0.8.0 or higher. That release fixes it by parsing message length headers per RFC 9112 and by treating request bodies as never close-delimited. No lower bound is given, so treat earlier releases as affected.
The impact is mainly on standalone Pingora deployments in front of certain backends that accept HTTP/1.0 requests. Cloudflare says its CDN was not affected, because its ingress layers forwarded only HTTP/1.1 requests, rejected ambiguous framing such as invalid Content-Length values, and forwarded a single Transfer-Encoding chunked header for chunked requests.
This is a sibling of CVE-2026-2833, which is about connection upgrades. Both are CWE-444 (Inconsistent Interpretation of HTTP Requests) flaws fixed in the same release. If you fix one, you should be fixing both.
How to check if you're exposed
Find Pingora in your dependency tree.
cargo tree -i pingora
grep -A1 'name = "pingora' Cargo.lock
Any version below 0.8.0 is in scope.
Then look at your backends. Do any accept HTTP/1.0 requests, or accept requests with more than one Transfer-Encoding value? If your backends are strict about framing, the exposure narrows, but the fix is still the right move.
What to do now
- Upgrade pingora crates to 0.8.0 or later, refresh Cargo.lock and rebuild.
- Redeploy every service that embeds Pingora.
- As a workaround, reject any non-HTTP/1.1 request in your request filter logic, which stops processing bytes on the connection and disables downstream connection reuse. Cloudflare's text also says to reject certain other requests, but the NVD copy is cut off mid-sentence, so read the full Pingora advisory for the complete list.
- Make your backends strict about HTTP framing where you can, so a parsing disagreement has fewer places to hide.
- Run the same checks you use for CVE-2026-2833, since the two fixes ship together.
Why it matters
Message framing is the rule that says where an HTTP request body ends. HTTP/1.1 offers two ways: a Content-Length value or chunked Transfer-Encoding. The standard says what to do if both are present or if the values conflict, and the safest implementations reject ambiguous requests.
Cloudflare's description says two things went wrong in Pingora. It allowed HTTP/1.0 request bodies to be close-delimited, where the body ends when the connection closes, and it handled multiple Transfer-Encoding values incorrectly. Either one can make the proxy and a backend disagree about the length of a request, and the leftover bytes can be read by the backend as a new request.
The consequences listed are the usual smuggling ones: bypassing access control lists and web application firewall logic, poisoning caches and upstream connections, and cross-user attacks that appear to come from the proxy's trusted address.
The record does not flag exploitation in the wild, and the CVE is not in CISA's Known Exploited Vulnerabilities catalog. Because Pingora is a library compiled into your service, a patched upstream does nothing until you rebuild.
Quick check
How is this different from CVE-2026-2833?
CVE-2026-2833 concerns connection upgrades. This one concerns HTTP/1.0 bodies and multiple Transfer-Encoding values. Both are fixed in Pingora 0.8.0.
Does it matter if my backend is strict?
It narrows the exposure, since the description says the risk is highest in front of backends that accept HTTP/1.0. Upgrading is still the correct fix.
Sources
Last reviewed: 19 October 2026.
