React2Shell: The Critical RCE Vulnerability Every Next.js Developer Must Address Now

Published: 14 hours ago (December 9, 2025 at 11:02 AM EST)

4 min read

Source: Dev.to

Overview

A critical remote code execution (RCE) vulnerability—CVE‑2025‑55182 (also tracked as GHSA‑9qr9‑h5gf‑34mp) affects React Server Components (RSC) used by Next.js applications that employ the App Router. The flaw allows an attacker to execute arbitrary JavaScript on the server with a single crafted HTTP request, requiring no authentication. It impacts Next.js versions 15.0.0 through 16.0.6 and several related React packages.

Key points

CVSS score: 10.0 (critical)
Exploits were publicly released on December 4, 2025.
Successful exploitation enables credential theft, cryptomining, reverse shells, and persistent backdoors.

How the Vulnerability Works

React Server Components use the Flight protocol to serialize and deserialize data between server and client. The deserialization logic incorrectly traverses prototype chains when processing specially‑crafted multipart/form‑data payloads. By injecting __proto__, constructor, or prototype references via $‑prefixed strings, an attacker can break object boundaries and run arbitrary code on the server.

Typical attack flow:

Attacker → malicious multipart/form-data POST
          ↓
Next.js server (RSC‑enabled route)
          ↓
Flight protocol deserializes payload
          ↓
Prototype chain traversal → arbitrary code execution
          ↓
Server‑side RCE with application privileges

Even if your app does not explicitly use server functions, the mere presence of the App Router (an app/ directory) enables the vulnerable endpoints.

Affected Packages and Versions

Package	Vulnerable Versions
`react-server-dom-webpack`	19.0.0, 19.1.0, 19.1.1, 19.2.0
`react-server-dom-parcel`	19.0.0, 19.1.0, 19.1.1, 19.2.0
`react-server-dom-turbopack`	19.0.0, 19.1.0, 19.1.1, 19.2.0
Next.js (GHSA‑9qr9‑h5gf‑34mp)	All stable versions 15.0.0 – 16.0.6
Next.js canary	≥ 14.3.0‑canary.77, and ≥ 15.6.0‑canary.58
Other frameworks using RSC	`react-router` (unstable RSC APIs), `waku`, `@parcel/rsc`, `@vitejs/plugin-rsc`, `rwsdk`

Determining Your Current Version

In the browser

// Returns the deployed Next.js version
next.version

From the project files

# package.json
cat package.json | grep '"next"'

# npm lockfile
npm ls next

# yarn
yarn why next

# pnpm
pnpm why next

Vercel dashboards may display a banner for vulnerable deployments, but verify directly.

Patch and Upgrade Matrix

Currently Running	Upgrade To
Next.js 15.0.x	15.0.5
Next.js 15.1.x	15.1.9
Next.js 15.2.x	15.2.6
Next.js 15.3.x	15.3.6
Next.js 15.4.x	15.4.8
Next.js 15.5.x	15.5.7
Next.js 16.0.x	16.0.7
Next.js 14 canaries (≥14.3.0‑canary.77)	Downgrade to 14.2.x stable
Next.js 15 canaries (<15.6.0‑canary.58)	15.6.0‑canary.58 or later

Automated Fix (Vercel)

npx fix-react2shell-next

The tool scans for vulnerable packages and upgrades them automatically.

Manual Upgrade

# Update to a patched version (example)
npm install next@15.3.6   # replace with the appropriate target version

# Refresh lockfile
npm install

# Verify
npm ls next

Commit both package.json and the lockfile to avoid mismatched dependencies.

Deploy the Fixed Version

# Vercel CLI
vercel --prod

# Or via CI/CD
git add package.json package-lock.json
git commit -m "fix: patch React2Shell vulnerability (CVE-2025-55182)"
git push origin main

Immediate Post‑Compromise Actions

If your production app was exposed on December 4, 2025 at 1:00 PM PT (when public exploits appeared), assume environment variables may have been stolen. Rotate secrets in the following priority:

Database credentials
Third‑party API keys (Stripe, SendGrid, AWS, etc.)
OAuth client secrets
JWT signing keys
Internal service authentication tokens

Vercel’s documentation provides a step‑by‑step guide for rotating secrets.

Indicators of Compromise

Log Analysis

Unexpected multipart/form-data POST requests to unknown routes
Malformed or suspicious Content-Type headers
Spikes in 500 errors from RSC routes
Unusual function timeouts (though many exploits complete silently)

Runtime Anomalies

Unknown processes running inside containers
Outbound connections to unfamiliar IPs or domains
DNS queries to 169.254.169.254 (cloud metadata service)
Sudden CPU usage spikes unrelated to traffic

Observed Post‑Exploitation Behaviors

Credential exfiltration (environment variables)
Cryptominer deployment (often masquerading as system services)
Reverse shell establishment
Persistent cron jobs or process respawners

If any of these signs appear, treat the incident as a confirmed breach: isolate affected systems, preserve logs, and activate your incident‑response plan.

Defense‑in‑Depth Measures (Temporary)

Measure	Notes
Web Application Firewall (WAF)	Major providers (AWS WAF, Cloudflare, Fastly, Vercel) have released rules targeting known exploit patterns. WAFs mitigate many attacks but are not a substitute for patching.
Deployment Protection	Enable authentication for preview/non‑production deployments (e.g., Vercel’s Standard Protection). Audit shareable links that bypass protection.
Network Segmentation	Restrict outbound traffic from your serverless functions or containers to only required endpoints.
Runtime Monitoring	Deploy anomaly‑detection tools to flag unusual CPU, memory, or network usage.
Least‑Privilege Secrets	Store credentials in secret managers with short TTLs and rotate regularly.

Summary Checklist

Identify the Next.js version in production.
Upgrade to a patched version according to the matrix above.
Run npx fix-react2shell-next (or perform manual upgrades).
Verify the upgrade with npm ls next.
Deploy the patched code immediately.
Rotate all potentially compromised secrets.
Review logs and runtime metrics for indicators of compromise.
Apply temporary WAF rules and deployment protections while patching.

Staying on a patched version of Next.js and promptly rotating secrets are the most effective ways to mitigate the React2Shell RCE risk.