Cache key injection has a 2020 name, four 2026 lab demonstrations, no CVE and no named victim

2,234 days, four lab demonstrations and no CVE

James Kettle's paper on cache entanglement, published by PortSwigger on 5 August 2020, already had two sections headed Cache Key Injection, one on Akamai and one on Cloudflare. YesWeHack published its own write-up under that name on 17 September 2026, 2,234 days later (our count). The 2026 piece shows four demonstrations against Nginx caches in a controlled environment. It cites no CVE, names no vendor advisory and describes no victim. The Hacker News summarised it in its ThreatsDay bulletin on 1 October, 14 days after the write-up.

That count matters for what it does not establish. It does not show that any live site is vulnerable today. It does not show that anyone is using the technique: at 17:00 BST on Monday 5 October 2026 the CISA Known Exploited Vulnerabilities catalogue, version 2026.10.04, had no entry that names Nginx or cache key collisions. It does not say how many sites build cache keys without separators, because the write-up does not count them. And it does not call Nginx defective. It shows how keys written in Nginx configuration can collide, and says that even the common pattern of scheme, host and request URI can be vulnerable under certain conditions.

The briefing is still worth reading, for a reason that has nothing to do with news. A cache is a shared memory of responses, addressed by a string. The line that builds the string decides which users are given the same answer. Whoever owns that line is making an access control decision, whatever the change request calls it.

What the write-up claims, at the level a defender needs

A cache decides whether it already holds the answer to a request by computing a key from parts of the request. RFC 9111, the HTTP caching standard, says the key is "composed from, at a minimum, the request method and target URI", and that caches may add more. In Nginx the key is a string the administrator writes with variables. The documented default joins the scheme, the proxy host and the request URI, and Nginx names each cache file by applying MD5 to the key (Nginx documentation, read 5 October). YesWeHack notes that developers often add headers or cookies to the key so that login state or language changes the answer.

The claim is that when a key joins such fragments with no boundary between them, different splits of the same characters produce the same string. Move characters from one request field into the next, and two requests that look different to every other component produce one key. Hashing the string afterwards does not help, because equal strings give equal hashes. The write-up's own test for a shared cache is correspondingly small: split a harmless test value across two adjacent fields and see whether the second request is answered with the first one's cached response. It insists on a unique cache buster when testing a real environment, because otherwise the test request can poison an entry that real users receive.

Who receives the stored answer depends on which request filled the entry first. The write-up reports four demonstrations. Each was reproduced in a controlled environment, in its words, with Nginx as a caching proxy in front of a backend application, and Cloudflare in front of Nginx for the layered one.

The four demonstrations in the write-up, summarised without the requests. Source: YesWeHack, 17 September 2026.

1. Demonstration

   Cache deception with no click

   What had to be true in the lab

   A global key that includes a request header, a rule limiting one path to the local address, the restricted page already cached, and a 30 second lifetime

   Effect it names

   A requester who is not allowed receives the cached restricted page

2. Demonstration

   Cache-poisoned denial of service

   What had to be true in the lab

   The colliding request arrives before real users have cached the target page, and the origin answers it with a not-found error that is then cached

   Effect it names

   Later visitors receive the cached error until it expires

3. Demonstration

   Stored cross-site scripting via scheme and host

   What had to be true in the lab

   Key starts with scheme then host, Nginx accepts an attacker-set Host header, the same content is served on ports 80 and 443 without a redirect, and the backend reflects the host into a script source on a cacheable page

   Effect it names

   Script from a domain the attacker controls runs when a victim loads the cached page

4. Demonstration

   Edge bypass to an origin cache

   What had to be true in the lab

   Cloudflare in front of Nginx. An Authorization header makes Cloudflare bypass its cache, while Nginx does not apply the same rule unless configured to

   Effect it names

   The origin cache can be poisoned, and a later request may receive the entry once the edge copy is absent or expired

Demonstration	What had to be true in the lab	Effect it names
Cache deception with no click	A global key that includes a request header, a rule limiting one path to the local address, the restricted page already cached, and a 30 second lifetime	A requester who is not allowed receives the cached restricted page
Cache-poisoned denial of service	The colliding request arrives before real users have cached the target page, and the origin answers it with a not-found error that is then cached	Later visitors receive the cached error until it expires
Stored cross-site scripting via scheme and host	Key starts with scheme then host, Nginx accepts an attacker-set Host header, the same content is served on ports 80 and 443 without a redirect, and the backend reflects the host into a script source on a cacheable page	Script from a domain the attacker controls runs when a victim loads the cached page
Edge bypass to an origin cache	Cloudflare in front of Nginx. An Authorization header makes Cloudflare bypass its cache, while Nginx does not apply the same rule unless configured to	The origin cache can be poisoned, and a later request may receive the entry once the edge copy is absent or expired

