Web cache poisoning
If a header or query changes the response but is not in the cache key, you poison everyone who shares that key. Two clients. One poisons. The other must receive it.
Skill: Cache deception and cache poisoning
Ask: Is a private response stored at a URL the cache treats as static, or does an unkeyed input change what other users receive?
Stop: You can say which of the two bugs you observed. Do not file one as the other.
Practice the class in the browser: PortSwigger Web Security Academy. The lab is theirs. This page is the stop condition and the disclosures.
Checklists
- Cache - Two clients. One poisons. The other must receive it.
Disclosures
- A smuggled request was stored as a cached response - HTTP request smuggling
Playbooks
- Web Cache Poisoning - An unkeyed input changes the response other users receive. That is poisoning. A private response stored at a URL the cache treats as static is deception, and it belongs on the cache-deception playbook. Report them separately.
Tools
- Burp Suite - The industry-standard intercepting proxy for manual web testing. Community edition is free; Pro adds the active scanner and automation.
Questions
How do I prove it?
Poison with a unique marker, then fetch as a second user-agent or IP and show CF-Cache-Status / Age / X-Cache HIT with your marker.
Can I leave it poisoned?
No. Use a harmless marker and purge or wait. Production poison of real users is how you get banned.
This page is the linked pack hunt_brief("cache") returns on the MCP connector. Authorized testing only.