Automate Cache Poisoning Vulnerability - Nuclei

Inspired by James Kettle's research on Web Cache Poisoning in 2018


I started my regular night, as usual, checking my inbox, Twitter, and HackerOne, soon after I received a message on discord from my friend Khaled, who asked if we could create a template for Nuclei to detect web cache poisoning, so we started to check if it's even possible, turned out It's a perfect idea. If cache poisoning is a new term for you, I suggest this article by James Kettle.


We started to tear down the detection process into small pieces. Khaled came out with common unkeyed inputs headers which were extracted from previously disclosed reports and write-ups.

Unkeyed Inputs

It's known that triggering cache poisoning requires two requests, one of which will cause the server to cache our poisoned response, and the second request will retrieve our poisoned response. Based on this behavior, we built our template.

Creating Template

Putting it all together, we came out with the following Nuclei-Template.
id: cache-poisoning
name: Cache Poisoning
author: melbadry9 & xelkomy
severity: low
- raw:
- |
GET /?mel=9 HTTP/1.1
- |
GET /?mel=9 HTTP/1.1
req-condition: true
- type: dsl
- 'contains(body_2, "") == true'
You can see that we used mel=9 as cache-buster so we don't end up poisoning everyone in case of vulnerable subdomain.

Testing Template

At this point, we have created a theoretical template that has to be tested, so we used PortSwigger Labs to test our template, specifically this lab.
Testing Template on Vulnerable Lab
After testing, our template worked and detected cache poisoning in the vulnerable lab.


I started collecting my targets which include public bug bounty programs and private programs, using this tool. By the end of this process, I ended with a list containing 4957145 subdomains. Then I fired my VPS and started Nuclei, and went to sleep.
After I woke up, I checked the scanning output file. To my surprise, scanning generated a few hits, and I had to determine which header was causing cache poisoning and then check for possible exploitation scenarios.

Success Case

After scanning generated, some hits turned out that only one of them is exploitable and worth reporting. I reported it to the private program, launched in 2016, and led to a $1500 bounty.

Vulnerability Report




  • Stored XSS, which leads to stealing login credentials
  • Web defacement and DDoS attack