Two phrases in the write-up deserve to be kept next to the table. On the stored script case it says each condition is "relatively common" but the exploit "requires all of them to exist together". On severity it lists four things it depends on: the affected endpoint, the cache lifetime, the number of users sharing the cache and whether the poisoned response propagates through edge or origin layers. It gives no score, no count of affected sites and no victim.

What is stated, and what is not

Match each verb to the evidence. This table sets the record next to the gaps in it.

Stated and not stated, from the YesWeHack write-up read in full on 5 October 2026, with KEV and nginx.org read the same afternoon.

1. Question

   Is the technique real?

   Stated

   Two requests can share one key when fragments are joined without boundaries; four lab demonstrations

   Not stated

   How many deployed caches are built that way

2. Question

   Which products?

   Stated

   Nginx caches in a lab; Cloudflare in front of Nginx for one demonstration

   Not stated

   Any named production site, customer or software version; any vendor acknowledgement

3. Question

   Is there a CVE or advisory?

   Stated

   None cited in the write-up

   Not stated

   Whether the Nginx project treats the pattern as a flaw. Its advisory page mentions no cache issue (read 5 October)

4. Question

   Is it exploited?

   Stated

   Examples reproduced in a controlled environment

   Not stated

   Any attack outside the lab. KEV 2026.10.04 has no entry naming Nginx or key collisions

5. Question

   How severe?

   Stated

   Depends on endpoint, cache lifetime, users sharing the cache and propagation across layers

   Not stated

   A score, a count of affected sites, or a rating of any one demonstration

6. Question

   What is the fix?

   Stated

   Keep each component's boundary and meaning before any hash is taken

   Not stated

   A tested change for any product, or whether any vendor documentation will change

7. Question

   Is the idea new?

   Stated

   Called an underestimated technique; Kettle's 2020 paper is listed in its references

   Not stated

   That it is the first description of the idea, or what the 2020 paper found about key injection

8. Question

   Did the lab backend send private or no-store?

   Stated

   The restricted page was cached under a 30 second lifetime in the lab configuration

   Not stated

   Whether the backend sent Cache-Control private or no-store, or why the page was cacheable

Question	Stated	Not stated
Is the technique real?	Two requests can share one key when fragments are joined without boundaries; four lab demonstrations	How many deployed caches are built that way
Which products?	Nginx caches in a lab; Cloudflare in front of Nginx for one demonstration	Any named production site, customer or software version; any vendor acknowledgement
Is there a CVE or advisory?	None cited in the write-up	Whether the Nginx project treats the pattern as a flaw. Its advisory page mentions no cache issue (read 5 October)
Is it exploited?	Examples reproduced in a controlled environment	Any attack outside the lab. KEV 2026.10.04 has no entry naming Nginx or key collisions
How severe?	Depends on endpoint, cache lifetime, users sharing the cache and propagation across layers	A score, a count of affected sites, or a rating of any one demonstration
What is the fix?	Keep each component's boundary and meaning before any hash is taken	A tested change for any product, or whether any vendor documentation will change
Is the idea new?	Called an underestimated technique; Kettle's 2020 paper is listed in its references	That it is the first description of the idea, or what the 2020 paper found about key injection
Did the lab backend send private or no-store?	The restricted page was cached under a 30 second lifetime in the lab configuration	Whether the backend sent Cache-Control private or no-store, or why the page was cacheable

The press coverage ran ahead of that record. GBHackers and Cybersecurity News, both dated 21 September, used headlines of the form "Lets Hackers" and "Hackers Can". Those describe a capability shown in a lab. The Hacker News bulletin of 1 October is more careful: it describes a technique and names no product, which also means it never says Nginx.

Class, product bug and exploitation are three separate questions

A research write-up can answer one of three questions. Is the pattern real? Is a particular product wrong and fixed? Is anyone using it? This one answers the first.

