July 20, 2026
Using Cache Deception Techniques to Discover Cache Poisoning Vectors
When identifying cache poisoning issues in live web applications, there are two main steps:

By HCN
2 min read
- Identify a cache-busting technique.
- Determine a exploitation method.
If a cache-busting technique is found, it becomes straightforward to verify whether the issue is exploitable. This article discusses less common cache-busting techniques, although they are well known in the context of cache deception attacks.
Deception vs Poisoning
For shared caches:
- If a single URL can produce multiple responses, it may be vulnerable to cache poisoning. Example: The same URL is requested twice, but one request includes a header that triggers an error page. This can lead to CPDoS. There is only one URL (no variations), but multiple possible responses.
- If multiple URLs return the same response, it may be vulnerable to cache deception. Example: An admin page is accessible via multiple URL variations such as /admin and /%61dmin. An attacker can trick a victim into visiting /%61dmin, causing the response to be cached.
To identify cache deception issues, it is necessary to find multiple URLs that map to the same page. This is similar to identifying cache-busting techniques for cache poisoning, where the goal is to discover different URLs for the same endpoint in order to test unique request variations.
Deception technique for busting
Consider a website with a parser differential where the application decodes the URL before routing it to the endpoint, while the cache proxy does not normalize it and instead treats it as-is.
URL: /%41bout
Cache proxy: /%41bout
Backend: /about
This behavior can be used for cache deception attacks if the endpoint returns sensitive information. It can also be leveraged for cache busting.
The word "about" contains 5 characters: a, b, o, u, t. Each character has two possible representations in a URL:
- Literal form (e.g., a)
- Percent-encoded form (e.g., %61 or %41)
Since each of the 5 positions has 2 independent possibilities, the total number of combinations is:
2⁵ = 32
This produces 32 variations of the word "about." Excluding the original literal form, there are 31 alternative URLs that can be used to test a single endpoint.
More chances
This technique limits testing to 31 variations for a specific path in this scenario. Therefore, instead of relying on arbitrary headers, it is more effective to focus on the most likely headers or other exploitable primitives. Identifying additional parser differentials further expands the variation space by increasing the number of possible combinations.
Additionally, the same root cause may exist across multiple endpoints, which allows us to increase the available testing space. We can test the 31 URL variations with different headers against one endpoint. After completing the tests for one endpoint, we can move to another endpoint and test the same set of URL variations with additional header combinations. This increases the overall testing space and the chance of identifying a cache poisoning condition.
In some cache deception cases, such as /contact versus /contact.html, the opportunity may be limited to a single variation. In these scenarios, a low cache duration can be used as an advantage, although it introduces constraints. For instance, if the cache duration is 10 seconds, it is possible to test /contact.php within that time window. After the cache expires, the server processes a new request, and since the primary URL is /contact, testing /contact.php does not impact real users.
Low cache durations are uncommon. As cache duration increases, testing time also increases. Even when a low cache duration is present, the impact of attacks like denial-of-service is limited because the effect only lasts for a short period. Despite this limitation, such conditions can still be useful for exploiting issues like XSS.