Web cache poisoning

What makes cache poisoning dangerous: it turns a reflected bug that only harms the attacker into one that harms EVERYONE. A reflected header (like X-Forwarded-Host in the host-header topic) affects only the attacker's own request; but if that response is cached, it serves every subsequent user — so a "self-only" XSS becomes a stored XSS at CDN scale.

Two concepts to grasp, and they are the whole topic:

• The cache key is the set of inputs the cache uses to decide "are these two requests the same". The default is usually just method + path + a few headers. Any input OUTSIDE the cache key that the response depends on is a vulnerability: the attacker changes it, the response changes, but the cache treats the two requests as one.
• Unkeyed input: a header like X-Forwarded-Host, X-Forwarded-Scheme, User-Agent, or a query parameter the cache ignores but the application uses. This is the attack surface.

And one point about location: the fix is almost always in the cache configuration, not the application code — like the request-smuggling topic. It is a bug of disagreement between the cache and the app about "what this request is".

The mechanism is the gap between the cache key (what the cache uses to compare requests) and what the response actually depends on.

sequenceDiagram    autonumber    actor A as Attacker    participant C as Cache (key = method + path)    participant S as Server    A->>C: GET / <br/>X-Forwarded-Host: evil.example    Note over C: The cache key OMITS X-Forwarded-Host → treats it as a normal GET /.    C->>S: forwards it    S-->>C: 200, HTML with <script src=//evil.example/x.js><br/>(the server used X-Forwarded-Host)    Note over C: The cache STORES the malicious response under key "GET /".    actor V as Victim    V->>C: GET / (normal)    C-->>V: the POISONED response from cache    Note over V: The victim gets the attacker's script. XSS at CDN scale.

The key point: the malicious response is STORED under a normal cache key, so a victim sending a completely normal request gets back the poisoned response. This is why it harms everyone, not only the attacker.

A table of forms, by cause:

The last row is worth knowing: cache poisoning is not only XSS — poisoning an error page into the cache is a DoS. One request makes the server return 400, that 400 is cached, and everyone after gets 400 for a normal page.

A homepage cached by a CDN, where the server uses X-Forwarded-Host to build the canonical URL.

# The poisoning request. X-Forwarded-Host is NOT in the cache key, but the server uses it.GET / HTTP/1.1Host: app.exampleX-Forwarded-Host: evil.example

HTTP/1.1 200 OKCache-Control: public, max-age=300 <script src="//evil.example/analytics.js"></script>   ← the server reflected X-Forwarded-Host

The cache stores this under the key GET / (it ignores X-Forwarded-Host). For the next 300 seconds, every user sending a normal GET / gets the page with the attacker's script.

# Detection: send an unkeyed header with a marker and see whether it gets cached.curl -s https://app.example/ -H 'X-Forwarded-Host: canary123.evil' | grep -q canary123 \  && echo "X-Forwarded-Host is reflected"# Then send a NORMAL request and see if the marker is still there → if so, it was cached.curl -s https://app.example/ | grep -q canary123 && echo "CACHE POISONED"

# DoS variant: a malformed header makes the server return 400, and the 400 is cached.GET / HTTP/1.1X-Forwarded-Host: evil\r\n(a malformed header makes the server error)# The 400 is cached under the key GET / → everyone after gets 400 for the homepage.

# After the fix: X-Forwarded-Host is not reflected (use the configured domain, host-header topic),# or it is added to the cache key, and error pages are not cached.

James Kettle's research — "Practical Web Cache Poisoning" (2018) and "Web Cache Entanglement" (2020). Defined the class and showed it existing on many large sites via unkeyed headers like X-Forwarded-Host, X-Forwarded-Scheme. It is the source of the forms table in block 3, and of the canary-marker detection technique in block 4.

Real CDN incidents (many reports). Many bug bounty reports describe the same pattern: a reflected header plus a CDN caching by default, letting one request poison the homepage or a shared JS resource for every user. Memorable because the impact multiplies by the cache's scale: one request, millions of victims.

Cache-poisoning DoS (CPDoS, 2019 research). A family of attacks using malformed headers to make the server return an error and then make the cache store that error — turning the cache into a denial-of-service tool. It illustrates the last row of the block 3 table: cache poisoning is not only XSS, it is any bad response you can force into the cache.

1. The canary technique — the core check, and it is two steps:

B=https://staging.example.comM="canary$RANDOM"# Step 1: send an unkeyed header with a marker, see whether it is reflected into the response.curl -s "$B/" -H "X-Forwarded-Host: $M.evil" | grep -q "$M" \  && echo "reflected — dangerous if cached" || { echo "not reflected, ok"; exit 0; }# Step 2: send a NORMAL request (no header) and see if the marker is still there.sleep 1curl -s "$B/" | grep -q "$M" && { echo "CACHE POISONED"; exit 1; }exit 0

2. Try many unkeyed headers — the block 3 table is a starting list:

for h in X-Forwarded-Host X-Forwarded-Scheme X-Host X-Forwarded-Server X-Original-URL; do  M="c$RANDOM"  curl -s "$B/" -H "$h: $M" > /dev/null  curl -s "$B/" | grep -q "$M" && echo "POISONED via $h"done

3. Grep for the app reflecting a header into the response — the same check as the host-header topic:

grep -rnE 'X-Forwarded-Host|X-Forwarded-Scheme|Request\.Host' --include='*.cs' src/ \  | grep -viE 'ForwardedHeaders|HostFiltering' \  && echo "WARNING: possibly reflecting a header into the response"

4. Check error responses are NOT cached (CPDoS):

# Force a 400 and check it has no public Cache-Control.curl -sI "$B/" -H 'X-Forwarded-Host: a\r\nb' | grep -iE 'cache-control|^HTTP'# 4xx/5xx must be no-store/private, not public.

5. Check the cache-key configuration at the CDN — this is where the real fix lives. Confirm every header the app uses to build the response is in the CDN cache key, or the app does not use them. This is a config check, not a code test.

The model mistake, and it is the central one: thinking the default cache key (method + path) is enough. Cache poisoning is a DISAGREEMENT between "what the cache thinks this request is" and "what the app builds the response from". Every input the app uses but the cache ignores is a vulnerability.

The location mistake: looking for the fix in application code. Like the request-smuggling topic, the fix almost always lives in the cache/CDN configuration — what the cache key includes, what is cached, the TTL. Code is only involved in whether it reflects input at all (layer 1).