What is Web Cache Poisoning?

Web Cache Poisoning is a security attack where an attacker tricks a web server and its caching system into storing a malicious HTTP response. Instead of generating a fresh response for every user, the cache serves the stored (poisoned) response to everyone who requests the same resource. As a result, many users can unknowingly receive malicious content.

The attack typically happens in two stages:

1. Create a malicious response: The attacker figures out a way to make the web server generate a response that contains malicious content, such as a harmful script or manipulated data.
2. Store it in the cache: Next, the attacker ensures that this malicious response is saved by the caching system. Once cached, every user requesting that page receives the poisoned response until the cache expires or is cleared.

How Does Web Cache Poisoning works?

Let's understand how web cache poisoning works with the example of restaurant.

Imagine a popular restaurant that prepares dishes in advance to serve customers quickly. To avoid cooking the same meal repeatedly, the restaurant stores prepared dishes in a pantry.

Whenever a customer places an order, the staff first checks the pantry. If the requested dish is already available, they serve it immediately. Otherwise, the chef prepares a fresh dish, stores it in the pantry, and serves it.

But here's the important part.

The restaurant organizes its pantry using labels such as the dish name and size (for example, Veg Burger — Large). These labels help the staff decide whether they already have the requested dish. In web caching, these labels are called the cache key.

Now imagine that the chef also reads a special note attached to the order, such as:

"Add extra chili sauce."

However, the pantry staff doesn't include this note when creating the label. They still label the dish simply as Veg Burger — Large.

This special note is similar to an unkeyed input in a web application — it affects how the dish is prepared, but it is not included in the cache key.

Now let's see how an attacker exploits this.

1. The attacker sends a specially crafted request. Instead of making a normal request, the attacker includes an unkeyed input (such as an HTTP header, query parameter, or cookie) that changes how the server generates the response.
2. The server creates a modified response. Since the application trusts this input, the response now contains attacker-controlled content — for example, a malicious JavaScript file or a manipulated URL.
3. The cache stores the response. The caching system generates the cache key using only the values it considers important, such as the URL. Because the attacker's input is unkeyed, it isn't part of the cache key. As a result, the malicious response is stored under the same cache entry that normal users will request.
4. Other users receive the poisoned response. When another visitor requests the same page, the cache sees that the cache key matches and serves the stored response directly, without contacting the server. Since the cached response is already poisoned, every user receives the malicious version until the cache expires or is cleared.

What is the impact of Web Cache Poisoning Vulnerability?

Not every Web Cache Poisoning vulnerability has the same level of impact. The severity of the attack mainly depends on two factors:

1. what the attacker is able to store in the cache.

If the attacker can only cache harmless content, the impact may be minimal. However, if they can cache malicious JavaScript, modify HTML, inject redirects, or alter important page elements, the consequences can be much more severe.

2. how many users request the poisoned page.

Since the malicious response is stored in a shared cache, every user requesting that page receives the poisoned content until the cache expires or is cleared. If the poisoned page is an admin dashboard that only a few employees visit each day, the attack affects only a small number of users. If the poisoned page is the website's homepage, login page, or a popular JavaScript file that thousands of users access every hour, the impact can be massive. The more frequently a cached resource is requested, the more victims the attacker can reach with a single poisoned cache entry.

How to exploit Web Cache Poisoning Vulnerability?

When assessing an application for Web Cache Poisoning, the objective is to determine whether the application's response can be manipulated and subsequently stored in the cache. This assessment can be broken down into three phases.

Identify Unkeyed Inputs:

An unkeyed input is any part of an HTTP request that influences the application's response but is not included in the cache key. During a security assessment, modify different parts of the HTTP request such as HTTP headers, query parameters, cookies, or other request attributes and observe whether the server's response changes.

If modifying an input changes the response while the cache still treats both requests as the same resource, that input is considered unkeyed and may indicate a potential Web Cache Poisoning vector.

Determine Whether a Harmful Response Can Be Generated:

Finding an unkeyed input alone does not confirm a vulnerability. The next step is to evaluate how much control that input provides over the server's response. During testing, analyze whether the application reflects or uses the unkeyed input in meaningful ways. For example, determine whether it is used to construct URLs, generate HTML content, reference JavaScript files, or build redirects. The objective is to understand whether the application's behavior could lead to a response that, if cached, would negatively impact other users. In other words, this phase focuses on evaluating the security impact of the unkeyed input rather than simply confirming its existence.

Verify That the Response Is Cached:

The final step is to verify whether the manipulated response is actually stored by the caching layer. If the application caches the modified response using the same cache key as a normal request, subsequent requests for that resource may receive the cached version instead of a newly generated response. This confirms that the caching layer does not distinguish between requests that produce different responses, creating the conditions required for Web Cache Poisoning. During a penetration test, this verification should always be performed in a controlled and authorized environment to avoid affecting legitimate users.