Cache poisoning incidents: when one user becomes everyone

One invariant, four caches

In ten minutes you will know exactly how to spot a poisoned cache key before it ships — and what to do the moment a ticket says “I see someone else’s data.” A cache is a map from key to response. The correctness invariant is one sentence: everything the response depends on must be part of the key — otherwise two requests that deserve different responses collide in one slot, and whoever renders first becomes everyone’s response. That is the entire failure class. “Poisoning” sounds adversarial, but most production incidents are self-inflicted: the attacker is your own code reading something the key does not know about.

Next.js gives you four caches with four different keys, and the invariant must hold in each. The Full Route Cache keys on the route path: a static route renders once and the HTML plus RSC payload serve everyone. The Data Cache keys each fetch on URL and options. unstable_cache keys on keyParts plus the serialized arguments of the wrapped function — and this is the trap from the Hook: values captured in a closure are invisible to the key. The CDN keys on URL plus whatever Vary names. Four layers, four chances to omit something.

// THE BUG: userId lives in the closure — the key is constant
const getSummary = unstable_cache(
  async () => db.account.summary(session.userId), // closure capture
  ['account-summary'],
  { revalidate: 600 },
);

// THE FIX: arguments are serialized into the key
const getSummary = unstable_cache(
  async (userId: string) => db.account.summary(userId),
  ['account-summary'],
  { revalidate: 600 },
);
await getSummary(session.userId); // per-user slot — or better: do not cache this at all

Next.js has a tripwire for the route-level version of this: calling cookies() or headers() during render opts the whole route out of the Full Route Cache — personalized routes go dynamic automatically. The leak happens when personalization enters around the tripwire. A server component fetches the user via a cached data-layer call (the closure bug above, or a fetch authorized by a module-level token) and passes user.name and cart.items as props into a client component. No cookies() call ever ran, so the route stayed static — and those props are serialized into the RSC payload, which is the Full Route Cache entry. User A’s cart ships inside the cached payload to user B. The client component is innocent; the poison was baked one layer below, where the tripwire cannot see it.

Set-Cookie at the CDN, Vary discipline, draft tokens

The second Next.js-specific shape needs no application bug at all — only an ops change. A response that carries Set-Cookie is a session being handed to one person; a shared cache that stores it hands that session to everyone who hits the entry. CDNs refuse to cache Set-Cookie responses by default, which is why this incident almost always starts with a human overriding defaults: a “cache everything, ignore origin headers” page rule added at 13:40 during a traffic emergency, and at 14:02 the first “I am logged in as someone else” ticket. That is full session bleed — the victim does not see your data, they become you. The guard is mechanical: an edge rule that never caches a response carrying Set-Cookie, regardless of what other rules say, plus Cache-Control: private, no-store on everything personalized so the origin states its intent.

Third shape: Vary discipline. If the app negotiates anything by request header — locale from Accept-Language, an A/B bucket from a header set by an upstream router — then the header is part of what the response depends on, so it must be part of the CDN key via Vary: Accept-Language. Omit it and the first-cached variant serves all: German homepage for everyone, or worse, treatment-group pricing cached for the control group. The honest tradeoff: Vary multiplies cache cardinality, and Vary: Cookie effectively disables caching. When cardinality matters, move the variant into the URL (/de/…) where the key sees it natively.

Fourth: draft mode. draftMode() exists precisely to bypass caches so editors see unpublished content — the bypass cookie is the point. The leak shape is a preview URL with the bypass token shared into a channel where a caching proxy or a prefetcher sits, or a custom preview route that forgets no-store on its responses: unpublished content cached under a public URL. Treat preview tokens like credentials, because that is what they are.

The classics still work, and how to run the postmortem

When you review a PR that adds a new CDN rule or tweaks response headers, ask one question before approving: “does this let an unkeyed input reach a shared response?” The pre-framework cache-poisoning literature applies to Next.js apps unchanged, because the CDN in front speaks plain HTTP. The canonical probe is the unkeyed header: find a header that influences the response but not the cache key. X-Forwarded-Host is the classic — frameworks and SEO helpers use it to build absolute URLs for canonical links, og:image, and password-reset emails. An attacker sends one request with X-Forwarded-Host: evil.example, the response is cached under the normal URL, and every user for the next TTL receives HTML whose absolute links point at the attacker’s host. The PortSwigger playbook is to probe with a cache-buster query param, confirm reflection, then drop the buster; your security tests should run exactly that probe against your own stack.

When the incident lands, the postmortem walk is always the same four stations. Detection: “I see someone else’s cart” tickets are a P1 security incident, not a UI bug — route them to the on-call, and add the synthetic check you wish you had: two sessions request the same URL every minute and assert the responses do not bleed. Blast radius: everyone who hit the poisoned entry until purge or TTL expiry — multiply by the number of poisoned keys, and remember each expiry re-poisons with a fresh victim. Mitigation: purge every layer — CDN purge, revalidatePath/revalidateTag for the route and data caches, and a restart if anything was cached in process memory — then ship the key fix, because a purge without the fix buys you one TTL of calm. Prevention is a checklist, not vigilance: every cached response reviewed against “what does this read, and is all of it in the key”; no-store on personalized fetches; Set-Cookie never cacheable; a Vary audit on every header the app negotiates by; the two-session bleed probe and the unkeyed-header probe wired into CI.