Cybersecurity glossary
What is Cache Poisoning?
Learn what cache poisoning means in HTTP and distributed systems, how malicious or incorrect entries get stored under legitimate keys, and how it differs from web cache poisoning on shared CDNs.
Definition
Cache poisoning is a class of attacks and failures where a cache stores a harmful, incorrect, or attacker-controlled entry under a key that honest clients later reuse, causing them to receive the wrong data without contacting the origin again.
Why cache poisoning matters
Caches exist to save time and bandwidth. Cache poisoning flips that efficiency into a weapon: one successful store operation can affect thousands of later requests. Because victims often never reach the origin, poisoning can persist silently across regions and user sessions.
The concept spans DNS resolvers, HTTP CDNs, API gateways, server-side object caches, and even client-side service workers. Security reviews that only harden origin code while ignoring what gets stored downstream leave a durable attack surface open.
How cache poisoning happens
Poisoning requires three ingredients: a cache that stores responses, a way to influence what gets stored, and a key that future honest requests will match. Attackers and misconfigurations supply the influence; weak keying supplies the amplification.
Attacker shapes a request
Malicious or unusual headers, parameters, or paths trigger an unintended response from the origin or edge.
Cache accepts the response
Freshness rules allow storage; the entry is indexed under a key honest users will reuse.
Harmful bytes are retained
The stored body or headers include XSS, redirects, wrong JSON, or session cookies.
Victims receive the cached copy
Normal requests hit the poisoned slot and never see the intended origin response.
Impact persists until eviction
TTL expiry, manual purge, or key rotation ends the incident; until then, exposure continues.
Where poisoning appears
HTTP shared caches
CDNs and reverse proxies serving one stored response to many clients—the web cache poisoning specialty.
DNS resolver caches
Forged answers redirect entire applications before TLS and HTTP begin.
Application object caches
Redis or in-process maps that omit tenant or user dimensions in keys.
Negative caching
404 or error bodies cached too aggressively, breaking routes after transient failures.
Browser HTTP cache
Less common for cross-user impact but relevant for single-user persistence of bad content.
Service workers
Client-controlled caches that can serve attacker-influenced assets offline.
Poisoning vectors compared
| Cache layer | Common enabler | Primary mitigation |
|---|---|---|
| CDN / reverse proxy | Unkeyed headers changing responses | Fix Vary, disable cache on variance, purge and audit keys |
| DNS resolver | Weak resolver validation, spoofed replies | DNSSEC, source port randomization, encrypted DNS where appropriate |
| App server cache | Shared key across tenants or roles | Namespace keys by principal; never cache authz decisions alone |
| Error page cache | Caching 4xx/5xx with attacker-reflected input | no-store on errors; sanitize reflected output |
| Web cache (browser) | Conflicting Cache-Control from intermediaries | Consistent headers; avoid sensitive content in cacheable responses |
Defense checklist
- Distinguish generic cache poisoning from web cache poisoning when scoping tests and runbooks.
- Never cache personalized HTML, Set-Cookie responses, or authorization-dependent JSON on shared tiers.
- Include every response-varying dimension in cache keys or emit precise Vary headers.
- Treat unkeyed query parameters and headers as untrusted input in cacheable routes.
- Set Cache-Control: no-store on error and diagnostic responses that might reflect user input.
- Patch header injection and request smuggling flaws that let attackers control stored metadata.
- Monitor CDN purge events and anomalous hit ratios on dynamic paths after deployments.
- For application caches, prefix keys with tenant ID, locale, and permission scope where data differs.
Limits and pitfalls
Not every stale response is poisoning. Legitimate caching of public assets is desirable. The security failure is storing attacker-controlled or user-specific content where others will retrieve it.
Teams sometimes over-focus on CDN dashboards while ignoring Redis caches inside the API layer. Conversely, disabling all HTTP caching to “be safe” can hide keying bugs that still exist at the edge when someone re-enables performance features later.
The practical takeaway
Cache Poisoning means a cache remembered the wrong thing under a label honest clients trust. It is a family of problems—not only the well-known CDN research class covered under web cache poisoning.
Design keys and freshness rules so sensitive variance never shares a slot, test shared caches with adversarial requests, and treat a single poisoned entry as an incident that requires purge plus root-cause fixes—not just waiting for TTL.
Related security terms
Web Cache Poisoning
CDN and browser shared-cache attacks that abuse HTTP keying and unkeyed inputs.
Cache Key
How caches index responses; weak keys enable many poisoning variants.
DNS Spoofing / Cache Poisoning
Resolver-level poisoning that redirects clients before HTTP caching matters.
HTTP Header Injection
Injection flaws that can influence stored responses and cache metadata.
Frequently asked questions
What is cache poisoning in simple terms?
Something bad gets saved in a cache under a normal lookup label. Later, legitimate users ask for the same thing and receive the bad copy instead of fresh, correct data from the source.
How is generic cache poisoning different from web cache poisoning?
Cache poisoning is the broad idea: any cache layer can be polluted. Web cache poisoning specifically targets shared HTTP caches such as CDNs and reverse proxies, often by abusing unkeyed headers or parameters.
Do only attackers cause cache poisoning?
No. Misconfiguration, buggy intermediaries, stale negative caching, and deployment mistakes can poison caches without malicious intent. The user impact is similar: wrong bytes served from cache.
Can application-level caches be poisoned?
Yes. In-memory stores, Redis, ORM second-level caches, and template caches can retain attacker-influenced objects if keys omit tenant, user, or authorization context.
What is the impact of cache poisoning?
Impacts range from broken pages and stale configuration to XSS delivery, open redirects, session fixation via poisoned Set-Cookie, and large-scale malware injection through a single stored entry.
How do teams prevent cache poisoning?
Use correct cache keys and Vary, avoid caching personalized responses on shared tiers, validate unkeyed inputs, patch injection bugs, set safe Cache-Control on errors, and test CDN behavior under adversarial requests.
References
Explore authoritative guidance and frameworks related to cache poisoning.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.