Web Cache Poisoning Lab: Serve Your Payload to Everyone

This article explains web cache poisoning through a practical lab exercise where attackers exploit the gap between what a cache uses as its key and what influences the actual response. CacheServ demonstrates how an unkeyed input—specifically the X-Forwarded-Host header—can be reflected into HTML without being part of the cache key, allowing a single poisoned request to be stored and served to all subsequent visitors requesting the same URL. This vulnerability matters because it converts a reflected quirk into a persistent, mass attack affecting every user who shares the cached key.

• Cache key mismatch enables broad poisoningCacheServ caches pages by URL only but reflects the X-Forwarded-Host header into the HTML response. Because this header is not included in the cache key, an attacker can send one request with a malicious header value, which gets cached under the normal URL key. All subsequent visitors requesting that URL receive the poisoned cached content, even though they never sent the malicious header themselves.
• Unkeyed inputs create the exploit windowAn unkeyed input is any request element—typically a header like X-Forwarded-Host—that changes the response but is excluded from the cache key. The article identifies this mismatch as 'the whole bug': attackers exploit it by confirming a header is reflected but unkeyed, sending a poisoned request that gets cached, then verifying a clean request serves the poisoned content to simulate victim exposure.
• Attack requires three discrete stepsThe attack proceeds by confirming X-Forwarded-Host is reflected but unkeyed, sending a request to the target URL with a malicious header value to poison the cache, and finally making a clean request without the header to confirm the cached poisoned response is served. This third step is crucial because it simulates what a victim would receive and demonstrates the attack's scope.
• Defense requires input inclusion or exclusionThe article presents two defensive strategies: either include every input that influences the response in the cache key, or strip those inputs before caching occurs. Additionally, it recommends not reflecting request headers into responses unless absolutely necessary and never doing so without validation; headers should be allowlisted and normalized at the edge to prevent unexpected ones from reaching the application.
• Real-world discovery and classificationJames Kettle's 2018 research 'Practical Web Cache Poisoning' demonstrated unkeyed-header attacks against major sites and frameworks, making this technique widely known. The vulnerability maps to OWASP A05 (Security Misconfiguration) in the 2021 Top 10, establishing its classification as a serious misconfiguration rather than an isolated quirk.
• Cache scope and response composition matterThe article advises scoping cache entries carefully and keeping cacheable responses free of request-specific data. This principle acknowledges that even properly keyed caches can be vulnerable if responses retain user-specific or request-specific content that should not be shared across different clients.
• Practical testing approach for researchersTo hunt cache poisoning on authorized targets, the article recommends adding headers like X-Forwarded-Host and observing whether they are reflected in responses. If they are reflected and not part of the cache key, a single request can affect multiple users, indicating a vulnerability worth deeper investigation and testing.

Bottom line: Web cache poisoning succeeds when a request header or input changes the cached response but is excluded from the cache key; defending against it requires either including all response-affecting inputs in the cache key or stripping them before caching, combined with validation and careful scope management. Attackers should test for reflected unkeyed headers during authorized assessments, and defenders must ensure every element that influences a response is either keyed or never reflected unvalida