From False Positive to Hall of Fame: Exploiting Web Cache Poisoning in 4 Hours 🚀🐛

LinkedIn:- https://www.linkedin.com/in/vansh-rathore-cybersecurity?utm_source=share_via&utm_content=profile&utm_medium=member_android

Juggling bug bounty hunting with my 3rd-year CSE coursework means I have to make every hunting session count. I've always believed that relying solely on automated scanners builds a false sense of security — the real bugs are found when you step away from the automated tools and manually poke at the business logic.

Recently, that hands-on approach paid off massively. I discovered a Web Cache Poisoning vulnerability via Cache Entanglement on Shout Me Crunch, leading to an incredibly fast 4-hour resolution and a spot on their Security Hall of Fame! 🏆

Here is the full breakdown of how I approached the target, fell into a classic testing trap, bypassed a WAF, and secured the proof of concept.

🤔 What is Web Cache Poisoning?

Before diving into the exploit, let's establish some groundwork. Web caches exist to speed up websites by saving a copy of a server's response and serving it to other users requesting the same resource. To identify if two users are asking for the same thing, the cache uses a "Cache Key" (usually the URL and the Host header).

Web Cache Poisoning happens when an application processes input that is not included in the cache key (an "unkeyed" parameter). An attacker can send a crafted request to force the server to generate a malicious response. Because the cache ignores the malicious parameter when saving the file, it serves that poisoned response to normal users visiting the clean URL.

🎯 The Target & Initial Discovery

I was testing [www.shoutmecrunch.com], a content platform for bloggers and marketers. During my recon, I noticed that the site utilized WP-Super-Cache at the origin server, heavily shielded by Cloudflare's Web Application Firewall (WAF) at the edge.

I started fuzzing parameters and found that the content parameter was reflecting directly in the DOM.

Initially, an automated test or a quick glance might flag this as Reflected XSS. However, because of the caching layers, I suspected something much more impactful.

🪤 The Trap: Hitting the WAF

My first instinct was to go for the kill — injecting a classic XSS payload to prove maximum impact. I fired up Burp Suite Repeater and sent:

HTTP

GET /?1uzvno4p0w=1&content="><script>alert(document.domain)</script> HTTP/1.1
Host: xxxxxx

GET /?1uzvno4p0w=1&content="><script>alert(document.domain)</script> HTTP/1.1
Host: xxxxxx

(Note: I always use a cache-buster parameter like ?1uzvno4p0w=1 to ensure I never accidentally poison the live site for real users).

The Result? A big, fat Cloudflare Anti-Bot challenge page: <title>One moment, please...</title>.

The WAF caught the <script> tags immediately. Because Cloudflare intercepted the request before it reached the WordPress backend, the payload never reached WP-Super-Cache. My payload wasn't cached, and my browser showed nothing.

A lot of hunters might see the WAF block and move on. But a WAF blocking an XSS payload doesn't mean the caching vulnerability is fixed — it just means you need to pivot.

🕵️‍♂️ The Exploit: Proving Cache Entanglement

I didn't need to execute JavaScript to prove the cache was broken; I just needed to prove I could manipulate the cached DOM for other users. I switched my strategy to Content Spoofing/Cache Defacement.

I needed a payload that Cloudflare would see as benign, but the backend would still cache. I also needed a brand new cache-buster so I wasn't testing against the stale cache from my previous attempts.

Step 1: Poisoning the Cache

I sent the following request using a simple, tag-less string to bypass the WAF:

HTTP

GET /?xyz=99&content=CACHE_POISONED_BY_VANSH_RATHORE HTTP/1.1
Host: xxxx
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:151.0) Gecko/20100101 Firefox/151.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Connection: close

GET /?xyz=99&content=CACHE_POISONED_BY_VANSH_RATHORE HTTP/1.1
Host: xxxx
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:151.0) Gecko/20100101 Firefox/151.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Connection: close

I checked the HTTP response in Burp. Cloudflare let it through (200 OK), and right near the bottom, nestled inside a JSON object for Jetpack analytics, was my payload! I checked the WP-Super-Cache timestamp at the bottom of the HTML, and it confirmed a fresh cache was generated.

Step 2: The Execution (The Clean Request)

This is the most crucial step. To prove Web Cache Poisoning, you must show that a victim receives the payload without having the malicious parameter in their URL.

I opened a completely fresh, Incognito browser window and navigated to the clean URL: [https://www.shoutmecrunch.com/?xyz=99]

I right-clicked, viewed the page source, and searched for VANSH_RATHORE.

Boom. 💥

The string was sitting right there in the source code of the clean URL. The WP-Super-Cache ignored the utm_content parameter when creating the cache key, entangling my poisoned response with the clean URL path.

☢️ The Impact

By exploiting this, an attacker could silently manipulate high-traffic pages (like the homepage). While Cloudflare blocked obvious <script> tags, an attacker could inject arbitrary text to launch targeted phishing campaigns, render fake login portals, or cause severe reputational damage. Furthermore, if a WAF bypass was ever discovered, this would immediately escalate to unauthenticated, zero-click Stored XSS for all site visitors.

🤝 The Best VDP Experience

I wrote up a detailed report, packed with my Burp raw requests, steps to reproduce, and screenshots of the source code, and fired it off to their security team, explicitly noting that I stopped testing to respect their Safe Harbor policy.

The response from Dr. Toufiq Hassan Shawon and the Shout Me Crunch team was absolutely incredible.

Triage & Patch: Within exactly 4 hours of my email, they acknowledged the report, swapped their caching plugin, hardened their .htaccess configurations, and asked me to re-test.
Verification: I re-tested the endpoints and confirmed the vulnerability was completely remediated.
Recognition: Shortly after, I was officially listed on their Security Hall of Fame!

It is incredibly refreshing to work with organizations that prioritize security, communicate transparently, and collaborate so seamlessly with researchers.

Takeaway: Never let an automated scanner do your thinking for you, always isolate your blast radius with cache-busters, and remember that a WAF block is often just a puzzle waiting to be solved. Happy hunting! 💻🛡️

Contents