Web cache poisoning: how it works, how testers prove it, how to fix it

Web cache poisoning is an attack in which someone abuses the behavior of a web server and its cache so that a harmful HTTP response is served to other users. PortSwigger describes two phases: get the back end to return a response that carries a payload, then make sure the cache stores it. It is not DNS cache poisoning, which attacks resolvers and has different defenses.

Only test systems you own or have written authorization to test. Every example here uses a fictional app on example.com.

What is web cache poisoning?#

A shared cache (a CDN, a reverse proxy or an application cache) saves a response and sends the saved copy to later visitors. To decide whether two requests are the same, the cache compares a small set of request parts called the cache key. PortSwigger says this is usually the request line and the Host header. Everything else is "unkeyed".

The bug appears when an unkeyed part changes the response. The attacker sends one request with a bad value in that part. The server builds a response that contains it, the cache stores the response under the normal key, and the next visitor to that URL gets the poisoned copy. The attacker does not need to reach the victim.

Caching also turns small bugs into serious ones. Kettle's 2018 research notes that header-based XSS is normally harmless, because a victim's browser never sends the attacker's header. A cache removes that barrier.

How the attack works: two requests and a cache buster#

The attacker finds an unkeyed input that the application reflects, then sends a request that gets the reflected response cached. A tester repeats the same two steps with a harmless value and a cache buster, so no real visitor can receive the response.

GET /?cb=7f3a91 HTTP/1.1
Host: notes.example.com
X-Forwarded-Host: canary.example.net

HTTP/1.1 200 OK
Cache-Control: public, max-age=300
X-Cache: MISS
<meta property="og:image" content="https://canary.example.net/preview.png">

GET /?cb=7f3a91 HTTP/1.1
Host: notes.example.com

HTTP/1.1 200 OK
Age: 12
X-Cache: HIT
<meta property="og:image" content="https://canary.example.net/preview.png">

In a real attack the reflected value would sit in a script import or a redirect. The tester stops at the harmless canary. The response header values that help here are Age, Cache-Control and any vendor hit or miss header, because they show how long the entry lives and whether the second request came from the cache.

The main variants#

The table groups the cases testers meet most. Each row names the unkeyed input and what the attacker gets.

Kettle's 2018 post reports that the Vary header can let an attacker target one browser type, because the cache then keys on that header. MDN explains Vary as the way to make a cache store separate responses per listed header.

Web cache poisoning vs web cache deception#

Poisoning and deception both abuse a cache, and they work in opposite directions. PortSwigger puts it this way: poisoning manipulates the cache key to inject malicious content into a cached response, and deception exploits cache rules to trick the cache into storing private content.

In the deception example, the origin maps /user/123/profile/wcd.css to the profile endpoint and ignores the file name, while the cache sees a CSS file and stores it. The tests in this page for cache behavior also apply to deception, with the roles reversed.

Real incidents and CVEs#

Poisoning has been found in popular frameworks and in large sites. Each entry is from a primary source checked on 9 November 2026.

Two of these are framework features that trusted headers or built caching headers on their own. A site owner who never wrote a bad line could still be exposed.

How penetration testers detect and prove it#

The method follows PortSwigger's attack steps: find unkeyed inputs, make the server reflect or use one, then check that the cache stores the result. We add controls and a read-back, as in our other tests.

1. Map the cache. Send a request twice and compare Age, Cache-Control and any hit or miss header. Record which paths are cached and for how long.
2. Add a unique cache buster to every test URL, as PortSwigger recommends, so test responses cannot reach real visitors. Change it for each new test.
3. Look for unkeyed inputs. Add random values to headers and compare responses. The Param Miner extension's "Guess headers" feature automates this and can add a buster automatically.
4. Use a canary value you own, not a script. A host such as canary.example.net on a domain the authorization covers is enough to show reflection.
5. Run the two-request test. Send the header once, then request the same buster URL from a second client that sends no header. If the canary appears, the cache stored it.
6. Run controls. Send the second request with a different buster and confirm it is clean. Send the header to an uncached path and confirm no stored copy. Test one header at a time.
7. Show the impact in a real browser where it matters. Load the poisoned buster URL in Chromium and record what the page does with the canary.

