Web Cache Poisoning: Hidden Inputs and Param Miner

Last updated: April 26, 2026

Web cache poisoning makes CDN / reverse proxy serve attacker-controlled content to other users. Once cached, the malicious response is served until cache expires — affecting many users from a single poisoning event. This article covers the techniques and the cache-key configuration that prevents the bug class.

The mechanism

CDN / reverse proxy caches responses keyed by URL + Vary headers. If the request includes unkeyed inputs that influence the response (e.g., custom header that the back-end uses), attacker can manipulate that input to produce malicious response, get it cached, and have it served to victims requesting the same URL.

The classic example

# Vulnerable backend: reflects X-Forwarded-Host into a redirect
GET / HTTP/1.1
Host: target.com
X-Forwarded-Host: attacker.com

# Backend response:
HTTP/1.1 302 Found
Location: https://attacker.com/login

# CDN caches keyed on URL only (not X-Forwarded-Host)
# Subsequent users requesting / get cached redirect to attacker.com

Common unkeyed inputs

• Custom headers used by back-end (X-Forwarded-*, X-Original-Host, X-Real-IP)
• Cookies — sometimes back-end uses cookies but cache doesn’t include in key
• Query parameters — if cache only keys on path
• Request method — if cache merges GET and HEAD

Practical testing — Param Miner

# Burp extension Param Miner discovers hidden / unkeyed inputs
# Right-click request → Param Miner → "Guess headers"
# Burp sends thousands of common header names with canary value
# Reports headers whose values appear in response

# Once unkeyed input identified, test cache poisoning:
GET /resource HTTP/1.1
Host: target.com
X-Forwarded-Host: attacker.com  ← unkeyed
[Cache-Buster: random123]

# Request again without buster — observe if cached version returns attacker.com

Variants

1. Header-based poisoning

Most common. X-Forwarded-Host, X-Original-URL, X-Rewrite-URL.

2. Cookie-based poisoning

Cookie value influences response but not cache key. Less common because cookies are typically per-user.

3. Cache key normalisation gaps

URL /api/data vs /api/data/ vs /api/data?foo= sometimes cache as same key but back-end treats differently.

4. Cache-poisoning via DoS

Smuggle a malformed request that causes back-end error response; CDN caches the error; legitimate requests get cached error page.

The fix

• Cache keys include all inputs that affect response — Vary headers configured exhaustively
• Don’t trust X-Forwarded-* from arbitrary sources; validate via known proxy IP allow-list
• Normalize URL before caching
• Don’t cache error responses (or short TTL)
• Cache only static / public resources; never cache authenticated responses

Detection

• CDN logs for anomalous header values appearing in cache-keyed responses
• Alerts on cache-hit-rate spikes that don’t correlate with traffic
• Monitoring for unusual response anomalies served to multiple users

The takeaway

Web cache poisoning is the Burp Param Miner test that reveals hidden inputs influencing responses. CDN configuration with comprehensive Vary headers + back-end input validation closes the bug class. The risk scales with cache size — one poisoning event affects every cache-keyed user until expiry.