Cache Key Injection: New Nginx Cache Poisoning Flaw Enables Stored XSS

A class of web cache vulnerabilities that flips conventional wisdom about caching security on its head. While most cache poisoning research targets unkeyed request fragments the parts of a request caches ignore when deciding what to store Brumen’s technique, dubbed “cache key injection,” attacks the keyed values themselves, the very components caches trust to uniquely identify a response.

A new Nginx cache key injection flaw allows attackers to manipulate how web content is stored in the cache. By poisoning the cache with malicious content, attackers may cause that content to be delivered to other users, potentially leading to security risks such as Stored XSS.

The vulnerability can also be exploited to cause Cache-Poisoned Denial of Service (CPDoS). This could result in legitimate users receiving corrupted responses or being unable to access affected web services until the poisoned cache is cleared.

Cache Key Injection

At the heart of the vulnerability is a deceptively simple problem: how caches like Nginx build a cache key. A typical configuration concatenates fragments such as the HTTP scheme, host, request URI, and headers like Accept into a single string before hashing it, for example, proxy_cache_key "$scheme$proxy_host$uri$is_args$args$http_accept".

Because these fragments are joined without delimiters, two completely different HTTP requests can produce an identical final string. Brumen demonstrates that shifting characters between the URL path and an adjacent header, say, moving /admin into /ad plus an Accept: min*/* header can generate the exact same cache key as the legitimate, unmodified request.

The research walks through several real-world exploitation paths:

Web cache deception without user interaction: By splitting a restricted path like /admin across the URI and the Accept header, an attacker bypasses IP-based access-control lists and retrieves a cached admin dashboard response without ever tricking a victim into clicking anything.
Cache-Poisoned Denial of Service (CPDoS): An attacker preemptively requests a broken variant of a legitimate path (e.g., /h with Accept: ome*/*), causing the origin to return a 404 that gets cached under a key colliding with /home. Every subsequent visitor gets served the error instead of the real page.
Stored XSS via HTTP scheme confusion: This is the most striking finding. When a cache key starts with $scheme$host and the backend reflects the Host header into a script tag’s src attribute, an attacker can shift the trailing “s” from “https” onto a crafted hostname over plain HTTP (e.g., sdummywebsite.localhost). The resulting key collides with the legitimate HTTPS key, so real HTTPS visitors receive a page referencing the attacker’s domain, executing attacker-controlled JavaScript as persistent stored XSS.
Bypassing layered defenses: In tests pairing Cloudflare with an Nginx origin, Brumen found that adding an Authorization header made Cloudflare bypass its own edge cache while Nginx cached normally, letting an attacker’s injected key reach and poison the origin cache directly, bypassing the CDN’s protections entirely.

A critical takeaway is that hashing the final cache key provides no protection if the underlying string is ambiguous; colliding inputs still hash identically.

Brumen recommends replacing bare concatenation ($scheme$host$request_uri$http_accept) with delimited, structurally distinct formats ($scheme|$host|$request_uri|$http_accept) so no combination of attacker-controlled values can masquerade as another request.

“Defenders often treat keyed values as inherently safe simply because they’re used to build the cache key this research shows that assumption is exactly where the risk lives,” one industry observer noted when reviewing the disclosure, underscoring that key construction logic deserves the same scrutiny as unkeyed header handling.

Teams running Nginx or similar reverse proxies with custom proxy_cache_key directives should audit their configurations for unstructured concatenation, verify Host header handling doesn’t allow arbitrary values, and confirm HTTP-to-HTTPS redirection is properly enforced to eliminate scheme-confusion collisions.

Site: Thecyberdef.com

Follow TheCyberDef on Google News, LinkedIn & X for the latest cybersecurity updates. Stay informed.