Cache Poisoning: Making Your CDN Serve Malicious Content to Everyone 🗄️

Introduction: The Hidden Danger in Your Caching Infrastructure

Content Delivery Networks (CDNs) and web caches are the invisible backbone of today’s internet, making websites load faster and reducing server strain. However, these performance-enhancing systems harbor a critical vulnerability that attackers can exploit to serve malicious content to thousands or even millions of users simultaneously. Welcome to the world of cache poisoning—a sophisticated attack vector that transforms your trusted CDN into a weapon against your own users.

Cache poisoning attacks manipulate the caching mechanisms that websites rely on, tricking them into storing and distributing malicious responses. Unlike traditional attacks that target individual users, cache poisoning allows a single malicious request to poison content for all subsequent visitors, creating a force-multiplier effect that makes these attacks particularly devastating.

Understanding Web Cache Architecture

Before diving into the attacks themselves, it’s essential to understand how web caching works. When a user requests a resource from a website, the request typically passes through multiple layers:

1. The Client Browser: Makes the initial request
2. The CDN/Caching Layer: Intermediate servers distributed globally
3. The Origin Server: The actual web server hosting your application

CDNs use cache keys to compare new requests against cached resources, determining whether content should be served from cache or requested from the origin server. This optimization dramatically improves performance, but it also creates opportunities for attackers to manipulate what gets stored and served.

The cache operates on a simple principle: store frequently requested static resources locally to avoid repeatedly querying the origin server. This reduces latency and server load, but the system’s effectiveness depends entirely on correctly identifying what should and shouldn’t be cached.

Cache Poisoning: The Fundamentals

What is Cache Poisoning?

Cache poisoning uses an HTTP request to trick an origin web server into responding with a harmful resource that has the same cache key as a clean request, causing the poisoned resource to be cached and served to other users. The attack exploits discrepancies in how different components of the caching infrastructure interpret and process requests.

The attack works because of a fundamental assumption in caching systems: that resources with the same cache key will always return the same content. Attackers exploit this by crafting requests that bypass cache validation mechanisms while still matching the cache key of legitimate requests.

How Cache Poisoning Works

The typical cache poisoning attack follows this pattern:

1. Reconnaissance: The attacker identifies how the cache system generates cache keys and what parameters it considers
2. Crafting the Payload: A malicious request is constructed that will be cached under a legitimate cache key
3. Cache Injection: The attacker sends the crafted request, causing the malicious response to be stored in the cache
4. Mass Distribution: All subsequent users requesting that resource receive the poisoned content

The beauty (from an attacker’s perspective) and the danger (from a defender’s perspective) of cache poisoning is its scalability. One successful poisoning attempt can affect thousands of users until the cache expires or is manually purged.

Cache-Poisoned Denial of Service (CPDoS)

The Evolution of Cache Poisoning

Cache-Poisoned Denial of Service (CPDoS) attacks work by provoking an error on the origin server that is not detected by the intermediate caching system, causing the cache to be poisoned with the server-generated error page and rendering the victim service unavailable. This attack variant represents a significant evolution in cache exploitation techniques.

Three Primary CPDoS Attack Methods

Research has identified three main CPDoS attack vectors:

1. Header Oversize (HHO) Attacks: These attacks send HTTP requests with oversized headers that the CDN accepts but the origin server rejects. The attack works by sending requests with oversized headers that pass through the CDN but cause errors when they reach the origin server, with the error page then being cached.

2. Meta Character (HMC) Attacks: These exploit differences in how the CDN and origin server handle special characters in HTTP headers. Meta characters that are acceptable to the cache but cause parsing errors on the origin server trigger error pages that get cached.

3. HTTP Method Override (HMO) Attacks: These attacks manipulate HTTP method override headers, causing the origin server to reject requests that the cache considers valid.

Real-World Impact of CPDoS

