| CVE ID |
CVSS Score |
Vulnerability Type |
Primary Impact |
| CVE-2026-2836 |
8.4 (High) |
Cache Poisoning |
Cross-origin responses and multi-tenant data leakage
|
| CVE-2026-2835 |
9.3 (Critical) |
HTTP Request Smuggling |
Bypassing WAF/ACL controls and session hijacking
|
| CVE-2026-2833 |
9.3 (Critical) |
HTTP Request Smuggling |
Bypassing security controls via premature connection upgrades
|
1. Insecure Default Cache Keys (CVE-2026-2836)
In older versions, Pingora’s alpha proxy caching feature generated cache keys using only the URI path. By omitting the host header, the system could inadvertently serve a cached response from one website to a user visiting an entirely different domain. In multi-tenant environments, this flaw creates a high risk of cross-tenant data leakage.
2. Request Smuggling via Transfer-Encoding (CVE-2026-2835)
This critical flaw stems from how Pingora handled HTTP/1.0 request bodies and multiple Transfer-Encoding values. Attackers can exploit these parsing inconsistencies to “desync” the proxy from the backend server. Once desynced, an attacker can smuggle hidden requests past security layers like Web Application Firewalls (WAFs) and Access Control Lists (ACLs).
3. Premature Upgrade Forwarding (CVE-2026-2833)
Pingora previously forwarded bytes following an Upgrade header immediately, without waiting for a formal 101 Switching Protocols response from the backend. This “premature upgrade” allows an attacker to tunnel malicious traffic through the proxy, effectively bypassing proxy-level security controls.
Mitigation and Recommendations
Immediate Action: Upgrade to Pingora v0.8.0 or higher. This version removes the insecure default cache key implementation and enforces strict RFC 9112 compliance for message parsing.
If an immediate upgrade is not possible, administrators should implement the following manual protections
- For Cache Poisoning: Manually define cache keys to include the host/authority, the upstream TLS scheme, and the HTTP method.
- For Request Smuggling: Update request filter logic to reject any non-HTTP/1.1 requests, requests with invalid Content-Length, or any Upgrade headers.
- Cloudflare Status: It is important to note that Cloudflare’s own CDN infrastructure and customers were not affected by these issues, as their custom implementations already utilized the security measures now standardized in v0.8.0.