CVE-2026-2835: 
Rust vulnerability analysis and mitigation

CVE-2026-2835 is an HTTP Request Smuggling vulnerability (CWE-444) in Cloudflare's Pingora proxy framework, affecting all versions prior to 0.8.0 (i.e., ≤ 0.7.0 of the pingora-core Rust crate). The flaw stems from Pingora improperly allowing HTTP/1.0 request bodies to be close-delimited and incorrectly handling multiple Transfer-Encoding values, enabling attackers to desync Pingora's request framing from backend servers. The vulnerability was disclosed on March 4–5, 2026, and was reported responsibly by Rajat Raghav (@xclow3n) through the Cloudflare Bug Bounty Program. It carries a CVSS v4.0 base score of 9.3 (Critical) and a CVSS v3.1 base score of 9.1 (Critical) (Github Advisory, NVD).

The root cause is classified as CWE-444 (Inconsistent Interpretation of HTTP Requests / HTTP Request Smuggling). Pingora versions before 0.8.0 violated RFC 9112 in two ways: (1) they permitted HTTP/1.0 request bodies to be close-delimited (i.e., terminated by connection close rather than an explicit Content-Length or Transfer-Encoding), and (2) they failed to reject or normalize requests carrying multiple Transfer-Encoding headers. An unauthenticated, remote attacker can craft a specially formed HTTP/1.0 request that Pingora parses differently than the backend server, causing the backend to interpret trailing bytes as the beginning of a new, attacker-controlled request. No authentication or user interaction is required. The fix, applied in commits 7f7166d, 40c3c1e, and 87e2e2f, enforces strict RFC 9112 message-length parsing and removes close-delimiting of request bodies (Github Advisory, NVD).

Successful exploitation allows an attacker to smuggle arbitrary HTTP requests to backend servers behind a Pingora proxy, with three primary consequences: bypassing proxy-level ACL controls and WAF logic (allowing access to restricted resources), poisoning caches and upstream connections (causing legitimate users to receive responses intended for smuggled requests), and performing cross-user attacks by hijacking sessions or making requests appear to originate from the trusted proxy IP. The vulnerability has high integrity and confidentiality impact on subsequent systems. Notably, Cloudflare's own CDN infrastructure was not affected because its ingress layers forwarded only HTTP/1.1 requests and rejected ambiguous framing (Github Advisory, NVD).

As of the time of disclosure, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (Github Advisory). The EPSS score is approximately 0.018–0.048%, indicating a low near-term exploitation probability. No threat actor attribution has been reported, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The vulnerability is exploitable by any unauthenticated remote attacker against standalone Pingora deployments fronting backends that accept HTTP/1.0 requests, making the attack surface meaningful for self-hosted Pingora users.

1. Reconnaissance: Identify internet-facing services running a standalone Pingora proxy (versions ≤ 0.7.0) in front of a backend that accepts HTTP/1.0 requests. This can be done via banner analysis, HTTP response headers, or service fingerprinting tools such as Shodan or Censys.
2. Craft ambiguous HTTP/1.0 request: Construct an HTTP/1.0 request that exploits one of two parsing flaws — either a close-delimited body (no Content-Length or Transfer-Encoding, relying on connection close to signal body end) or a request with multiple Transfer-Encoding headers (e.g., Transfer-Encoding: identity\r\nTransfer-Encoding: chunked).
3. Append smuggled request: Append a second, attacker-controlled HTTP request as the "body" of the first request. Because Pingora misparses the message boundary, it forwards both the outer and inner requests to the backend as a single stream, but the backend interprets them as two separate requests.
4. Achieve smuggling objective: Depending on the goal, the smuggled request can: (a) target a restricted backend endpoint to bypass ACL/WAF rules, (b) poison a shared cache entry so subsequent legitimate users receive the attacker's crafted response, or (c) prepend attacker-controlled headers to a victim's next request to hijack their session (Github Advisory, NVD).

• Network: Unexpected HTTP/1.0 requests reaching the Pingora proxy, particularly those lacking a Content-Length header or containing multiple Transfer-Encoding headers; anomalous backend requests appearing to originate from the proxy IP for resources not requested by any known client.
• Logs: Pingora access logs showing HTTP/1.0 requests with ambiguous framing (missing Content-Length, duplicate Transfer-Encoding values, or Transfer-Encoding values other than exactly chunked); backend access logs recording requests that do not correspond to any client-visible request in the proxy logs.
• Application Behavior: Legitimate users receiving unexpected responses (e.g., responses intended for other users or for internal endpoints); cache entries containing unexpected or attacker-controlled content; session tokens or authentication cookies appearing in requests from unexpected source IPs.

Cloudflare has released Pingora v0.8.0, which fixes this vulnerability by correctly parsing message-length headers per RFC 9112 and ensuring HTTP request bodies are never close-delimited. All users of pingora-core ≤ 0.7.0 should upgrade to v0.8.0 or higher immediately. As an interim workaround (without upgrading), operators should implement request filter logic to reject: any non-HTTP/1.1 request, requests with an invalid Content-Length, requests with multiple Transfer-Encoding headers, or requests where the Transfer-Encoding value is not an exact match for the string chunked. Rejecting such requests must also disable downstream connection reuse to prevent desync (Github Advisory, NVD).

The vulnerability received notable coverage from security news outlets including GBHackers, CyberSecurityNews, SecurityOnline, and The Hacker News (in their weekly recap), highlighting the cache poisoning and request smuggling risks for self-hosted Pingora deployments (GBHackers, SecurityOnline, The Hacker News). Cloudflare explicitly noted in the advisory that its own CDN infrastructure was unaffected, which helped limit alarm among Cloudflare customers while still urging standalone Pingora users to patch promptly. The vulnerability was also catalogued in the RustSec advisory database as RUSTSEC-2026-0034, reflecting the Rust ecosystem's active security tracking (RustSec).