Exploiting web cache poisoning vulnerabilities

Web (or HTTP) caching is a highly adopted practice to effectively optimize web page loading times for clients. However, as with most technologies, when incorrectly implemented, it may open up a new exploitable attack surface for us to look into.

In this article, we'll cover what web cache poisoning vulnerabilities are, how they arise, a few effective ways to enumerate such vulnerabilities, and eventually move on to the practical exploitation part.

Let's dive in!

What is web or HTTP caching

Before we can dive into web cache vulnerabilities, we must first have a firm understanding of what web caching is and how it works. HTTP caching is the practice of storing a copy of an HTTP response for a given request. Whenever another client makes the same request, the cached response is returned instead of hitting the origin server again.

Developers rely on caching to reduce server load and improve performance on the origin server. This not only benefits the client with faster load times but also helps a domain rank higher in search results, as page speed is a key factor in SEO.

How web caching works

Different forms of caching

Caching takes several forms within the network layer. Let's have a look at the 3 relevant types.

DNS cache

The Domain Name System is the service that translates a domain name, like example.com, into the server's public IP. Developers are required to contact their DNS registrar any time they want to introduce a new change. However, since most DNS changes are long-term, DNS caching was introduced to further improve overall performance by preventing the DNS resolver from making repeated lookups for every request.

It operates at multiple levels, including the operating system, the ISP's resolver, and dedicated DNS servers. It is crucial to note that DNS caching operates at the network layer and is entirely separate from HTTP caching, so web cache poisoning does not target DNS caches.

Server-side cache

Server-side caches sit between the client and the origin server, intercepting HTTP requests and serving stored responses where possible. This category includes reverse proxies and CDNs (such as Varnish, Nginx, Cloudflare, and Akamai), which cache full HTTP responses, as well as application-level caches (such as Redis and Memcached), which store processed data objects to reduce repeated computation or database queries.

For web cache poisoning, the reverse proxy and CDN layer are what matter most. This is the layer targeted by web cache poisoning attacks, as it sits in the request path of all users hitting the same endpoint.

Browser cache

Lastly, browser caching stores assets locally in the client's web browser, such as scripts, stylesheets, images, and HTML responses. It is controlled through response headers such as Cache-Control and Expires, which instruct the browser on whether and for how long to reuse a cached resource. Unlike server-side caches, browser caches are per-user and local by design.

Diving deeper into server-side caching

When a request arrives at a cache endpoint, the cache must determine whether it has a cached response it can return. To do this, it constructs a cache key, a unique identifier derived from specific components of the incoming HTTP request.

By default, cache keys are typically built from the request's URL path, query string, and Host header. These are known as keyed inputs: if any of them differ between two requests, the cache treats them as distinct entries and won't serve a cached response across them.

However, not every component of an HTTP request is included in the cache key. Headers such as X-Forwarded-For, Accept-Language, or other custom headers may be forwarded to and processed by the origin server, yet completely ignored by the cache when constructing the key. These are referred to as unkeyed inputs.

It is crucial to understand this distinction, as it is the root cause of web cache poisoning. If an unkeyed input influences the server's response, an attacker can manipulate it to inject malicious content, and since the cache key doesn't account for it, the poisoned response gets served to every user whose request matches the same key.

Cache HIT and cache MISS

When a request arrives at the cache, one of two things happens:

• Cache HIT: The cache has a stored response. It returns it directly, without ever reaching the origin server.

• Cache MISS: The cache has no matching stored response. It forwards the request to the origin server, if the configuration allows, it'll cache the response it receives before finally returning it to the client.

Most caching layers expose this through response headers such as X-Cache: HIT or X-Cache: MISS. Targets behind Cloudflare typically use CF-Cache-Status: HIT instead. This becomes important during testing. By observing HIT and MISS responses, you can confirm whether your crafted request has been cached and whether subsequent requests are being served the poisoned response.

Caching response headers

Several HTTP response headers depict how caching layers handle stored responses. Here's an overview of the most relevant ones:

HTTP cache headers

The Vary header is worth paying close attention to. For example, Vary: Accept-Encoding instructs the cache to store separate entries for clients sending gzip compared to those that do not. From a security perspective, Vary can sometimes limit the exploitability of a cache poisoning vulnerability, but it can also hint at which request headers the origin server is actively processing.

What are web cache poisoning vulnerabilities

Web cache poisoning arises when an attacker can control and pollute the cached version of a resource. The polluted cache will then be served to every user whose request matches the same cache key.

Web cache poisoning vs. web cache deception

These two vulnerability classes are commonly confused with each other. However, they are fundamentally different in both their mechanism and their goal.

In web cache poisoning, the attacker manipulates the cache into storing a malicious response, which is then served to other users. The goal is to deliver harmful content to victims.

With web cache deception, the attacker tricks the cache into storing a response containing sensitive, user-specific data, and then retrieves it themselves. The objective is to steal private information that was unintentionally cached.

Understanding HTTP cache poisoning vs cache deception attacks

Throughout this article, we'll focus only on web cache poisoning.

How web cache poisoning vulnerabilities arise

