CVE-2026-2836: Pingora HTTP Proxy Cache Poisoning Flaw

CVE-2026-2836 Overview

A cache poisoning vulnerability has been identified in the Pingora HTTP proxy framework's default cache key construction mechanism. The vulnerability stems from the default HTTP cache key implementation generating cache keys using only the URI path, while excluding critical factors such as the host header (authority). Organizations relying on the default cache key implementation are vulnerable to cache poisoning attacks, which may result in cross-origin responses being improperly served to users.

Critical Impact

This vulnerability enables cross-tenant data leakage and cache poisoning attacks in multi-tenant deployments. Attackers can poison the cache to serve malicious content to legitimate users or cause users from one tenant to receive cached responses intended for another tenant.

Affected Products

• Pingora HTTP Proxy Framework versions prior to v0.8.0
• Deployments using the default CacheKey implementation
• Multi-tenant proxy configurations relying on default cache key behavior

Discovery Timeline

• March 5, 2026 - CVE-2026-2836 published to NVD
• March 5, 2026 - Last updated in NVD database

Technical Details for CVE-2026-2836

Vulnerability Analysis

This cache poisoning vulnerability arises from a fundamental design flaw in how the default cache key is constructed within the Pingora framework. The default CacheKey implementation uses only the URI path to generate cache keys, omitting essential request attributes that differentiate requests across different origins, tenants, or schemes.

In a properly configured caching proxy, cache keys must incorporate multiple factors to ensure cache isolation between different hosts, origins, and request contexts. When the host header (authority) is not included in the cache key calculation, requests to different hosts sharing the same URI path will resolve to the same cache entry.

This creates two primary attack scenarios. First, cross-tenant data leakage becomes possible in multi-tenant deployments where an attacker can poison the cache so that users from one tenant receive cached responses originally intended for another tenant. Second, traditional cache poisoning attacks allow adversaries to serve malicious content to legitimate users by poisoning shared cache entries with attacker-controlled responses.

Cloudflare's CDN infrastructure was not affected by this vulnerability, as Cloudflare's default cache key implementation uses multiple factors to prevent cache key poisoning and never utilized the previously provided default implementation.

Root Cause

The root cause of this vulnerability lies in the insufficient default implementation of cache key generation within the Pingora framework. The default CacheKey callback only considers the URI path when constructing cache keys, failing to incorporate the host header, HTTP scheme of the upstream peer, and other request attributes that should differentiate cached responses.

This architectural oversight means that any Pingora deployment using alpha proxy caching features with the default implementation lacks proper cache isolation. Without explicit implementation of a custom cache key callback that includes appropriate differentiating factors, the cache cannot distinguish between requests from different origins.

Attack Vector

The attack vector is network-based, requiring no special privileges to execute. An attacker can exploit this vulnerability by sending crafted HTTP requests to the vulnerable Pingora proxy instance. The attack flow involves the attacker first sending a malicious request with a specific URI path, which gets cached by the proxy.

Subsequently, when legitimate users request the same URI path but potentially for a different host or origin, the proxy serves the attacker's cached response instead of fetching the correct content from the intended backend server.

The vulnerability mechanism centers on the cache key collision. When two requests with different host headers but identical URI paths are processed, they generate the same cache key. This allows an attacker controlling responses for one host to poison cache entries that will be served to users requesting content from a completely different host. For detailed technical analysis, refer to the Pingora GitHub repository.

Detection Methods for CVE-2026-2836

Indicators of Compromise

• Unexpected cache hit responses for requests that should be cache misses
• Users receiving content intended for different tenants or origins
• Anomalous cache key collisions in proxy logs
• Reports of cross-origin content being served to users

Detection Strategies

• Monitor cache hit/miss ratios for unusual patterns indicating potential poisoning
• Implement logging of host headers alongside cache key generation to identify collisions
• Audit Pingora configuration to verify custom CacheKey implementations are in use
• Review proxy access logs for requests with mismatched host headers and response origins

Monitoring Recommendations

• Configure alerting for cache entries being served to requests with non-matching host headers
• Implement anomaly detection on cache utilization patterns across different tenants
• Enable detailed cache operation logging to track key generation and entry retrieval
• Monitor for unexpected response content types or origins in cached responses

How to Mitigate CVE-2026-2836

Immediate Actions Required

• Upgrade Pingora to version v0.8.0 or higher immediately
• Audit all existing Pingora deployments for usage of the default CacheKey implementation
• Implement custom cache key callbacks that include host header and upstream HTTP scheme
• Review multi-tenant configurations for potential data isolation breaches

Patch Information

The recommended remediation is to upgrade to Pingora v0.8.0 or higher. This version removes the insecure default cache key implementation entirely, requiring users to explicitly implement their own callback that includes appropriate factors such as the Host header, origin server HTTP scheme, and other attributes specific to their caching requirements.

For users unable to immediately upgrade to v0.8.0, the mitigation path involves removing any usage of the default CacheKey and implementing a custom callback. At minimum, custom implementations should include the host header (authority) and the upstream peer's HTTP scheme to ensure proper cache isolation.

Additional technical details and upgrade guidance are available at the Pingora GitHub repository.

Workarounds

• Implement a custom CacheKey callback that includes the host header and HTTP scheme
• Disable proxy caching functionality until a proper cache key implementation is deployed
• Configure separate cache namespaces for different tenants in multi-tenant environments
• Add host header validation to reject requests with suspicious or unexpected host values

# Configuration example
# Upgrade Pingora to the patched version
cargo update -p pingora --precise 0.8.0

# Verify the installed version
cargo tree -p pingora | grep pingora