In an extensive study of fifteen web caching solutions, researchers identified one proxy cache product and five CDN services vulnerable to CPDoS, including prominent solutions that cache high-value websites. The consequences are severe—a single malicious request can paralyze a website across large geographical regions.

When an error page is injected, the CDN distributes it to many edge cache server locations around the world, with attacks from Frankfurt, Germany affecting regions across Europe and parts of Asia. This demonstrates the global reach that attackers can achieve with minimal effort.

Web Cache Deception: Stealing Private Data

While cache poisoning focuses on distributing malicious content, web cache deception represents a different but equally dangerous attack vector that exploits caching mechanisms to steal sensitive user data.

Understanding Web Cache Deception

Web cache deception exploits cache rules to trick the cache into storing sensitive or private content, which the attacker can then access by exploiting discrepancies between how the cache server and origin server handle requests. This attack doesn’t require poisoning the cache with malicious content; instead, it tricks the cache into storing content it shouldn’t.

The Attack Mechanism

In a web cache deception attack, an attacker persuades a victim to visit a malicious URL that induces the victim’s browser to make an ambiguous request for sensitive content, with the cache misinterpreting this as a request for a static resource and storing the response.

Here’s a practical example:

1. A legitimate user profile page exists at https://example.com/my_profile
2. The attacker crafts a URL: https://example.com/my_profile/fake.css
3. The victim clicks this link while authenticated
4. The origin server ignores the non-existent fake.css and serves the profile page
5. The cache sees the .css extension and caches the response as a static file
6. The attacker requests the same URL and receives the cached private profile data

The attacker can then request the same URL to access the cached response, gaining unauthorized access to private information.

Cache Rule Exploitation

Web cache deception attacks exploit different types of cache rules, including static file extension rules that match file extensions like .css or .js, static directory rules that match URL paths starting with specific prefixes like /static or /assets, and file name rules that match specific files like robots.txt and favicon.ico.

Recent Vulnerabilities and Case Studies

Next.js Cache Poisoning (CVE-2025-49826)

A critical vulnerability discovered in Next.js versions 15.1.0 to 15.1.8 involves a cache poisoning bug that could lead to Denial of Service when using routes with Incremental Static Regeneration (ISR) or Server-Side Rendering (SSR) routes combined with a CDN configured to cache HTTP 204 responses.

When these conditions are met, a 204 No Content response could be erroneously cached for static pages, resulting in all users attempting to access the page being served a blank 204 response and causing a service blackout. This vulnerability received a CVSS score of 7.5, indicating high severity.

BIND 9 DNS Cache Poisoning (CVE-2025-40778)

The DNS infrastructure, which underlies all internet communication, has also been affected by cache poisoning vulnerabilities. CVE-2025-40778 affects over 706,000 exposed BIND 9 resolver instances worldwide, with a CVSS score of 8.6, exploiting a logic flaw that accepts and caches resource records not part of the original query.

The vulnerability impacts BIND 9 versions from 9.11.0 through 9.16.50, 9.18.0 to 9.18.39, 9.20.0 to 9.20.13, and 9.21.0 to 9.21.12, allowing attackers to inject fake address records pointing to attacker-controlled infrastructure.

Once poisoned, caches can misdirect downstream clients for hours or days depending on TTL values, leading to phishing attacks, data interception, or service disruptions.

Technical Deep Dive: Cache Key Manipulation

Understanding Cache Keys

Cache keys are the identifiers that caching systems use to store and retrieve content. Typically, they include:

• The URL path
• Query string parameters (sometimes)
• The host header
• Specific request headers (varies by configuration)

The problem arises when there’s a mismatch between what the cache considers part of the cache key and what the origin server uses to generate its response. This discrepancy creates an opportunity for attackers to craft requests that:

1. Match the cache key of legitimate requests
2. Trigger different behavior on the origin server
3. Cause unintended content to be cached

Unkeyed Inputs: The Attacker’s Best Friend

