CVE-2026-2836
Cache Poisoning in Pingora Proxy Due to Insecure Cache Key
Publication date: 2026-03-05
Last updated on: 2026-03-12
Assigner: Cloudflare, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| cloudflare | pingora | to 0.8.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-345 | The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability is a cache poisoning issue found in the Pingora HTTP proxy framework's default cache key construction. The problem arises because the default cache key only uses the URI path to generate cache keys, ignoring important elements like the host header (authority). As a result, attackers can poison the cache, causing users to receive incorrect or malicious cached responses, including cross-origin responses.
How can this vulnerability impact me? :
If you use Pingora's alpha proxy caching feature with the default CacheKey implementation, this vulnerability can lead to serious impacts.
- Cross-tenant data leakage: In multi-tenant environments, attackers can poison the cache so that users from one tenant receive cached responses intended for another tenant.
- Cache poisoning attacks: Attackers can serve malicious content to legitimate users by poisoning shared cache entries.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
I don't know
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, it is strongly recommended to upgrade to Pingora version 0.8.0 or higher, which removes the insecure default cache key implementation.
If upgrading is not immediately possible, users should remove any usage of the default CacheKey implementation and explicitly implement their own cache key callback. This custom implementation should at minimum include the Host header (authority) and the upstream peer’s HTTP scheme to prevent cache poisoning.