Web Cache Poisoning: The Overlooked Attack with High Impact

1 day ago 9

BOOK THIS SPACE FOR AD

ARTICLE AD

Most security professionals are familiar with XSS, SQL injection, and authentication bypasses, but there’s one subtle yet powerful attack that often gets overlooked: web cache poisoning.

Web caches are designed to speed up content delivery and reduce server load. But when they aren’t configured properly, they can be exploited by attackers to serve malicious content, redirect users, or even leak sensitive data; all while bypassing traditional security mechanisms.

Many researchers ignore cache poisoning because:

It requires multiple conditions to be exploitable.It’s not always easy to test compared to other vulnerabilities.The attack’s impact depends on how many users rely on the poisoned cache.

However, when exploited correctly, cache poisoning can turn into a severe attack vector, leading to persistent XSS, credential theft, phishing, and even denial-of-service (DoS).

Let’s break down what web cache poisoning is, how attackers exploit it, real-world examples, and how to detect and prevent it effectively.

A web cache sits between users and the backend server, storing copies of previously requested resources to speed up future requests.

Instead of contacting the server every time, the cache serves a pre-saved response, reducing load times and improving performance.

User A requests https://example.com/home .The server responds with the page. The cache stores this response.When User B visits the same page, the cache serves the stored response instead of making another request to the backend.

This improves website speed and scalability — but what happens if an attacker manipulates what gets stored in the cache?

To execute a cache poisoning attack, an attacker must:

Find a cacheable endpoint.Inject malicious content into the response (e.g., XSS, redirects, sensitive data leaks).Trick the cache into storing and serving the poisoned response to other users.

To do this, attackers target unkeyed inputs — parts of the HTTP request that affect the response but are not included in the cache key.

1. Header-Based Cache Poisoning

Some caching servers trust user-controlled headers, allowing attackers to inject harmful responses.

Example Attack:

GET /dashboard HTTP/1.1
Host: example.com
X-Forwarded-Host: attacker.com

If the cache incorrectly includes the attacker’s header in the response but doesn’t key it, all users will receive a poisoned version of /dashboard.

2. Query Parameter Poisoning

Some caching mechanisms ignore query parameters, meaning an attacker can inject malicious JavaScript or redirects that get stored and served to others.

Example Attack:

GET /news?theme=<script>alert(1)</script> HTTP/1.1

If the server reflects this parameter in the response and the cache stores it, future visitors will execute the XSS payload.

3. Redirect-Based Cache Poisoning

Misconfigured caches can store and serve attacker-controlled redirects, leading to phishing, malware distribution, and session hijacking.

Example Attack:

The attacker sends a request with a crafted redirect:GET /login HTTP/1.1
Host: example.com
Referer: evil.com

2. If the cache stores the redirect, every user visiting /login will be silently redirected to evil.com.

In 2018, security researchers discovered a serious cache poisoning vulnerability in Cloudflare.

What Happened?

Attackers found that Cloudflare’s caching system trusted unkeyed headers.They exploited this flaw to inject malicious content into cached responses.The attack affected Cloudflare customers who unknowingly served attacker-controlled content to their users.

Why It is Dangerous

Poisoned pages could be used for persistent XSS, phishing, and data exfiltration.The attack could be repeated indefinitely by re-poisoning the cache.

1. Identifying Cacheable Endpoints

Look for static pages, news sections, dashboards, or any content served to multiple users.

2. Testing for Unkeyed Inputs

Modify headers or query parameters and see if they are reflected in the response.Try injecting unique values and check if the cache serves them back.

3. Using Security Tools

Burp Suite Param Miner: Detects unkeyed inputs vulnerable to poisoning.Turbo Intruder: Automates high-speed attacks to force cache inconsistencies.

1. Validate and Sanitize User Inputs

Never trust headers like X-Forwarded-For, X-Forwarded-Host, or Referer.

2. Implement Proper Cache Keying

Ensure caches include all relevant request components in the cache key.

3. Set Secure Cache-Control Headers

Use Cache-Control: no-store, no-cache, must-revalidate for sensitive content.

4. Regularly Audit Cache Behavior

Monitor caching logs and purge caches when anomalies are detected.

Web cache poisoning is a severely underestimated attack, capable of injecting malicious scripts, stealing credentials, and silently redirecting users.

Many security researchers ignore cache poisoning because it seems rare or complex — but when misconfigurations exist, the impact can be devastating.

Attackers exploit unkeyed headers, query parameters, and redirects to poison caches.Once poisoned, the cache serves malicious content to every visitor.Proper cache configurations, input validation, and security headers prevent exploitation.

Most people don’t even test for cache poisoning, but now, you know better.

Read Entire Article