Many caching systems don’t include all HTTP headers in their cache keys. These “unkeyed inputs” can be manipulated by attackers without affecting the cache key, meaning the poisoned response gets stored under the same key as legitimate requests.

Common unkeyed inputs include:

• User-Agent headers
• Accept-Language headers
• Cookie values
• Custom application headers
• HTTP method override headers

Attackers systematically test these inputs to find ones that: - Aren’t included in the cache key - Influence the origin server’s response - Can be exploited to inject malicious content

Defending Against Cache Poisoning and Deception

Origin Server Configuration

Organizations should review their caching configuration and ensure they cache only files that are static and do not depend on user input in any way. This fundamental principle eliminates many attack vectors.

Best Practices for Origin Configuration:

1. Strict Path Handling: Configure your application to reject requests with non-existent paths rather than silently ignoring path components
2. Proper Cache-Control Headers: Always set appropriate Cache-Control headers that explicitly indicate what should and shouldn’t be cached
3. Content-Type Validation: Ensure responses include accurate Content-Type headers that match the requested resource type

Cache Layer Protections

The most effective mitigation is to disable error page caching in the cache configuration, with CDNs like CloudFront and Akamai providing configuration settings to do so.

CDN Configuration Guidelines:

1. Disable Error Page Caching: Configure your CDN to never cache error responses (4xx and 5xx status codes)
2. Cache-Control Respect: Ensure the CDN respects Cache-Control headers from the origin server
3. Content-Type Verification: Implement checks that verify the Content-Type header matches the URL extension before caching

Web Application Firewall (WAF) Deployment

A Web Application Firewall can be deployed to mitigate CPDoS attacks, but WAFs must be placed in front of the cache to block malicious content before it reaches the origin server. WAFs positioned behind the cache can still be exploited to generate error pages that get cached.

Advanced Detection and Monitoring

Implement Comprehensive Monitoring:

1. Cache Hit Rate Analysis: Sudden drops in cache hit rates may indicate poisoning attempts
2. Error Response Monitoring: Track unusual spikes in error responses being served from cache
3. Content-Type Mismatches: Alert on responses where the Content-Type doesn’t match the URL extension
4. Cache Key Analysis: Regularly audit what parameters are included in cache keys

Anomaly Detection:

• Monitor for unusual request patterns with oversized headers
• Track requests with special characters in headers
• Identify requests with suspicious path manipulations
• Alert on unexpected HTTP method override usage

Testing Your Infrastructure for Vulnerabilities

Systematic Vulnerability Assessment

Constructing a basic web cache deception attack involves identifying a target endpoint that returns a dynamic response containing sensitive information, identifying a discrepancy in how the cache and origin server parse the URL path, crafting a malicious URL that uses the discrepancy, and fetching the cached response.

Testing Methodology:

1. Identify Dynamic Endpoints: Map all endpoints that return user-specific or sensitive data
2. Test Path Manipulation: Try appending various file extensions and paths to these endpoints
3. Verify Caching Behavior: Check if modified URLs result in cached responses
4. Analyze Cache Keys: Determine what parameters influence cache storage decisions
5. Test Unkeyed Inputs: Systematically test headers and parameters not included in cache keys

Automated Scanning Tools

Several tools can help identify cache poisoning vulnerabilities:

• Burp Suite Extensions: Tools like Param Miner can identify unkeyed inputs
• Custom Scripts: Develop scripts to systematically test cache behavior
• HCache Framework: Research tools designed specifically for web cache poisoning detection

The Future of Cache Security

Emerging Threats

As web applications become more complex and caching systems more sophisticated, new attack vectors continue to emerge. Recent research has focused on:

1. Client-Side Cache Poisoning: Exploiting browser-level caching mechanisms
2. HTTP/2 and HTTP/3 Exploits: New protocols introduce new caching behaviors to exploit
3. Edge Computing Vulnerabilities: As computation moves to the edge, new cache-related attack surfaces appear
4. API Cache Poisoning: REST and GraphQL APIs present unique caching challenges

