The Reverse Bounty Hunter: Chaining Shodan, Nuclei, and AI for a High-Severity React DoS

1. Dodging the Hype Train

If you were on Infosec Twitter (X) arround December 2025 to January 2026, you know exactly what the timeline looked like. Everyone was losing their minds over a newly discovered Remote Code Execution (RCE) vulnerability in React: CVE-2025–55182.

Every day, hunters were posting screenshots of their bounties. Naturally, I wanted a piece of the action. I fired up my tools, did my recon, and started hunting. But the problem with highly publicized bugs is that they create an incredibly crowded attack surface. The low-hanging fruit was gone within hours, and I was staring down the barrel of inevitable "Duplicate" resolutions.

Then, just a couple of days later, another React CVE dropped: CVE-2025–55184. This one was a Denial of Service (DoS) vulnerability.

There was very little public information about it, and more importantly, nobody was talking about it. Why? Because in the bug bounty world, DoS is almost universally considered "Out of Scope."

But I looked at the lack of competition and made a calculated decision: I'd rather risk getting a "Not Applicable" (N/A) on an uncrowded vulnerability than fight for scraps on an RCE that thousands of other hackers were already scanning for. I decided to pivot and target the DoS.

2. The Recon Pipeline: Hunting IPs, Not Domains

Because information on CVE-2025–55184 was so sparse, I started digging through GitHub. Eventually, I struck gold: I found a repository containing a custom Nuclei template for the bug, alongside a specific Shodan query designed to find vulnerable React Server Components (RSC) stacks.

Instead of targeting a specific company's domains, I decided to cast a massive net across the entire internet.

Here is the exact workflow I used to extract my targets:

1. The Query: I ran the Shodan query http.component:"Next.js" to pull up all matching servers globally.

2. The Extraction: Instead of manually copying IPs, I clicked on "More" in Shodan and used the drop-down menu to isolate just the IP addresses.

3. The Secret Weapon: To actually capture this data, I used a bookmarklet created by Lostsec. If you aren't familiar with it, it's a simple JavaScript bookmarklet that lets you instantly scrape and download a raw list of IPs from a page. In seconds, I had a massive text file of raw targets.

javascript:(function(){var ipElements=document.querySelectorAll('strong');var ips=[];ipElements.forEach(function(e){ips.push(e.innerHTML.replace(/["']/g,''))});var ipsString=ips.join('\n');var a=document.createElement('a');a.href='data:text/plain;charset=utf-8,'+encodeURIComponent(ipsString);a.download='ip.txt';document.body.appendChild(a);a.click();})();

javascript:(function(){var ipElements=document.querySelectorAll('strong');var ips=[];ipElements.forEach(function(e){ips.push(e.innerHTML.replace(/["']/g,''))});var ipsString=ips.join('\n');var a=document.createElement('a');a.href='data:text/plain;charset=utf-8,'+encodeURIComponent(ipsString);a.download='ip.txt';document.body.appendChild(a);a.click();})();

(Create a bookmark on your browser, add the above code as url in the bookmark and save it. just click on the the bookamrk when you are on the IP ist page)

I fed that massive IP list into Nuclei, running the custom template I'd found. After filtering through the noise, I was left with a handful of potentially vulnerable endpoints.

3. Execution: AI-Assisted Safe Verification

Here is where I ran into a massive dilemma. I had vulnerable endpoints, but this was a DoS bug. If I actually executed the payload to prove it worked, I would crash the company's server. Taking down production infrastructure is the fastest way to get permanently banned from a bug bounty platform.

I needed a way to manually verify the bug safely.

I took the Nuclei template, the limited vulnerability details I had, and fed them into an AI (Gemini). I asked: "How can I manually verify this endpoint is vulnerable without actually crashing the server?"

The AI analyzed the React Flight protocol deserializer flaw and gave me a brilliant, non-destructive Proof of Concept (PoC). It gave me this exact curl command:

curl -i -X POST "https://sub.target.com/" \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -H "Next-Action: x" \
     --data-raw '0=["$F1"]&1={"id":"x","bound":null}'

curl -i -X POST "https://sub.target.com/" \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -H "Next-Action: x" \
     --data-raw '0=["$F1"]&1={"id":"x","bound":null}'

Why does this work? The AI explained the logic perfectly. If I sent this request and the server returned a 404 "Action not found", it meant the vulnerability was present. It proved that the server had successfully parsed the complex Flight protocol body and actively attempted to execute the logic inside of it, confirming the vulnerable deserializer was exposed.

If the server was patched or safe, it would reject the request entirely at the front door with a 400 Bad Request or 415 Unsupported Media Type.

(For educational purposes, the actual destructive payload that crashes the server uses a circular reference that looks like this: 0=["$@1"]&1=["$@0"]. But to keep things safe and ethical, I never ran this.)

I ran the safe curl command against my targets. HTTP 404. I had my bugs.

4. The Reverse-Bounty Mapping

At this point, my workflow was completely backward. Usually, you pick a company, find their IPs, and look for bugs. I had the bugs and the IPs, but I had no idea who owned them.

I had to reverse-map my findings. I took my vulnerable IP addresses and started looking up their ASN and SSL certificate data to find the owning organizations. Then, I cross-referenced those companies against HackerOne, Bugcrowd, and independent platforms to see if they had active Bug Bounty or Vulnerability Disclosure Programs (VDPs).

Sure enough, I hit the jackpot. I found that two separate, vulnerable assets on my list belonged to the exact same company, and they had an active VDP.

5. The Payoff: Why VDPs Are Worth Your Time

I carefully wrote up my first report. I explicitly included the safe 404 proof-of-concept and conceptually explained the destructive payload. I made sure the security team knew that I intentionally withheld executing the crash payload to protect their infrastructure.

Triagers love responsible testing. They accepted the first report and triaged it as a High-Severity bug.

Once that was validated, I immediately submitted the report for their second asset. Boom — another High-Severity bug accepted.

Because this was a VDP (Vulnerability Disclosure Program), there was no cash bounty attached to these findings. Some hunters won't even look at VDPs for that reason, but I see it differently. Securing two High-severity bugs drastically spiked my reputation score on the platform.

The real ROI wasn't a cash payout on that specific bug; it was the flood of private program invites that followed. By ignoring the hype, taking a calculated risk on a DoS CVE, and testing safely, I unlocked access to uncrowded, highly lucrative private attack surfaces.

The takeaway? Don't be afraid to hunt where others won't. Grab your IPs, use AI to build safe PoCs, and always check the VDPs.

I hope you like this writeup and learned something new from it, if you did please clap this post. your feedback is appreciated.

My socials:

linkedin — https://www.linkedin.com/in/hamja-bohra-012952156/

instagram — https://www.instagram.com/hamzaburhanuddin2

BYE !!!