Hackers Can Manipulate Web Cache Keys to Access Restricted Data and Poison Websites

A web cache poisoning technique called cache key injection could let attackers access restricted data, disrupt websites, or poison cached pages with malicious content.

Alex Brumen’s research shows attackers don’t always need to exploit unkeyed HTTP request values, the usual focus of cache poisoning attacks.

Instead, they can abuse values that are already included in a cache key when a web server combines them without clear separators. Web caches improve performance by storing responses and serving them again when later requests generate the same cache key.

In Nginx, a cache key may be built from parts of an HTTP request, including the protocol scheme, hostname, URI, query string, cookies, or headers.

A common Nginx configuration can resemble: proxy_cache_key "$scheme$host$request_uri$http_accept";.

The problem appears when variable request components are joined together directly. If there are no separators between them, two different requests may create the same final cache key.

Web Cache Keys to Access Data and Poison Sites

For example, a legitimate request for /home with an Accept: / header could produce the same key as an attacker request for /h with Accept: ome*/*.

Although the requested paths are different, Nginx may treat both requests as the same cache object after concatenating the values. This collision allows an attacker to store one response under a key that later matches a different, legitimate request.

One demonstrated impact involves access-controlled endpoints such as /admin. In the proof of concept, Nginx allowed only localhost to access the administrative dashboard. At the same time, its cache used a custom key containing the request URI and Accept header.

An administrator could cache the /admin page from localhost. An external attacker, who could not request /admin directly, could then request a different path such as /ad while placing the remaining min fragment in a controlled header value.

If the manipulated request creates the same cache key as /admin, the server can return the previously cached administrative response without evaluating the original access rule for the protected path. This creates a form of web cache deception that does not require victims to click a crafted link.

The technique can also cause cache-poisoned denial of service, or CPDoS. An attacker could request a non-existent resource such as /h while manipulating a header so that its cache key collides with /home.

Because the attacker’s request returns a cached 404 Not Found response, later visitors requesting the real /home page could receive the poisoned error response until the cache expires or is cleared.

Brumen also demonstrated a more serious scenario involving HTTP and HTTPS scheme confusion. If an Nginx key starts with $scheme$host$request_uri, an attacker may shift the final s in https into a malicious Host header value sent over HTTP.

For example, an HTTP request using the host sdummywebsite. localhost can produce the same key as a normal HTTPS request to dummywebsite. localhost.

If the backend reflects the Host value inside a script source, the poisoned cached page may load JavaScript from an attacker-controlled domain. This can result in stored cross-site scripting.

The research also examined environments using Cloudflare in front of an Nginx origin cache. Attackers may use an Authorization header to make Cloudflare bypass its edge cache while forwarding the request to Nginx.

If Nginx still caches that response, the attacker can target the internal origin cache directly. A later request may then retrieve the poisoned entry from Nginx, especially after the Cloudflare edge entry expires or does not exist.

The main mitigation is to avoid concatenating raw cache-key fragments without boundaries. Hashing an ambiguous key does not fix the issue because two different request combinations can still produce the same underlying string.

Instead of this configuration:proxy_cache_key "$scheme$host$request_uri$http_accept";. Administrators should use clear delimiters or structured encoding: proxy_cache_key "$scheme|$host|$request_uri|$http_accept"; .

Organizations should also avoid caching authenticated or access-controlled responses in shared caches, validate Host headers strictly, redirect HTTP traffic to HTTPS, and ensure cache behavior is consistent across CDN and origin layers.

The findings show that cache keys should not be considered safe merely because request values are included in them. Without clear boundaries, attacker-controlled values can collide with legitimate requests and turn a performance feature into a data-exposure, website-defacement, or denial-of-service risk.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC