Category: Attack Techniques

Cache Poisoning

Also known as: DNS Spoofing, DNS Cache Poisoning, Web Cache Poisoning

Simply put

Cache poisoning is an attack in which an attacker inserts false or malicious data into a cache so that subsequent requests return the attacker-controlled content instead of the legitimate response. Victims who rely on the poisoned cache receive incorrect or harmful information without any indication that something is wrong. The attack exploits the trust that systems and users place in cached data.

Formal definition

Cache poisoning is a class of security vulnerability in which an attacker causes invalid, forged, or malicious entries to be stored in a caching layer, which are then served as authoritative responses to subsequent requestors. The attack manifests in at least two distinct contexts: DNS cache poisoning, in which false resource records are inserted into a DNS resolver cache causing clients to resolve domain names to attacker-controlled IP addresses; and web cache poisoning, in which an attacker exploits web server and cache behavior, typically through HTTP response splitting or manipulation of cache key logic, to cause a shared cache to store and serve a harmful HTTP response to other users. Web cache poisoning typically requires flaws in the web application or cache configuration, while DNS cache poisoning typically exploits weaknesses in resolver transaction ID validation or source port randomization. In both cases, the poisoned entry persists for the duration of the cache TTL, potentially affecting all users served by that cache.

Why it matters

Cache poisoning is significant because caches are designed to be trusted intermediaries that improve performance and availability. When an attacker successfully poisons a cache, the malicious response is served automatically to every subsequent user who queries that cache, multiplying the impact of a single successful attack across a potentially large population without requiring the attacker to interact with each victim individually. The poisoned entry persists for the duration of the cache TTL, meaning remediation requires not just fixing the underlying flaw but also invalidating or waiting out the cached content.

In the DNS context, a poisoned resolver cache can redirect users to attacker-controlled infrastructure, enabling phishing, credential harvesting, malware delivery, or man-in-the-middle attacks, all while the victim's browser displays a familiar domain name. In the web cache context, a poisoned shared cache can cause a harmful HTTP response, such as one containing malicious scripts or redirects, to be served to all users whose requests match the cached entry. Both variants are particularly difficult for end users to detect because the content appears to originate from a legitimate source.

The Kaminsky vulnerability, disclosed in 2008, is a well-documented example of the DNS variant's severity. Dan Kaminsky demonstrated that weaknesses in DNS resolver transaction ID validation and source port randomization allowed an attacker to poison resolver caches at scale, potentially affecting large portions of internet traffic. The disclosure prompted an industry-wide emergency patching effort and accelerated adoption of source port randomization and DNSSEC as mitigations.

Who it's relevant to

Application Security Engineers

Application security engineers are responsible for identifying and remediating the application-layer flaws that enable web cache poisoning, including HTTP response splitting vulnerabilities and misconfigured cache key logic. Static analysis tools typically cannot detect web cache poisoning because exploitation depends on the runtime interaction between application behavior and cache configuration. Dynamic testing, including intentional probing of unkeyed inputs and cache storage behavior, is generally required to assess exposure.

Infrastructure and Platform Engineers

Engineers who configure and operate DNS resolvers, CDNs, and caching layers are directly responsible for controls that limit both DNS and web cache poisoning. For DNS, this includes ensuring source port randomization is enabled and evaluating the feasibility of deploying DNSSEC validation. For web caches, it includes reviewing cache key configuration to ensure that inputs capable of influencing response content are either included in the cache key or stripped before caching.

Security Architects

Security architects must account for the trust relationships that caching introduces into system design. Because poisoned caches serve malicious content as authoritative responses, architectural decisions about which layers are cached, how TTLs are configured, and whether cryptographic authentication such as DNSSEC or HTTPS is enforced throughout the data path directly affect an organization's exposure to cache poisoning at both the DNS and web layers.

Penetration Testers and Red Teams

Penetration testers assessing web applications should probe for web cache poisoning by identifying unkeyed inputs and testing whether attacker-influenced content can be stored and served to other users. DNS cache poisoning is typically out of scope for application-layer penetration tests and requires network-level testing in controlled environments. Both variants require runtime context to assess, and neither can be reliably identified through source code review alone.

End Users and Security-Aware Consumers

End users are the ultimate targets of cache poisoning attacks and typically have no reliable way to detect that a cached response has been tampered with. Users relying on DNS resolvers that lack DNSSEC validation or that serve content over unencrypted connections may be redirected to malicious infrastructure without any visible indication. Using encrypted DNS transports such as DNS over HTTPS or DNS over TLS, and ensuring that web sessions use HTTPS, reduces but does not eliminate exposure.

Inside Cache Poisoning

Poisoned Cache Entry

A malicious or attacker-influenced response stored in a cache layer that will subsequently be served to legitimate users who request the same resource, without those users ever directly interacting with the attacker-controlled input.

Cache Key

The set of request components (typically URL, host, and select headers) that a cache uses to identify and match stored responses. Inputs excluded from the cache key but still processed by the origin server are the primary enablers of cache poisoning attacks.

Unkeyed Inputs

HTTP headers, query parameters, or other request elements that influence the origin server's response but are not included in the cache key. These are the core attack surface for cache poisoning, as they allow an attacker to inject malicious content that gets cached under a key shared with benign users.

Cache Layer

The intermediary component (such as a CDN, reverse proxy, or application-level cache) where responses are stored and replayed. The specific behavior and configuration of this layer determines which inputs are keyed, how long entries persist, and how poisoned entries can be evicted or overwritten.

Cache Invalidation and TTL

The mechanisms controlling how long a cached entry persists before expiry or forced removal. A poisoned entry with a long TTL or lacking a reliable invalidation path will affect a greater number of users over a longer window of time.

Origin Server Response Handling

The behavior of the backend application when processing unkeyed inputs and reflecting them into responses. Vulnerabilities arise when the origin server incorporates attacker-supplied unkeyed values into response headers or body content that is then stored by the cache.

Common questions

Answers to the questions practitioners most commonly ask about Cache Poisoning.

Does cache poisoning only affect web caches like CDNs and reverse proxies?

No. Cache poisoning can affect any caching layer that stores and replays responses or data based on cache keys. This includes DNS caches, application-level caches, browser caches, and API gateway caches. While CDN and reverse proxy attacks receive significant attention, the underlying principle applies wherever a cache serves stored content to multiple users or requests based on a key that an attacker may influence.

Is cache poisoning the same as cache deception?

No. Cache poisoning involves an attacker injecting malicious content into a cache so that legitimate users receive the attacker-controlled response. Cache deception is the reverse: the attacker tricks the cache into storing a victim's private or sensitive response, which the attacker then retrieves. The two attacks exploit caching behavior in opposite directions and require different mitigations, though both stem from inconsistencies between how caches and origin servers interpret requests.

How do unkeyed headers contribute to cache poisoning vulnerabilities?

Many caches construct their cache keys from only a subset of request attributes, typically the URL and Host header, while forwarding additional headers to the origin server. If an origin server uses an unkeyed header (such as X-Forwarded-Host or X-Original-URL) to influence its response, an attacker can inject a malicious value in that header. The cache stores the poisoned response under the original cache key and serves it to subsequent users whose requests match that key but do not include the attacker's header.

What steps should teams take to identify cache poisoning risks in their applications?

Teams should audit which request headers and parameters the origin server uses to construct responses, then compare that set against what the cache includes in its cache key. Any input that influences the response but is excluded from the cache key is a potential poisoning vector. Testing tools and techniques such as web cache poisoning probes (for example, using Param Miner) can help surface unkeyed inputs. Additionally, reviewing cache configuration to ensure the Vary header is correctly set for all response-influencing headers helps reduce exposure.

How can cache key normalization or keying on the full request reduce poisoning risk?

Configuring caches to include all request headers that the origin uses in generating responses within the cache key means that a response influenced by an attacker-supplied header will only be served to requests carrying that same header. This limits the blast radius of a poisoned entry. However, overly broad cache keys can significantly reduce cache hit rates and performance benefits, so teams typically need to balance security requirements against caching efficiency by selectively keying on known influential headers.

What mitigations at the origin server level help prevent cache poisoning even if cache configuration is imperfect?

Origin servers can reduce cache poisoning risk by ignoring or sanitizing unrecognized or untrusted headers rather than reflecting their values into responses, avoiding the use of arbitrary client-supplied input to construct redirects or resource URLs, and setting appropriate cache-control directives to prevent sensitive or user-specific responses from being cached at all. Using strict input validation on any header or parameter that influences response content also limits what an attacker can inject into a stored response.

Common misconceptions

Cache poisoning is the same as cache deception.

Cache poisoning involves an attacker causing a malicious or manipulated response to be stored in the cache and served to other users. Cache deception involves tricking the cache into storing a victim's private, authenticated response so the attacker can later retrieve it. The attack direction and goal are distinct: poisoning targets users who make future requests, while deception targets the confidentiality of a specific victim's data.

Using HTTPS prevents cache poisoning.

TLS encrypts data in transit but does not prevent cache poisoning. The vulnerability exists in how the cache and origin server handle request inputs at the application layer, which occurs after TLS termination. An attacker can still inject malicious unkeyed inputs through HTTPS requests that result in poisoned cache entries.

Cache poisoning only affects public, unauthenticated content.

While cache poisoning most commonly impacts publicly cached responses, misconfigurations in caching layers can result in responses that vary by user context being incorrectly cached and served broadly. Additionally, poisoned responses can carry payloads such as malicious scripts that affect authenticated users who subsequently load the cached resource.

Best practices

Audit all HTTP headers and request parameters processed by the origin server and explicitly configure the cache key to include any input that influences the response, reducing the unkeyed input attack surface.

Disable or strip unnecessary HTTP headers at the cache or reverse proxy layer before they reach the origin server, particularly headers not required by the application that could be reflected into cached responses.

Apply strict cache-control policies, including appropriate TTL values and Cache-Control directives such as no-store or private for responses that contain user-specific, sensitive, or dynamically generated content.

Regularly test caching infrastructure using purpose-built tooling to identify unkeyed inputs and verify that variations in those inputs do not produce different cached responses visible to other users.

Implement cache purging and invalidation procedures so that if a poisoned entry is detected, it can be evicted promptly without waiting for natural TTL expiry.

Review and validate the behavior of CDN and reverse proxy configurations after any changes, as default configurations from vendors may not key all relevant inputs and may differ from expectations established during initial security review.