Automate Cache Poisoning Vulnerability - Nuclei

Inspired by James Kettle research on Web Cache Poisoning in 2018


I started my normal night as usual checking my mail, twitter and HackerOne, soon after I received a message on discord from my friend Khaled, who asked if we can 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 very good idea. If cache poisoning is a fairly new term for you I suggest this article by James Kettle.


We started to tear down the detection process to 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 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 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 which has to be tested, so we used PortSwigger Labs to test our template we specifically used this Lab.

Testing Template on Vulnerable Lab

After testing our template, It worked and detected cache poisoning on 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 alive subdomain. Then I fired my VPS and started Nuclei and went to sleep.

After I wake up, I checked scanning output file. To my surprise scanning generated a few hits, which I had to determine which header is causing cache poisoning then check for possible exploitation scenarios.

Success Case

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

Vulnerability Report




  • Stored XSS which leads to steal login credentials

  • Web defacement and DDoS attack