Web cache poisoning vulnerabilities arise from a fundamental gap in the developer's understanding of how caching layers interact with the application. Developers often add support for custom request headers, such as X-Forwarded-Host or X-Original-URL, to handle scenarios like load balancing, URL generation, or infrastructure routing, without accounting for how the cache treats them.

Since these headers are typically unkeyed, the cache ignores them entirely when constructing the cache key. Yet the origin server may process and reflect their values in the response, for instance, dynamically generating a script source URL or an Open Graph tag. From the cache's perspective, two requests are identical if their keyed components match, regardless of what malicious value was passed through an unkeyed header. The poisoned response gets stored, and every subsequent user with a matching cache key receives it.

Unexploitable web cache poisoning vulnerabilities

It is crucial to understand that not every cache-related observation constitutes a valid web cache poisoning vulnerability. There are two common pitfalls to be aware of.

An unkeyed input alone is not a vulnerability. For a finding to be valid, the origin server must actively process the unkeyed input and reflect or act on its value in the response in a meaningful way. Simply identifying that a header is ignored by the cache is not sufficient, you will always need to demonstrate an impact on the polluted, cached response.

Similarly, a poisoned response with no impact on other users is not a vulnerability. If the cache key is scoped to something user-specific, such as a session token or user ID, the poisoned response will never be served to another user. Similarly, if the manipulated value produces no exploitable consequence, the finding lacks the impact required to be considered a valid vulnerability.

Additionally, it is important to note that if the cache is short-lived (think of invalidation after 1 second), the impact may be questionable, as you'd need to poison the cache continuously. It's also worth noting that you need to ensure the cache poisoning vulnerability you're about to report can be reliably demonstrated and reproduced across different devices in different networks.

Identifying web cache poisoning vulnerabilities

Identifying web cache poisoning vulnerabilities involves finding a way to poison the cache with a malicious payload while ensuring it is served to other users. Let's look into each step individually.

1. Identifying cache keys

Your first step will always be to identify cache keys. As we've mentioned before, keyed inputs are taken into account when the cache server tries to match your response with a cached version. Unkeyed inputs are components (such as request parameters or headers) that are not taken into account. Therefore, we'll need to identify unkeyed inputs that trigger malicious behavior. An example could be the X-Forwarded-Host header, which returns a 500 Internal Server Error response when sent with a malicious value.

In practice, you'll likely need to resort to bruteforcing to enumerate potential unkeyed inputs. During initial research, James Kettle, the researcher who originally is behind the concept of Web Cache Vulnerabilities, decided to create Param Miner. A tool that can help us tremendously speed up the process of enumerating keyed inputs for web cache poisoning.

2. Probing for malicious behavior

Once you've identified an unkeyed input, the next step is understanding exactly how the origin server processes it. This is what determines whether the input is exploitable. If, for instance, the value is reflected in the response without proper sanitization (e.g., being used to dynamically generate other data, such as a script URL, a redirect, or a meta tag), you have a potential entry point for poisoning. Similarly, if it fails to handle exceptions and you can reliably induce the server to return an error, it can serve as a potential entry point for cache poisoning that can lead to denial-of-service.

3. Serving the malicious cached response

Once we have successfully identified an unkeyed input that triggers malicious behavior, the next step is to cache the malicious response and serve it to other users. At this stage, you'll need to identify the keyed inputs to understand when a cached response will be served. Once you've identified these, you can start preparing your request to poison the cache.

Exploiting web cache poisoning vulnerabilities

Now that we understand how to identify web cache poisoning vulnerabilities, let's have a look at how we can weaponize them.

Caching malicious responses to exploit logic flaws

Most cache poisoning vulnerabilities are known to escalate to either cross-site scripting (XSS) or denial-of-service (DoS) attacks. However, in some cases, the most impactful exploit outcome is exploiting application logic flaws by manipulating what content the cache serves for a given endpoint. As usual, let's have a look at a practical example.

Consider an e-commerce target that allows its customers to enter a referral program. The concept is simple: refer new customers and help drive more sales with your unique code to earn a percentage of the sale. From an attacker's perspective, the ability to require everyone to use our referral code during checkout would be ideal.

Looking further through the app, we can observe that the checkout application route for guests indeed includes a referral code from an unkeyed query parameter into its response. In this instance, it's embedded within a hidden form field:

Caching malicious responses to exploit logic flaws

By poisoning the cache with our own referral code, we can ensure that every user who loads that page uses our code rather than any other referral code. Before we can do so, we first need to verify several attack conditions:

1. First of all, we'll need to ensure that the target indeed caches the checkout page. We figured the application would cache the checkout page, but only when the customer refrains from signing up and continues with a guest checkout. The keyed input here is most likely the full request path and the HTTP cart.session cookie that carries a JSON object of all cart items, and of course.

2. The next step is to ensure we identify all unkeyed cache keys to verify whether a cache poisoning is exploitable. In our case, we confirmed that the ref query parameter is the unkeyed cache key. Which is ideal, as in practice, the victim won't need to visit our specially crafted link to trigger cache poisoning. As long as he/she proceeds with the guest checkout, our poisoned response will be served, and the checkout session will hold our referral code.

