Critical HTTP Request Smuggling in Pingora Core CVE-2026-2835, Upgrade to 0.8.0

Pingora's HTTP/1.x parsing bugs let attackers desynchronize request framing and were judged severe enough to trigger immediate operational changes: Cloudflare's security team disabled traffic to vulnerable components and deployed a patch after submitting CVE-2026-2835 on March 4 at 7:15:57 PM, and the RustSec advisory database published RUSTSEC-2026-0034 on March 5, 2026. Multiple summaries cite a CVSS v4.0 base score of 9.3, and several advisories call the defect critical for standalone Pingora deployments.

The technical root cause centers on how pingora-core handled HTTP/1.0 and Transfer-Encoding headers. The EUVD/CVE summary states, "An HTTP Request Smuggling vulnerability (CWE-444) has been found in Pingora's parsing of HTTP/1.0 and Transfer-Encoding requests. The issue occurs due to improperly allowing HTTP/1.0 request bodies to be close-delimited and incorrect handling of multiple Transfer-Encoding values, allowing attackers to send HTTP/1.0 requests in a way that would desync Pingora’s request framing from backend servers’." That inconsistent interpretation of message length is the classic desynchronization exploited in request-smuggling attacks.

Exploit impact as enumerated in the advisory material is concrete and high-risk for affected deployments. The preserved impact language lists the possible outcomes exactly: "Bypass proxy-level ACL controls and WAF logic", "Poison caches and upstream connections, causing subsequent requests from legitimate users to receive responses intended for smuggled requests", and "Perform cross-user attacks by hijacking sessions or smuggling requests that appear to originate from the trusted proxy IP". Those attack paths matter when Pingora sits in front of backends that accept HTTP/1.0 requests and where upstream caches or access controls rely on proxy framing.

Affected software is pingora-core in standalone deployments prior to the fixed release; multiple sources advise upgrading to Pingora v0.8.0 or later to address the parsing fixes that align message length handling with RFC 9112. Cloudflare's published guidance contains a different line for OSS users: "No action is needed from Cloudflare customers, but if you are using the Pingora OSS framework, we strongly urge you to upgrade to a version of Pingora 0.5.0 or later." That version recommendation conflicts with the v0.8.0 guidance cited elsewhere and remains unresolved in the public notes.

Public timeline and scoring remain in flux: Cloudflare's CVE submission timestamp was logged March 4 at 7:15:57 PM, RustSec published RUSTSEC-2026-0034 on March 5, EUVD listed EUVD-2026-9511 on March 5 and shows an "Updated: 1d ago" flag, and the NVD record for CVE-2026-2835 is currently "Detail Awaiting Analysis." Aggregated reporting via Feedly included inconsistent CVSS estimates labeled HIGH and MEDIUM in separate items even as some feeds repeated the 9.3 CRITICAL figure.

Cloudflare framed its response as urgent and comprehensive: "Whether you are a customer of Cloudflare or just a user of our Pingora framework, or both, we know that the trust you place in us is critical to how you connect your properties to the rest of the Internet. Security is a core part of that trust and for that reason we treat these kinds of reports and the actions that follow with serious urgency." The company added, "After our security team escalated the vulnerability, we began investigating immediately, took steps to disable traffic to vulnerable components, and deployed a patch," and concluded, "We are confident about this patch and the additional safeguards that have been implemented, but we know that these kinds of issues can be concerning. Thank you for your continued trust in our platform. We remain committed to building with security as our top priority and responding swiftly and transparently whenever issues arise." Until maintainers reconcile the 0.5.0 versus 0.8.0 guidance and the NVD completes enrichment, operators running standalone Pingora in front of backends that accept HTTP/1.0 should plan to adopt a patched release and validate request-framing behavior in their stacks.