CDNs and reverse proxies speed up the Web by sharing responses across requests. This optimization relies on one essential assumption: two requests producing the same cache key must actually be safe to serve the same response.
What is a cache key for?
To decide whether a stored response can be reused, a cache builds a key from request elements such as scheme, host, URI, parameters and sometimes selected headers or cookies. When the same key appears again, the cache can directly serve the associated response.
Configurations become more delicate when variable-length values are added to that key. If their boundaries are not represented unambiguously, two different combinations can produce the same final string.
What cache key injection changes
YesWeHack’s research focuses on these collisions. Unlike many cache-poisoning scenarios that exploit data absent from the key, cache key injection targets fragments that are themselves part of key construction.
In controlled Nginx demonstrations, these collisions can lead, depending on context, to web cache deception, cache-poisoned denial of service (CPDoS), access-control bypass or, when several additional conditions are met, stored XSS.
Multiple caches, multiple interpretations
A modern architecture can layer a CDN and an origin cache: browser → CDN → Nginx → application. These layers do not necessarily make the same decisions or build their keys in the same way.
In its lab, YesWeHack shows that under certain conditions a request can bypass a Cloudflare edge cache and reach an Nginx cache behind it. This does not mean a CDN automatically makes a deployment vulnerable; it shows why each caching layer must be understood and configured independently.
How to reduce the risk
- Preserve boundaries between key components with separators or an unambiguous structured representation.
- Limit client-controlled values in the key to data that genuinely changes the representation served.
- Review Cache-Control and Vary policies to avoid sharing responses that should remain distinct.
- Treat each cache layer separately: CDN, reverse proxy and application may follow different rules.
- Use unique identifiers and avoid affecting users when cache behavior must be checked in production.
Hashing an ambiguous key does not remove the ambiguity
If two sets of values already produce the same string before hashing, they will still produce the same result after hashing. The fix must preserve component structure and boundaries before that step.
What InfraCheck could observe without poisoning a cache
A public scanner should not reproduce scenarios that could modify a shared entry and affect other visitors. Several signals can still be collected passively or with isolated requests.
- inventory cache-related headers such as
Cache-Control,Age,Varyand CDN-specific indicators; - flag sensitive responses that appear publicly cacheable;
- identify the likely presence of multiple cache layers;
- compare responses with unique cache busters to avoid touching a shared entry;
- keep a history of cache-policy changes.
This type of check would not automatically prove that cache key injection is exploitable. It would instead flag an HTTP cache exposure worth reviewing, together with the observations supporting that finding.
Observe the logic, not only the headers
A cache is a shared logic layer. Its security depends as much on how it distinguishes requests as on the headers visible in a response. YesWeHack’s research reinforces a useful rule: when an infrastructure has several intermediaries, verify that each one shares exactly the responses you expect — no more and no less.
Source
Published September 18, 2026. Technical details are summarized from the public research cited above.