Web Cache Poisoning & Deception
Get a malicious response cached and served to other users, or trick the cache into storing sensitive pages.
Every step requires authorization. Review side effects before running commands against a live system.
Find unkeyed inputs
Identify headers/params that affect the response but aren't part of the cache key (X-Forwarded-Host, X-Forwarded-Scheme, custom headers). Use Param Miner to discover them.
Prove reflection into cache
Inject a marker via an unkeyed input, then request the page fresh (no injection) and confirm the marker persists via cache HIT headers (Age, X-Cache: hit).
curl -s -H 'X-Forwarded-Host: evil.com' 'https://target.com/?cb=1' -IEscalate the payload
Turn reflected unkeyed input into stored XSS, open redirect, or resource hijack (poisoned JS/CSS URL). Choose a cache-buster you can re-poison at will.
Cache deception
Append a static-looking suffix (/account/profile.css) so the cache stores an authenticated page, then read another user's cached data.
curl -s 'https://target.com/account/settings/nonexistent.css' -ICommon guidance
- Read the Cache-Control, Age, and X-Cache headers religiously - they tell you keying behavior.
- Poison a unique cache-buster URL so you never affect real traffic while testing.
Mapped workflow tools
References
Version history: normalized permanent page created 2026-08-20.