Evolving Defenses

The security community is developing advanced defenses:

1. Machine Learning Detection: AI-powered systems that identify anomalous caching patterns
2. Zero-Trust Caching: Architectures that verify content authenticity even when served from cache
3. Cryptographic Cache Verification: Signed responses that can be validated even after caching
4. Dynamic Cache Key Generation: Intelligent systems that adapt cache keys based on content sensitivity

Conclusion: Building Resilient Caching Architectures

Cache poisoning and web cache deception represent serious threats to modern web infrastructure. These attacks exploit the fundamental tension between performance optimization and security, taking advantage of the complexity inherent in distributed caching systems.

The key to defense lies in understanding that caching is not just a performance feature—it’s a critical security boundary that must be properly configured and monitored. Organizations must:

1. Implement Defense in Depth: Layer multiple security controls across the caching infrastructure
2. Maintain Vigilance: Continuously monitor for signs of cache exploitation
3. Stay Updated: Keep all caching systems, CDNs, and origin servers patched
4. Test Regularly: Conduct systematic testing to identify vulnerabilities before attackers do
5. Educate Teams: Ensure developers and operations staff understand cache security implications

As web applications continue to rely heavily on caching for performance, the importance of secure cache implementation will only grow. The attacks described in this article demonstrate that a single misconfiguration or overlooked vulnerability can have widespread consequences, affecting thousands of users simultaneously.

By understanding these attack vectors, implementing proper defenses, and maintaining constant vigilance, organizations can harness the performance benefits of caching while protecting their users from these sophisticated attacks. The battle between cache poisoning attackers and defenders continues to evolve, making ongoing education and adaptation essential for maintaining secure web infrastructure.

---

Key Takeaways

• Cache poisoning attacks can serve malicious content to all users through a single request
• CPDoS attacks can render entire websites unavailable by poisoning caches with error pages
• Web cache deception exploits path confusion to steal private user data
• Recent vulnerabilities in popular frameworks and DNS servers show the ongoing threat
• Proper configuration of origin servers, CDNs, and WAFs is essential for defense
• Continuous monitoring and regular testing are critical for maintaining cache security
• Defense requires understanding cache key generation, unkeyed inputs, and content validation

The sophistication and impact of these attacks make cache security a top priority for any organization operating at scale on the modern internet.

Related Topics

#cache poisoning, CDN cache poisoning, web cache poisoning, content delivery network attack, CDN malicious content injection, caching infrastructure vulnerability, CDN serve malicious payload, poisoned cache response, HTTP cache poisoning, cache poisoned denial of service, CPDoS, cache-poisoned DoS, CDN cache key manipulation, unkeyed inputs cache poisoning, HTTP header oversize attack cache, HTTP method override cache poisoning, header meta-character cache attack, web cache deception, web cache deception attack, sensitive data cached maliciously, cache rules exploitation, cache key mismatch attack, large scale cache poisoning, cache poisoning 2025, modern CDN attack vectors, archive CDN cache breach, caching layer vulnerability, cache injection attack, multi-user malicious content via cache, CDN error-page caching abuse, static resource cache attack, HTML XSS via cache poisoning, malicious script via CDN cache, browser delivered malware via cache, cache hit manipulation attack, cache miss induced DoS via poisoning, CDN vulnerability mitigation cache poisoning, DevOps cache configuration best practices, cache key normalization, cache-layer security best practices, disable error cache, dynamic content caching risk, Cache-Control header misuse, content-type verification cache, GET/HEAD caching only, CDN log monitoring cache anomalies, cache hit rate anomaly detection, CDN cache monitoring tools, CDN anomaly detection framework, edge computing cache attacks, API caching vulnerabilities, REST API cache poisoning, GraphQL cache injection, supply chain cache poisoning, CDN multi-tenant cache risk, DNS cache poisoning vs web cache poisoning, cache accounting attacks CDNs, caching infrastructure security 2025