This vulnerability arises from the way Pingora constructs cache keys. The default implementation uses only the request URI path, omitting the host header and any other identifying information. Because the cache key is too narrow, an attacker can deliver a crafted request that creates a malicious cache entry. Subsequent legitimate requests that match the same path but come from different tenants or users can then return the poisoned content, exposing sensitive data or injecting malware. The weakness corresponds to CWE‑345, a cache‑poisoning flaw.

Affected users are operators who have deployed the Pingora framework as a proxy cache, particularly those on versions older than v0.8.0. The product in question is Cloudflare Pingora, a lightweight HTTP proxy framework that includes an alpha caching tier. Cloudflare’s own CDN infrastructure is not impacted because it implements a more comprehensive cache key. In any multi‑tenant deployment that relies on the insecure default cache key, the risk of cross‑tenant data leakage is heightened.

The exposure has a CVSS base score of 8.4, categorizing it as high severity. The EPSS probability is below 1 %, indicating that known exploits are rare, and the vulnerability is not listed in the CISA KEV catalog. Nevertheless, the impact is potentially widespread in multi‑tenant environments and requires no special privileges beyond the ability to send HTTP requests to the proxy. An attacker could prefix the target domain with a malicious URI path, poison the cache, and then benefit from the cached response for legitimate users. The risk is amplified in environments that proxy multiple customers through a single instance without custom cache‑key logic.