New Cache Key Injection Attack Lets Hackers Bypass Access Controls and Poison Nginx Caches

Security researchers have unveiled a cache poisoning technique called cache key injection that lets attackers bypass access controls, expose cached sensitive pages, trigger denial-of-service conditions, and potentially execute stored cross-site scripting (XSS) attacks against vulnerable Nginx deployments.

Research by YesWeHack researcher Alex Brumen highlights flaws that occur when web caches create cache keys by directly concatenating multiple variable request values without separators.

Unlike traditional web cache poisoning, which typically exploits unkeyed HTTP headers or parameters, cache key injection specifically targets values that are already included in the cache key.

New Cache Key Injection Attack

Nginx often builds cache keys from parameters such as the scheme, host, URI, query string, cookies, and request headers. A configuration like `proxy_cache_key “$scheme$host$request_uri$http_accept”;` may seem secure because each component has a key.

However, without clear boundaries between these values, two distinct requests can produce the same final cache key.

For instance, a legitimate request to `/home` with an `Accept: */*` header could generate an identical cache key to an attacker-controlled request to `/h` using `Accept: ome*/*`. If Nginx caches the attacker’s response first, subsequent requests for `/home` may receive the poisoned response.

This technique can have serious implications when combined with access control policies. In one proof-of-concept scenario, an Nginx server restricted access to `/admin` so that only localhost could access the endpoint. An attacker could request `/ad` and manipulate the remaining fragment in an adjacent keyed header.

Even though Nginx evaluates the request path as `/ad`, the resulting cache key collides with the cached response for `/admin`, allowing the attacker to retrieve sensitive content from the shared cache.

Researchers also illustrated cache-poisoned denial of service (CPDoS). An attacker can request a non-existent endpoint that collides with a legitimate resource’s cache key. If the origin server returns a cached 404 response, users attempting to access the actual page may instead receive the attacker-induced error until the cache entry expires or is purged.

A more severe scenario involves HTTP scheme confusion. When a cache key starts with `$scheme$host`, a server that accepts arbitrary Host headers, and where both HTTP and HTTPS serve the same application, an attacker can create a collision between an HTTP request with a Host value beginning with “s” and a legitimate HTTPS request.

If the application reflects the Host value into a script source, the poisoned cached page could load attacker-controlled JavaScript, leading to stored XSS vulnerabilities.

The research also cautions that Cloudflare can be bypassed as an edge-cache layer under certain conditions. Requests that contain an Authorization header may bypass Cloudflare’s cache while still reaching an Nginx origin cache that does not explicitly exclude authenticated requests from being cached.

To mitigate these risks, defenders should avoid concatenating raw, variable-length cache key components. Administrators should implement separators or structured encoding, such as `”$scheme|$host|$request_uri|$http_accept”`, validate Host headers, separate HTTP and HTTPS behaviors, and ensure that authenticated requests do not populate shared caches.

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