The class is older than the write-up. In his 2020 paper, Kettle describes Akamai bundling the components of a key into one string "without bothering to escape delimiters", shows two different requests that share a key, and says Akamai was working on a fix. For Cloudflare he reports that its security team said the documentation did appear to be wrong about the key, and that the company then patched the issue by escaping delimiters. The paper page is marked updated on 3 September 2025 and does not say whether Akamai's fix shipped. PortSwigger's Web Security Academy teaches the same idea under the heading Cache key injection, with a lab. The 2026 write-up differs in a way that is worth stating exactly: its Nginx keys have no delimiter between the variables, and it frames the problem as exploiting keyed fragments rather than unkeyed ones.

Both publishers sell something beside this research. YesWeHack runs a bug bounty and testing platform, and its page carries those product links. PortSwigger sells Burp Suite, and its Academy page ends with an invitation to try it. That is context, not a criticism of the research.

The product-bug record exists, but not for this write-up. The write-up cites no CVE, so we searched NVD for the same shape of bug. The keyword searches "cache key collision" and "cache key injection" returned 12 and 6 records on 5 October, and four of them describe cache keys that collide because they are built ambiguously, without enough uniqueness or without validation. None is cited by YesWeHack and none is an Nginx proxy cache. The list is a sample, not a census.

Cache key collision bugs with CVE numbers, found by our NVD search on 5 October 2026. Exploitation column is the CISA-ADP SSVC field as NVD shows it.

1. Record and published

   CVE-2026-39972, 9 April 2026

   Product and fix

   Mercure, fixed in 0.22.0

   What the record says

   Key built by joining two names with an underscore. Both can contain underscores, so two different pairs give one key

   Exploitation (CISA-ADP)

   none, assessed 9 April 2026

2. Record and published

   CVE-2026-25480, 9 February 2026

   Product and fix

   Litestar FileStore, fixed in 2.20.0

   What the record says

   Keys mapped to filenames without separators, so one URL can serve another's cached response

   Exploitation (CISA-ADP)

   none, assessed 10 February 2026

3. Record and published

   CVE-2026-35039, 6 April 2026

   Product and fix

   fast-jwt, fixed in 6.2.0

   What the record says

   A custom key builder that does not make unique keys can return one user's claims for another token

   Exploitation (CISA-ADP)

   none, assessed 7 April 2026

4. Record and published

   CVE-2020-13254, 3 June 2020

   Product and fix

   Django 2.2.13 and 3.0.7

   What the record says

   A memcached backend without key validation can collide keys, with potential data leakage

   Exploitation (CISA-ADP)

   no SSVC entry on the record

Record and published	Product and fix	What the record says	Exploitation (CISA-ADP)
CVE-2026-39972, 9 April 2026	Mercure, fixed in 0.22.0	Key built by joining two names with an underscore. Both can contain underscores, so two different pairs give one key	none, assessed 9 April 2026
CVE-2026-25480, 9 February 2026	Litestar FileStore, fixed in 2.20.0	Keys mapped to filenames without separators, so one URL can serve another's cached response	none, assessed 10 February 2026
CVE-2026-35039, 6 April 2026	fast-jwt, fixed in 6.2.0	A custom key builder that does not make unique keys can return one user's claims for another token	none, assessed 7 April 2026
CVE-2020-13254, 3 June 2020	Django 2.2.13 and 3.0.7	A memcached backend without key validation can collide keys, with potential data leakage	no SSVC entry on the record

Two lessons sit in that table. First, where a maintainer treated a collision as a flaw, the record shows a CVE and a fixed version. Nothing like that exists on the record we read for the Nginx demonstrations. Second, the Mercure row shows that a separator is not a cure by itself. An underscore was used and still collided, because values could contain underscores. The scores also differ: GitHub's CNA scored fast-jwt 9.1 and Litestar 6.5 under CVSS 3.1 and Mercure 7.1 under CVSS 4.0, while NVD scored Django 5.9 under 3.1. The class has no single severity, which fits the write-up's own point that impact depends on the endpoint.

Nothing on the record says it is used. KEV 2026.10.04 contains no entry whose vendor, product, name or description mentions Nginx, key collision, cache poisoning or cache deception. The nearest are two entries from August 2022 for different bugs: CVE-2022-22536, HTTP request smuggling in SAP products that KEV says can poison intermediary web caches, and CVE-2022-27924, memcache command injection in Zimbra that overwrites cached entries. Neither is this technique. We found no statement from the Nginx project, F5, Cloudflare or Akamai on the write-up, and a missing statement is not evidence either way. The accurate verb for this research is demonstrated, not exploited.

