Fixing request smuggling vulnerabilities in Pingora OSS deployments

Pingora 0.8.0 fixes three HTTP/1.x request-smuggling vulnerabilities affecting standalone deployments used as Internet-facing ingress proxies. The flaws could let attackers bypass proxy security controls, desynchronize connections with backends, hijack other users’ sessions, or poison shared caches. Cloudflare’s own CDN was not affected, but Pingora users are urged to upgrade immediately.

Scope and Impact

• Vulnerabilities:
  • CVE-2026-2833
  • CVE-2026-2835
  • CVE-2026-2836
• Reported through Cloudflare’s bug bounty program in December 2025.
• Affected deployments are standalone Pingora proxies exposed directly to the Internet.
• Potential consequences included:
  • Bypassing ACL and WAF checks at the proxy layer.
  • Desynchronizing Pingora and backend HTTP connections.
  • Cross-user session or credential theft.
  • Cache poisoning when shared backends are used.
• Cloudflare’s CDN was not vulnerable because Pingora is not used as its ingress proxy, and internal clients did not send pipelineable HTTP/1 requests to affected services.

Premature Upgrade Without a 101 Response

• Pingora treated a request containing an Upgrade header as an upgraded, pass-through connection immediately.
• Under RFC 9110, the connection should switch protocols only after the backend returns 101 Switching Protocols.
• If the backend instead returned 200 OK, Pingora could still forward subsequent bytes directly to the backend.
• An attacker could pipeline a second, partial request—such as /admin—after the initial upgrade request.
• This bypassed Pingora’s normal ACL or WAF processing and left Pingora and the backend disagreeing about request boundaries.
• A later request from another user could complete the attacker’s partial request, causing the backend to return the attacker’s response to the wrong user.
• Pingora 0.8.0 now enables pass-through mode only after receiving a valid 101 response.

HTTP/1.0, Close-Delimited Bodies, and Transfer-Encoding

• Another attack resembled a classic CL.TE desynchronization:
  • Pingora used Content-Length to determine the request body length.
  • The backend interpreted Transfer-Encoding: chunked and ended the body at the zero-length chunk.
• The example combined:
  • HTTP/1.0
  • Connection: keep-alive
  • Multiple transfer encodings
  • Both Transfer-Encoding and Content-Length
• Pingora’s earlier transfer-encoding detection was too simplistic:
  • It only checked whether Transfer-Encoding contained “chunked.”
  • It assumed a single encoding or header.
• HTTP specifications require the final transfer encoding to determine whether chunked framing applies, creating disagreement between Pingora and backend servers such as Node.js.
• These differing interpretations of body boundaries enabled attackers to smuggle a second request through the proxy.

Hardening and Recommendation

Pingora 0.8.0 corrects the HTTP/1 framing and upgrade handling issues and adds defensive hardening. Operators running Pingora as an ingress proxy should upgrade as soon as possible and review whether their deployments expose HTTP/1 connections directly to untrusted clients.