CVE-2026-2836: 
Rust vulnerability analysis and mitigation

CVE-2026-2836 is a cache poisoning vulnerability in the Pingora HTTP proxy framework's default cache key construction, titled "Cache poisoning via insecure-by-default cache key." The flaw affects the pingora-cache Rust crate in all versions up to and including 0.7.0, and was disclosed on March 5, 2026, after responsible disclosure by Rajat Raghav (@xclow3n) through the Cloudflare Bug Bounty Program. Cloudflare's own CDN infrastructure was explicitly not affected. The vulnerability carries a CVSS v3.1 base score of 8.1 (High) and a CVSS v4.0 base score of 8.4 (High) (Github Advisory, Pingora Repo).

The root cause is classified under CWE-345 (Insufficient Verification of Data Authenticity) and CWE-639 (Authorization Bypass Through User-Controlled Key). The default CacheKey implementation in Pingora's alpha proxy caching feature constructed cache keys using only the URI path, entirely omitting the HTTP Host header (authority) and upstream peer TLS scheme. This means that requests to different virtual hosts or origins sharing the same URI path would collide on the same cache entry, allowing an attacker to craft requests that cause the cache to store and serve responses intended for one origin to users of another. Exploitation requires no privileges and no special attack complexity, though passive user interaction (a legitimate user making a request) is needed to trigger cache serving (Github Advisory, Pingora Repo).

Successful exploitation can result in cross-tenant data leakage and content integrity violations. In multi-tenant deployments, an attacker can poison shared cache entries so that users from one tenant receive cached responses belonging to another tenant, exposing potentially sensitive data. Additionally, attackers can serve malicious or manipulated content to legitimate users by poisoning shared cache entries, impacting both confidentiality (of subsequent system data) and integrity of responses delivered to end users; availability is not directly impacted (Github Advisory, Pingora Repo).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of disclosure (Github Advisory). The EPSS score is approximately 0.01% (1st percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Identify target: Locate a Pingora-based proxy (versions ≤ 0.7.0) that uses the default CacheKey implementation and serves multiple virtual hosts or tenants sharing the same URI path space.
2. Craft a poisoning request: Send an HTTP request to the proxy targeting a URI path (e.g., /api/user/profile) with a manipulated or attacker-controlled Host header pointing to a victim tenant's origin, while the cache key resolves only to the URI path.
3. Poison the cache: Ensure the proxy caches the attacker-controlled or cross-origin response under the URI-path-only cache key, which will be shared across all hosts using that path.
4. Trigger victim request: Wait for or induce a legitimate user from the target tenant to request the same URI path. The proxy serves the poisoned cache entry — which may contain another tenant's data or attacker-injected content — instead of the correct response.
5. Achieve objective: Depending on the poisoned content, the attacker achieves cross-tenant data leakage (reading another tenant's response) or delivers malicious content to the victim user (Github Advisory, Pingora Repo).

• Network: Unusual HTTP requests to a Pingora proxy with varying Host headers but identical URI paths, particularly from unexpected source IPs; responses served to users that do not match the expected origin for their tenant.
• Logs: Proxy access logs showing cache hits for requests where the Host header differs from the origin that originally populated the cache entry; anomalous cross-tenant response patterns in cache hit/miss logs.
• Application Behavior: Users reporting receiving content or data belonging to other tenants; unexpected or malicious content appearing in cached responses for known-good URI paths.

The primary remediation is to upgrade the pingora-cache crate to version 0.8.0 or higher, which removes the insecure default CacheKey implementation entirely (Github Advisory). For operators unable to upgrade immediately, the workaround is to stop relying on the default CacheKey and implement a custom cache key callback that at minimum incorporates the Host/:authority header and the upstream peer's TLS scheme, along with any other factors relevant to the deployment (e.g., HTTP method). Operators should audit all usages of the default CacheKey in their Pingora-based proxies and replace them with explicit, multi-factor implementations (Pingora Repo).

The vulnerability received coverage from multiple security news outlets including GBHackers, CyberSecurityNews, SecurityOnline, and IT Security News, often grouped with a related HTTP request smuggling flaw also patched in Pingora v0.8.0 (SecurityOnline, GBHackers). The Hacker News weekly recap also referenced the Pingora patches. Cloudflare explicitly noted in the advisory that its own CDN infrastructure was unaffected, which was highlighted in community discussions as a mitigating factor for the broader internet. The vulnerability was responsibly disclosed through Cloudflare's Bug Bounty Program, which was noted positively by the security community.