Cache Poisoning is an attack that inserts malicious or incorrect data into a cache so later users receive the wrong content. In identity and web systems, attackers target DNS, web, and application caches to redirect traffic, bypass controls, or serve crafted responses, so defenders must validate cache keys and inputs.
How cache poisoning works
Cache poisoning is a cache integrity attack, the attacker does not need to win every request, only to get malicious data stored once so later users are served the wrong response. That makes the cache itself a trust boundary, not just a performance layer.
It matters because caches are designed to reuse responses, so a poisoned entry can amplify a single bad write into many incorrect reads. In web and DNS systems, that can redirect traffic, alter page content, or let an attacker steer users toward hostile infrastructure.
Where cache poisoning shows up
The term covers several related attack paths. dns cache poisoning targets resolver state so future lookups resolve to an attacker-controlled destination. web cache poisoning targets shared HTTP caches, while application cache poisoning can corrupt upstream application logic, template fragments, or API responses that are later reused.
These attacks are especially effective when cache keys do not fully reflect the inputs that shape the response. If a cache ignores a header, host value, query parameter, or routing decision that changes content, the attacker may be able to store a crafted variant that appears legitimate to later users.
For a practical view of the web side of the problem, see Web Application Attacks Guide, which covers web cache poisoning alongside other injection and request-manipulation patterns. DNS-specific attack paths are also part of DNS Security Guide.
Why it is dangerous in identity and web systems
In identity-adjacent environments, cache poisoning can subvert trust decisions that users and services rely on. A poisoned DNS cache may send a browser or service to the wrong endpoint, while a poisoned web cache can serve content that looks authenticated, trusted, or locally generated when it is not.
That is dangerous because the cache can become a covert distribution channel for phishing pages, malicious redirects, misleading security banners, or altered application state. The impact often shows up far from the original insertion point, which makes attribution and cleanup harder.
DNS defenders often need a deeper look at resolver behaviour, cache validation, and monitoring, which is why DNS Security Guide is a useful companion reference for the protocol and resolver side of the issue.
How defenders reduce exposure
Exposure checks usually start with cache inventory, because different cache layers fail in different ways. Teams should know which resolvers, reverse proxies, CDN layers, application caches, and service-side caches are in use, which inputs influence them, and which controls are meant to keep untrusted data out.
Defence is strongest when cache keys are specific, untrusted inputs are normalised before reuse, and responses that vary by sensitive context are not shared beyond the right boundary. Strong cache hygiene also includes logging, cache purge procedures, and control over who can poison or invalidate entries.
Because cache poisoning is a common web abuse pattern, it sits naturally within broader web attack review and testing, including the request-handling and proxy behaviour covered in Web Application Attacks Guide.
Risk and Threat Considerations
Cache poisoning is risky because it turns a performance feature into a persistence and distribution mechanism. Once the poisoned entry is accepted, the attacker may influence many users without maintaining live access to the origin system.
Failure mechanism: A cache accepts attacker-shaped data or a response variant that does not match the true request context, then reuses it for later lookups or requests.
Impact: Users receive false content, wrong destinations, or manipulated responses, which can enable redirect abuse, traffic interception, phishing, and control bypass.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V13 — Configuration | Cache poisoning exploits unsafe cache and proxy configuration around request variation. |
| Recommendation — Harden cache keys, vary rules, and response handling so untrusted inputs cannot alter shared cache entries. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Improper caching and proxy behavior can expose API responses to poisoning and reuse attacks. |
| Recommendation — Review API gateway and cache configuration so shared responses cannot be polluted or replayed across contexts. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Application-layer request handling and shared-response logic are common cache-poisoning failure points. |
| Recommendation — Validate application request-processing paths that feed caches and prevent attacker-controlled variance from being reused. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Cached content is stored data whose integrity and protection affect whether poisoned entries persist and spread. |
| Recommendation — Protect cached data with integrity controls and limit who can modify or invalidate shared entries. | ||
| MITRE ATT&CK | T1185 — Browser Session Hijacking | Poisoned web content can steer users toward malicious destinations or session abuse paths. |
| Recommendation — Hunt for poisoned response paths that redirect browsers or interfere with trusted web sessions. | ||
Practitioner Guidance
What to watch for: Investigate any cache entry that appears to vary unexpectedly by source, host, query string, or header set, especially when the served content does not match the origin response path. Repeated cache misses followed by suspiciously stable bad hits are a useful warning sign.
Governance implication: Ownership should be explicit across DNS, CDN, reverse proxy, and application teams, because cache poisoning usually exploits the gaps between those layers rather than a single product flaw.
Related resources from NHI Mgmt Group
- How should security teams test whether a cache key is safe from poisoning in practice?
- What do teams get wrong about detecting cache poisoning and related cache key flaws?
- What happens when a cache poisoning flaw is chained with a reflected client-side gadget?
- What should security teams do first when auditing for web cache poisoning risk?