Skip to content

Cache poisoning & deception

Injects a marker into headers commonly reflected but left unkeyed by CDNs (X-Forwarded-Host, X-Forwarded-Scheme, X-Original-URL, X-Rewrite-URL), then sends a follow-up plain request to check whether it receives the poisoned response back — the classic web cache poisoning technique.

FindingSeverityCWE
Unkeyed header injection via <header>criticalCWE-444

Appends a static-file extension or a nonexistent sub-path (/nonexistent.js, .css, /nonexistent.jpg, …) to the resource’s path and checks whether the (potentially authenticated) origin response is served — and looks cacheable — under that URL. This is cache deception via path confusion / static-extension probing.

FindingSeverityCWE
Cache deception via path confusionhighCWE-524

Provokes a 4xx/5xx response (via an out-of-range Range request) and checks whether the error response itself carries cache directives that make it cacheable — a transient error served to other users for longer than intended.

FindingSeverityCWE
Error response is cacheablemediumCWE-524

Response splitting via cache-key manipulation

Section titled “Response splitting via cache-key manipulation”

Injects a CRLF-encoded header/path fragment into an unkeyed input and checks whether it’s reflected as a literal, separate response header — HTTP response splitting exploitable through the cache.

FindingSeverityCWE
Response splitting via unkeyed inputcriticalCWE-113

This check depends on the unkeyed-header-injection check completing first (rather than just on resource discovery) — both manipulate the same unkeyed inputs on the same live resource, and running them concurrently could let one check’s poisoning request land in the middle of the other’s poison/confirm pair and mask its finding.