A cache is not a performance layer

The friendly names do the damage. "Cache" and "CDN" read as speed. The NCSC's denial of service guidance, last reviewed on 25 March 2024, tells organisations to consider deploying a CDN and spends its warning on supplier trust and hiding the origin. It describes a CDN as serving static content and managing dynamic requests, and it does not mention how a CDN decides who shares an answer. We searched the page for the word cache and found none.

The standards say it more plainly than the labels do. RFC 9111 defines the cache key as the information a cache uses to choose a response, and its section 7.3 warns that deployment flaws "often led to by the misunderstanding of cache operation" can expose sensitive information to unauthorised parties. Its mechanism for varying a response by header, the Vary field, compares field by field: a stored response may be reused only if the nominated request header fields match those in the original request. RFC 9110 puts it as "Vary expands the cache key". On our reading, that wording leaves no room to blur a path into a header. The blurring happens in local key strings that a person writes, which is inference on our part, not something the RFCs say.

Application security standards have the same reading. OWASP's ASVS 5.0.0 asks, at level 2 in requirement 14.2.2, that applications stop sensitive data being cached in server components "such as load balancers and application caches", and, at level 3 in 14.2.5, that caching only covers responses that do not contain "sensitive, dynamic content". OWASP's Top 10:2025 puts broken access control first and says access control is only effective when implemented in trusted server-side code, where an attacker cannot modify the check. A cache that answers before the check runs sits outside that code, on our reading.

In the write-up's lab, the rule that said local requests only was written on one path. The cache key was global. A request that named a different path never met the rule, and the key it produced matched the stored page. That is what we mean by a component that decides which requests share an answer being part of the access control. The framing is ours. The write-up reports the bypass of the rule and does not use these words.

The same shape appeared in an earlier briefing on a WAF rule that blocked one spelling of a path while the application accepted another. A control that decides on a string is only as strong as the agreement between that string and what the next component does with it.

What is cached at all limits the exposure. Cloudflare's documentation says it caches by file extension rather than content type and does not cache HTML or JSON by default, does not cache a response marked private, no-store or no-cache, and respects the origin's cache headers unless an Edge Cache TTL rule overrides them. In Nginx, the source we read marks a response not cacheable when Cache-Control contains no-cache, no-store or private, unless X-Accel-Expires applies, and the documentation says proxy_ignore_headers can switch that processing off. So the headers an application sends on personalised pages, and whether each layer obeys them, matter as much as the key. The write-up does not say what the lab backend sent.

What the vendor documents say about how keys are joined

We read the current pages for five products to see what each says about key composition and delimiters. The table states only what we read, and says "not discussed" where a page is silent.

Vendor documentation read on 5 October 2026. Varnish source read on its GitHub master branch the same day.

1. Product

   Nginx, proxy module (nginx.org)

   Key composition, as documented

   proxy_cache_key sets a string. Default is scheme, proxy host and request URI. The cache file name is an MD5 of the key

   Delimiters, as read

   Not discussed. The page's own example has a space before the cookie variable and none between host and URI

2. Product

   NGINX Plus guide (docs.nginx.com)

   Key composition, as documented

   Same directive. Its example joins host, request URI and a cookie value

   Delimiters, as read

   Not discussed. The example has no separator between the three variables

3. Product

   Cloudflare, Cache Keys

   Key composition, as documented

   Default key: scheme, host, URI with query, Origin header, some method-override and forwarded headers. Custom keys add headers, cookies, host and user

   Delimiters, as read

   Not discussed on the page. It recommends Normalize URLs to origin with custom keys, to prevent cache poisoning

4. Product

   Fastly, vcl_hash and key guide

   Key composition, as documented

   Default: URL and Host, plus a generation value for purging. Listed keys are combined to make a single hash

   Delimiters, as read

   Not discussed. The guide says Vary is generally better than modifying the hash, for example for login state

5. Product

   Akamai, Property Manager

   Key composition, as documented

   Hostname and path are required. Query string, headers, cookies and variables are optional

   Delimiters, as read

   Not discussed. Kettle's 2020 paper showed an internal key with double underscores between parts

6. Product

   Varnish, reference and source

   Key composition, as documented

   hash_data adds an input to the hash. The built-in VCL adds host and URL

   Delimiters, as read

   Reference is silent. The source adds a field separator after each hash_data call, with a comment about making the hash harder to manipulate. Strings joined inside one call are not separated

