Cache Keys Turned Hostile: A Small Lookup Rule With Big Security Fallout

Introduction

Web caching is supposed to make sites faster and steadier. But when the logic that decides what gets cached can be influenced by a request, the same system can start serving the wrong content to the wrong person. That is the core risk behind cache key injection: a flaw in how shared responses are indexed, not just stored.

Fast Facts

• Cache key injection targets the lookup rule a cache uses to match requests with stored responses.
• The technique described can let protected content be served outside its intended access checks.
• Poisoned cache entries can affect Nginx-related deployments that rely on shared caching behavior.
• The reported impact includes exposure of sensitive cached pages and denial-of-service conditions.
• Potential stored XSS becomes a concern if unsafe content is cached and later replayed to users.

Body

The technical danger sits in the cache key itself. If a web stack builds that key from request elements in unsafe ways, an attacker may be able to steer which response is reused for later requests. That can turn a normal optimization into a trust problem, especially when public and private content share the same caching path.

In practical terms, the risk is not limited to one bad page. A poisoned entry can cause a cache to hand out content that was meant for a different context, including pages that should have been checked before delivery. In some setups, that same behavior may also create denial-of-service pressure if the cache keeps replaying broken or harmful responses.

The broader lesson is that caching is not just storage. It is a security boundary. When caches derive keys from attacker-influenced input, defenders need to think about normalization, response separation, and whether authenticated or sensitive data should ever be shared through a cache at all. That is especially important in reverse-proxy-style deployments, where one mistake can affect many users at once.

At the time of writing, public information has not fully established the exact cache-key construction flaw, the complete scope of affected setups, or whether the broader impact went beyond the cache behavior described here. The available information supports a risk analysis, not a conclusion of wider compromise.

Conclusion

Cache key injection is a reminder that performance features can become security machinery the moment they start deciding who sees what. The lesson for defenders is straightforward: if a shared cache can be steered by input, it should be treated as part of the attack surface, not just part of the speed stack.

WIKICROOK

• Cache key: the identifier a cache uses to store and retrieve a response.
• Cache poisoning: forcing a cache to store malicious or incorrect content.
• Access control bypass: getting access to content without passing the intended checks.
• Stored XSS: attacker-controlled script saved on a server and later shown to users.
• Reverse proxy: a server that sits in front of web apps and often handles caching.