All that remains now is for us to effectively poison the cache:

Poisoning cache entry with our unique referral code

As shown in the figure above, we've successfully poisoned the response. Any user attempting to check out as a guest with a matching cart object will have the attacker's poisoned referral code auto-applied.

Verifying the poisoned cache response

Aside from caching malicious responses to exploit logic flaws, sometimes, they can also open up an attack vector for injection attacks. Let's have a look at a common scenario.

Stored XSS via cache poisoning

With traditional stored XSS, a payload persists because it gets written to a database and later retrieved and rendered for other users. Cache poisoning achieves the same outcome through a somewhat different mechanism. Once an unkeyed input carrying a malicious payload gets cached, every user whose request matches the cache key executes the attacker's script on a completely normal page load. In practice, this allows some forms of self-XSS vulnerabilities to be escalated to exploitable XSS.

Cookie reflection

The most common vector is cookie reflection. Applications frequently reflect cookie values directly in the response, such as locale preferences, currency selections, tracking identifiers, A/B feature flags, and theme selections. Depending on the caching configuration, those cookies often don't form part of the cache key.

Consider an application that stores the user's selected locale in a cookie and reflects it into the response body to render the appropriate language:

Poisoning the cache with a malicious locale cookie value

If the value is reflected without sufficient output encoding, an attacker can craft a request with a malicious cookie value:

A victim's clean request served the poisoned XSS payload from the cache

If the caching layer ignores the locale cookie when constructing the cache key, which is common, as caches typically only key on sensitive authentication cookies, the poisoned response gets stored. Every subsequent user requesting the same endpoint receives the attacker's payload as part of a perfectly normal page load.

Host header injection

A less common but worth mentioning vector is host header injection via the X-Forwarded-Host header. In setups where a reverse proxy sits in front of a multi-tenant SaaS application, where each tenant is served under a different hostname, the origin server may use the forwarded host value to dynamically generate tenant-specific values, such as canonical tags, Open Graph metadata, absolute URLs in API responses, or self-referencing links for things like password resets and email confirmations.

If an attacker can inject a malicious value via the X-Forwarded-Host header and the server reflects it without sufficient output encoding, the poisoned response may be cached and served to other users. It is worth noting that the Host header itself is typically included in the cache key by default, making X-Forwarded-Host the more practical vector in setups where this kind of dynamic generation is in play.

Poisoning the cache via an unkeyed X-Forwarded-Host header reflected into dynamically generated resource URLs

The two examples above are the most common vectors, but they're far from the only ones. Any reflected request component that falls outside the cache key can possibly lead to exploitable behavior, such as User-Agent, Accept-Language, custom headers introduced by the application, or even query parameters that the cache excludes from the key. This is also the reason why a thorough enumeration of unkeyed inputs is non-negotiable.

X-Forwarded-Host: www.example.com.attacker.com

X-Forwarded-Host: non-existent.example.com

Cache poisoning denial of service (CPDoS)

Cache-poisoned denial-of-service, or CPDoS, reverses the attack’s objective. Instead of poisoning the cache with malicious content intended to harm victims, an attacker crafts a request that causes the origin server to return an error response, then caches that error response. Every subsequent user whose request matches the same cache key receives the error instead of the legitimate response, effectively denying access to the endpoint (or even host) until the cache entry expires. As usual, let's have a look at a practical example.

Modern frontend frameworks like React and Next.js compile their applications into chunked JavaScript bundles that are served as static assets, typically from paths like /_next/static/chunks/main-xyz123.js or /static/js/main.xyz123.js. These JavaScript files will most likely be cached by CDNs, often with long TTLs, as they're treated as static assets that change less frequently.

Take the following NextJS-based target into consideration. The origin server is behind a popular CDN, Cloudflare. Suppose the origin server processes the X-HTTP-Method-Override header, but the CDN does not include it in the cache key. An attacker could send the following request:

Triggering a cacheable 405 Method Not Allowed against a Next.js JavaScript chunk via the X-HTTP-Method-Override header

The origin server processes the HTTP request method override, rejects the unsupported method, and returns a 405 Method Not Allowed.

A clean request from a legitimate user receiving the cached 405 instead of the JavaScript bundle, breaking the application

If the caching layer stores that error response against the JS chunk's cache key, every subsequent client will receive the cached error instead of the correct JavaScript file. This effectively breaks the application and denies access until the cached entry expires and is revalidated.

Conclusion

Web caching can be extremely useful, but as with any technology, when deployed incorrectly, it can also create a new attack vector. In this article, we've covered how server-side caching works, what qualifies as a valid web cache poisoning vulnerability, how to identify and confirm these issues in practice, and the various ways they can be effectively weaponized.

So, you've just learned something new about exploiting web cache poisoning vulnerabilities... Right now, it's time to put your skills to the test! You can start by practicing on vulnerable labs and CTFs or... browse through our 70+ public bug bounty programs on Intigriti, and who knows, maybe earn a bounty on your next submission!

START HACKING ON INTIGRITI TODAY