TL;DR — Why We’re Talking About This
Caching vulnerabilities are often misunderstood or entirely overlooked by penetration testers. Their true risk isn’t always obvious, but they have the potential to escalate lower-severity or even informational findings into critical bugs.
If you’re unfamiliar with these vulnerabilities, or want to learn how to test for them, we recommend the excellent breakdowns from PortSwigger here and here. Also, don’t skip the final thoughts – they contain important takeaways for both pentesters and clients.
Web Caches: A Double-Edged Sword
Web caching is everywhere: content delivery networks (CDNs), reverse proxies, and modern web frameworks all rely on it to speed up page loads and reduce server strain. But caching isn’t just a performance optimisation—it can also become a backdoor for attackers when misconfigured.
Two high-risk vulnerabilities stand out:
- Web Cache Poisoning (WCP): Can an attacker inject malicious content into a cache so that subsequent users are served it?
- Web Cache Deception (WCD): Can an attacker trick the server into caching sensitive data from another user, then access that cached data themselves?
These aren’t just theoretical. At Advanced Persistent Pentesting, we encounter both frequently in real-world assessments. Their impact can range from site defacement to full-scale user data exposure.
How Caching Vulnerabilities Amplify Risk
These vulnerabilities can turn otherwise minor findings into critical issues. Take Self Cross-Site Scripting (Self-XSS), for example. Normally, this is a informational risk finding: an almost laughable finding that amounts to a user being convinced to attack themselves by including malicious JavaScript within a request.
But combine this with a caching weakness:
- An attacker executes a Self-XSS payload.
- The payload is cached by the server.
- Every subsequent visitor to your website executes the payload.
Suddenly, a minor informational issue Self-XSS becomes Everyone-XSS (coined here today folks), and what was previously informational is now a critical site-wide vulnerability and you’re in trouble.
Other Vulnerabilities That Can Be Amplified
Caching weaknesses can be leveraged to chain or escalate attacks, including:
- Header Injections
- Exploits requiring malformed requests that a browser would be unlikely to send
- Exposure of dynamic content in resource files
- Reflected (and the already mentioned Self) cross-site scripting
- HTTP request smuggling
- Bypassing of cross-site request forgery (CSRF) protections
- Open redirects
In short, caching vulnerabilities don’t exist in isolation – they amplify the impact of other web vulnerabilities, sometimes turning low-severity findings into critical, site-wide risks.
A final thought for pentesters:
If you’re sending requests through tools like Burp Repeater or Intruder, watch for subtle cache behaviour. Missing an x-cache: hit could mean your payloads aren’t landing, and you’re missing a huge piece of the pentesting puzzle. Cache-busting techniques aren’t optional—they’re essential..
A final thought for customers:
Ensure your pentesting provider tests for caching vulnerabilities (If you are our customer, then we have you covered). If such issues are found, check that all other findings are evaluated in the context of potential chaining or amplification to ensure they are correctly rated. Ignoring caching vulnerabilities can leave your organisation exposed in ways that may not be obvious during standard testing.
Conclusion:
Caching is a performance tool—but misconfigured caching can be a security amplifier. From Self-XSS to request smuggling, these vulnerabilities can escalate minor issues into critical risks. Awareness, testing, and proper cache configuration are key to keeping both users and applications safe.