The finding records the buster, both requests with timestamps, the cache headers, and the browser observation. A reflected header alone is a lead. A stored copy served to a second client is the finding. Evidence is labeled "Observed" for the requests and "Browser-observed" for the page behavior. If the cache stored the copy only for the same client, that is a limit, and the report says so.

Safety limits come first. Do not poison a URL without a buster, do not use a live payload, and do not test shared caches in production unless the scope says so. If the cache has no purge option, ask the owner how a stored entry will be removed before you test.

How to prevent web cache poisoning#

Four rules cover most cases. They match PortSwigger's guidance.

1. Cache only static responses, and check what counts as static. Mark dynamic and personalized responses Cache-Control: no-store, private.
2. Remove or ignore request headers the application does not need. If the site works without X-Forwarded-Host, drop it at the edge.
3. If an input must change the response, add it to the cache key, or use Vary for a header. Do not drop parts of the key for speed. Rewrite the request instead.
4. Reject fat GET requests, and fix reflected values even when they look unexploitable. Cache behavior can make them exploitable.

nginx. The default key is close to $scheme$proxy_host$uri$is_args$args, which does not include request headers. If a header changes the response, put it in the key, and skip the cache for requests that carry credentials.

proxy_cache_key "$scheme$host$request_uri";
proxy_no_cache $http_authorization $cookie_session;
proxy_cache_bypass $http_authorization $cookie_session;
# Remove a header the app does not need
proxy_set_header X-Forwarded-Host "";

proxy_no_cache stops a response from being written to the cache, and proxy_cache_bypass stops one from being read. Use both.

Cloudflare. The documented default cache key includes the scheme, host and URI with query string, plus the Origin header and several forwarding headers, among them x-forwarded-host, x-host, x-original-url and x-rewrite-url. Custom cache keys that add headers, cookies or the host are Enterprise features. Cloudflare also lists Cache Deception Armor as available on all plans.

CloudFront. A cache policy sets the headers, cookies and query strings in the cache key. AWS notes that fewer values in the key raise the hit rate, so add only what changes the response, then check that the origin does not read anything else.

Node.js (Express). Set cache headers on dynamic routes, and do not build absolute URLs from a client header.

app.use((req, res, next) => {
  res.set("Cache-Control", "no-store, private"); // default for dynamic routes
  next();
});
const SITE = "https://notes.example.com"; // fixed, not from X-Forwarded-Host
res.send(`<meta property="og:image" content="${SITE}/preview.png">`);

Java (Spring). Spring's CacheControl builder sets the header for a response.

return ResponseEntity.ok()
    .cacheControl(CacheControl.noStore())
    .body(page);

Python (Flask). Set the header in an after-request hook for dynamic routes, and read the site URL from configuration.

@app.after_request
def no_store(resp):
    if request.endpoint not in STATIC_ENDPOINTS:
        resp.headers["Cache-Control"] = "no-store, private"
    return resp

Upgrade frameworks that had cache fixes. For the Next.js CVEs above, NVD lists fixed releases and says there is no official workaround for CVE-2024-46982. Doyhenard's defense for key confusion is to avoid normalizing the cache key and to avoid forwarding a delimiter suffix to the origin.

Testing checklist#

• Is each cache identified (CDN, proxy, framework), with its cache key documented?
• Do all test requests carry a unique buster?
• Were X-Forwarded-Host, X-Forwarded-Scheme, X-Original-URL and method override headers tested one at a time?
• Did a second client confirm that a stored copy was served?
• Did controls with a new buster stay clean?
• Were error responses (400, 404, 204, 5xx) checked for caching, to find CPDoS?
• Were path delimiter and encoding differences between cache and origin checked?
• Do dynamic and personalized pages send no-store, private?
• Are poisoned entries removed after testing, and is that recorded?

When to get a professional test#

Cache poisoning depends on how your CDN, proxy and application work together, so a scanner that only reads the application misses it. A tester needs written scope that names each cache layer and says who can purge entries. Excession Labs runs authorized tests of this kind as part of a web application penetration test, with the evidence standard described above. The related host header injection page covers the shared mechanism, and the HTTP request smuggling page covers a neighbor that also attacks the path between cache and origin.