# 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/](https://react2shell.com/)
    

PoC used: [https://github.com/lachlan2k/React2Shell-CVE-2025-55182-original-poc](https://github.com/lachlan2k/React2Shell-CVE-2025-55182-original-poc)

Cloudflare impact analysis (excellent breakdown):  
[https://www.youtube.com/watch?v=7vw445i8gOI](https://www.youtube.com/watch?v=7vw445i8gOI)

* by *ThePrimeTime*
    

Portswigger Detecting R2S: [https://portswigger.net/blog/how-to-detect-react2shell-with-burp-suite](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:

1. Spun up a **local dev environment** with the same Next.js version
    
2. Pulled the original PoC:  
    [https://github.com/lachlan2k/React2Shell-CVE-2025-55182-original-poc/blob/main/01-submitted-poc.js](https://github.com/lachlan2k/React2Shell-CVE-2025-55182-original-poc/blob/main/01-submitted-poc.js)
    
3. Ran 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