React2Shell (CVE-2025-55182): A Real-World Lesson on Why Incident Response Speed Matters
Zero-day vulnerabilities with a CVSS score of 10 are not theoretical risks, they are production outages waiting to happen. The recent React2Shell vulnerability demonstrated this brutally: a simple payload led to remote code execution (RCE) across thousands of applications using Next.js / React, impacting startups and large enterprises alike. This post walks through how I identified the issue in real time, validated the exploit, and mitigated it across production systems within hours.
So what is this React2Shell???
React2Shell (CVE-2025-55182) allows unauthenticated RCE in vulnerable Next.js / React setups due to unsafe server-side rendering behavior. Exploitation requires no authentication, no complex chaining - just a crafted payload.
- Official site: https://react2shell.com/
PoC used: https://github.com/lachlan2k/React2Shell-CVE-2025-55182-original-poc
Cloudflare impact analysis (excellent breakdown):
https://www.youtube.com/watch?v=7vw445i8gOI
- by ThePrimeTime
Portswigger Detecting R2S: https://portswigger.net/blog/how-to-detect-react2shell-with-burp-suite
This wasn’t just a bug. It was a global fire drill.
How I discovered it
TWITTER or should I call it X, Like many engineers, I was casually scrolling Twitter/X when I noticed chatter around a “new Next.js CVE.” At first glance, it looked like typical security banter noisy, half-confirmed claims. But CVEs around frontend frameworks are rare, and when they show up, they deserve attention.
A SERVER WAS DOWN
One of our subdomains was un-responsive so tried digging deeper into what could’ve happened..
Digging into Nginx Docker logs, I noticed something that immediately felt off:
The frontend upstream was failing—not the backend.
In most architectures, backend services are the usual failure point. Seeing the frontend container crash or hang under malformed requests was a huge red flag.
Log analysis showed something phishy
Reviewing request logs showed:
Broken request paths
Non-standard payloads
Repeated patterns hitting SSR routes
These were not scanners. These were exploit attempts.
This aligned suspiciously well with what I’d just seen online.
Confirming the exploit
Rather than guessing, I moved fast:
Spun up a local dev environment with the same Next.js version
Pulled the original PoC:
https://github.com/lachlan2k/React2Shell-CVE-2025-55182-original-poc/blob/main/01-submitted-poc.jsRan the payload
Result:
➡️ RCE on the first attempt. No tweaking. No edge cases. (OK maybe a lil bit tweaking but you get it)
That moment was sobering. This wasn’t a “theoretical exploit.” This was weaponized, reliable, and already in the wild.
Immediate Mitigation Steps Taken
Once confirmed, there was no room for debate or staged rollouts.
1. Emergency Dependency Upgrades
Identified all projects using vulnerable:
Next.js
React
Upgraded immediately to patched versions
Redeployed all affected services
2. Temporary Compensating Controls
While patching:
Tightened WAF rules - enabled for all subdomains
Increased logging verbosity for anomaly detection
Why Speed Is Everything in times like these?
This incident reinforced a hard truth:
There is no grace period for CVSS 10 vulnerabilities.
By the time a public PoC exists:
Mass scanning is already happening
Bots don’t wait for your change advisory board
“We’ll patch next sprint” equals compromise
