Vulnerability Research

Web Cache Poisoning Research

Caching layers in modern CDNs are designed to be fast, not safe. When the origin reflects attacker-controlled headers into a cacheable response — and those headers are not part of the cache key — a single request can poison the cache for every subsequent visitor. This research documents the vector and the practical mitigations that make it disappear.

Cache Poisoning CDN HTTP Headers Research Published 18 Apr 2025

Overview

Web cache poisoning targets the gap between the cache key (what the cache uses to look up a stored response) and the request inputs that actually shape the response. If a header influences the response but is not in the cache key, an attacker can mint a poisoned variant once and have it served to everyone.

Common Vectors

  • Unkeyed reflected headers: headers like X-Forwarded-Host, X-Original-URL, or custom CDN headers that get reflected into the body or redirect targets.
  • Fat GET requests: caches that ignore non-standard query parameters but the origin uses them.
  • Method override headers: e.g. X-HTTP-Method-Override changing response semantics.
  • Cache deception: appending a static-looking suffix (/account.css) that the cache stores as static while the origin still serves dynamic personalised content.

Representative PoC Pattern

GET / HTTP/1.1
Host: example.test
X-Forwarded-Host: attacker.tld
Cache-Control: no-cache

If the origin reflects X-Forwarded-Host into a canonical link or absolute redirect — and the cache stores by host + path only — the next visitor receives the attacker-poisoned variant until cache TTL expires.

Mitigation

  1. Strip request headers that should not influence responses at the CDN edge.
  2. Add unkeyed-but-influential headers to the cache key (or refuse to cache when they appear).
  3. Never reflect untrusted input into cacheable responses — including absolute URLs, canonical tags, and redirect targets.
  4. Set conservative Cache-Control on personalised or authenticated responses; explicit private or no-store where appropriate.
  5. Continuously monitor cache hit/miss anomalies — sudden ratio shifts often correlate with a probing attacker.
Defender takeaway: Cache poisoning is a configuration problem more than a code problem. Audit the cache key — that's where the fix lives.
← Back to Writeups Read: Stored XSS in Admin Dashboard