Product	Key composition, as documented	Delimiters, as read
Nginx, proxy module (nginx.org)	proxy_cache_key sets a string. Default is scheme, proxy host and request URI. The cache file name is an MD5 of the key	Not discussed. The page's own example has a space before the cookie variable and none between host and URI
NGINX Plus guide (docs.nginx.com)	Same directive. Its example joins host, request URI and a cookie value	Not discussed. The example has no separator between the three variables
Cloudflare, Cache Keys	Default key: scheme, host, URI with query, Origin header, some method-override and forwarded headers. Custom keys add headers, cookies, host and user	Not discussed on the page. It recommends Normalize URLs to origin with custom keys, to prevent cache poisoning
Fastly, vcl_hash and key guide	Default: URL and Host, plus a generation value for purging. Listed keys are combined to make a single hash	Not discussed. The guide says Vary is generally better than modifying the hash, for example for login state
Akamai, Property Manager	Hostname and path are required. Query string, headers, cookies and variables are optional	Not discussed. Kettle's 2020 paper showed an internal key with double underscores between parts
Varnish, reference and source	hash_data adds an input to the hash. The built-in VCL adds host and URL	Reference is silent. The source adds a field separator after each hash_data call, with a comment about making the hash harder to manipulate. Strings joined inside one call are not separated

The pattern is plain. The documentation describes what goes into a key. In nothing we read does it say how the pieces are joined. The property that decides whether this bug class applies is the one the manuals leave out, and only the Varnish source states it, for one function. Documentary silence is not a vulnerability. It is a reason to test your own deployment, because you cannot read the answer from the manual. It is also worth noticing that the NGINX Plus guide's own example has the shape the write-up calls ambiguous: adjacent request-controlled values with nothing between them. Whether any given deployment of it is exploitable depends on what else is true, as the write-up's own conditions show.

Ambiguous:  proxy_cache_key "$scheme$host$request_uri$http_accept";
Bounded:    proxy_cache_key "$scheme|$host|$request_uri|$http_accept";

The UK reading: what the guidance covers and what it leaves to you

This matters most to UK organisations that put a CDN or a reverse proxy in front of authenticated or personalised content: banks, councils, retailers, NHS portals. We have no evidence that any of them is affected. They are the ones for whom a wrong sharing decision would mean one person's page reaching another.

NCSC. We searched ncsc.gov.uk with two queries on CDNs, caching and web cache poisoning and read three pages: the denial of service guidance (published 20 January 2019, reviewed 25 March 2024), Building and operating a secure online service (2 March 2022) and the Application development collection. None mentions cache keys or caching of personalised content. The first recommends considering a CDN and warns that the CDN hosts your users' sessions and holds your private keys or a certificate trusted as if it were yours. The second points to the OWASP Top 10. Nothing relevant to cache key construction was found; a page we did not find could exist.

Cyber Essentials. Version 3.3 of the requirements, effective 27 April 2026, says publicly available commercial web applications are in scope by default and that bespoke and custom components of web applications are out of scope. The text does not mention caches, CDNs or reverse proxies. On our reading, a Cyber Essentials certificate therefore tells you nothing about how your cache keys are built.

ICO and UK GDPR. Article 32(1) requires measures appropriate to the risk, including in 32(1)(d) "a process for regularly testing, assessing and evaluating the effectiveness" of them, and Article 32(2) names unauthorised disclosure of or access to personal data among the risks to assess. A cache that serves one person's page to another is that risk. The ICO's guide says the testing can use vulnerability scanning and penetration testing, that its scope should suit what you do and the data you process, and that results should be documented and acted on. It does not mention caches, and the page says the guidance is under review because of the Data (Use and Access) Act. What to do with a real exposure is a matter for your data protection officer and legal advice, not for this briefing.

The practical use of the research for a UK security lead is as a test case for those obligations: a scoped penetration test or bounty item that asks specifically about cached personalised content.

What to do, in the order worth doing. The order and the weights are our judgement, not a standard.

PortSwigger's prevention advice adds a question that costs nothing to ask: if caching is only on "because it was switched on by default when you adopted a CDN", does it reflect what you need?

What we could not verify

The question this leaves

Which of your caches decides that two different requests may share one answer, and who last read the line that builds its key?

Key facts