The React2Shell vulnerability is now actively exploited, and default configurations are at risk. If you run React Server Components (RSC) or Next.js App Router in production, you need a concise, verifiable plan to patch, prove, and hunt within 72 hours. This guide focuses on the React2Shell vulnerability (CVE‑2025‑55182) and its downstream impact on Next.js so teams can move fast without breaking production. (microsoft.com)
What actually happened (and when)
On November 29, 2025, a researcher reported an unauthenticated remote code execution flaw in React’s server runtime. The React team disclosed it publicly on December 3, 2025, as CVE‑2025‑55182 and shipped fixed packages the same day: react-server-dom-* 19.0.1, 19.1.2, and 19.2.1. (react.dev)
Next.js published a downstream advisory (CVE‑2025‑66478) with patched framework versions across supported release lines (15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7) and tooling to automate upgrades. (nextjs.org)
Then, on December 11, additional React advisories landed for a denial‑of‑service chain and a source code exposure issue, followed by a complete DoS fix. If you patched in early December, you likely had to patch again: React 19.0.3, 19.1.4, and 19.2.3 address the full DoS scope; Next.js correspondingly pushed newer security releases. (react.dev)
By December 5, Microsoft detected exploitation attempts, and by mid‑December reported real compromises and common payloads (RATs, cryptominers) across Linux and Windows fleets. That same assessment emphasized how little friction is required for attackers: this is pre‑auth, default‑config vulnerable RCE with reliable public exploits. (microsoft.com)
Who’s actually at risk?
React: vulnerable when your project includes any of react-server-dom-webpack, react-server-dom-parcel, or react-server-dom-turbopack at versions 19.0, 19.1.0, 19.1.1, or 19.2.0. Fixed releases are 19.0.1, 19.1.2, and 19.2.1—and subsequent DoS fixes as described above. (react.dev)
Next.js: applications using the App Router with RSC are affected across 15.x and 16.x (plus specific 14.3 canaries). Patches exist per minor line (for example 15.0.5 and 16.0.7 initially, then later security bumps). Pages Router apps and Edge Runtime are not affected by the RCE. (nextjs.org)
Other frameworks/plugins that embed RSC—React Router’s RSC preview, Waku, Parcel RSC, and Vite’s RSC plugin—were flagged by the React team. If you ship RSC via any meta‑framework or bundler plugin, assume exposure until verified. (react.dev)
How attackers are exploiting React2Shell right now
Microsoft reports pre‑auth RCE via a crafted HTTP request to Server Function endpoints, followed by commodity and custom payloads (for example, XMRig miners, VShell/EtherRAT), persistence (new users, SSH key tampering), lateral movement via stolen cloud tokens (IMDS queries), and downloads proxied through temporary Cloudflare tunnel endpoints. That pattern has shown up on both Linux and Windows hosts. (microsoft.com)
Put plainly: if your app was internet‑facing, unpatched during the early December window, and handled RSC traffic, treat it as potentially compromised and rotate secrets as part of the response. Next.js says so directly; React coordinated temporary WAF mitigations, but they’re not a substitute for updating packages. (nextjs.org)
React2Shell vulnerability: a 72‑hour containment and recovery plan
Here’s a pragmatic plan I’ve used with teams this month. Adjust the order if you discover active compromise—but don’t skip validation steps.
0–6 hours: Patch, redeploy, rotate the crown jewels
1) Freeze non‑security deploys and create a change window. If you can, temporarily reduce traffic (maintenance mode or partial brownout) to shrink blast radius during redeploys.
2) Identify exposure: enumerate services that accept RSC traffic. Grep for react-server-dom-* in package-lock.json and list Next.js apps running App Router. Prioritize internet‑facing projects.
3) Patch React and your framework. For React, move to 19.0.1/19.1.2/19.2.1 minimum for the RCE, then to the latest 19.0.3/19.1.4/19.2.3 for the complete DoS fix. For Next.js, install the patched version for your minor line (e.g., 15.0.5 → 15.0.7+, 16.0.7 → 16.0.10+). If you’re on canaries for features like PPR, use the fixed canaries listed in the advisory. (react.dev)
4) Use the maintainer‑provided fixer. Run npx fix-react2shell-next to perform deterministic bumps on impacted Next.js apps. It won’t replace security review, but it accelerates safe version selection. (nextjs.org)
5) Redeploy and invalidate caches. Purge CDN edges and roll a fast smoke test that exercises RSC Server Functions.
6) Rotate secrets. If your app was online and unpatched after December 4, rotate critical tokens (DB, OAuth, payment gateways, AI providers, cloud credentials), then the rest on a schedule. (nextjs.org)
7) Add temporary WAF rules. If you’re on a managed platform, enable their React2Shell ruleset; otherwise, block known exploit patterns at the edge while you patch. Remember: mitigations help buy time; they don’t fix the bug. (react.dev)
6–24 hours: Prove you’re actually safe
8) Hunt indicators of compromise on all patched services during the exposure window. Microsoft highlights common post‑exploit behavior: process spawns for miners, unexpected user creation, SSH key changes, IMDS scraping, and downloads from ephemeral Cloudflare tunnel domains. Query logs and EDR accordingly. (microsoft.com)
9) Review server and build images for persistence. Check crontab, systemd units, authorized_keys, user accounts, Docker bind mounts, and startup scripts for surprises. Microsoft explicitly calls out bind‑mount based hiding; look for mounts masking paths where agents or miners usually sit. (microsoft.com)
10) Rebaseline environment variables and CI/CD secrets. Compare current values with IaC or secret manager history and rotate anything touched by a service that processed RSC traffic during the vulnerable period.
11) Add runtime guards. If your framework allows, force authentication on Server Function endpoints or segment them behind internal gateways. Pre‑RCE sanitization doesn’t remove the need to patch, but it reduces the blast zone of future bugs.
24–72 hours: Prevent regression and raise the bar
12) Make the patches sticky. Pin patched versions in package.json ranges, add npm audit/pnpm audit to CI, and alert when RSC packages drift.
13) Instrument deep health checks. Build a canary that exercises at least one Server Function and validates expected behavior and response times. DoS regressions should trip alarms quickly. (react.dev)
14) Review your App Router boundaries. If you adopted RSC widely, separate critical surfaces (checkout, identity) from RSC‑heavy pages so future server‑runtime bugs don’t take down everything at once.
15) Rehearse key rotations quarterly. The teams that felt calm this week had playbooks and pre‑baked automations. Write the scripts while the context is fresh.
Data you can take to a change board
• CVE: 2025‑55182 (CVSS 10.0) in React Server Components; public disclosure December 3, 2025; fixed React packages 19.0.1, 19.1.2, 19.2.1. (react.dev)
• Next.js downstream CVE‑2025‑66478 with patches per minor line (15.0.5 through 16.0.7), fixer utility, and guidance to rotate secrets if unpatched after December 4, 2025 at 1:00 PM PT. (nextjs.org)
• Additional React advisories on December 11 for DoS and source code exposure; complete DoS fix in 19.0.3/19.1.4/19.2.3; Next.js issued later December security updates aligned to those. (react.dev)
• Active exploitation observed from December 5 onward with common payloads and persistence behaviors documented by Microsoft. (microsoft.com)
People also ask
Does React 18 need patching for React2Shell?
React 18 did not ship RSC as a stable feature. The React advisory scopes vulnerable packages to specific 19.x versions (react‑server‑dom‑webpack/parcel/turbopack). If you aren’t using those packages, this CVE doesn’t apply. (react.dev)
Are Next.js Pages Router apps affected?
No for the RCE. The Next.js advisory clarifies Pages Router apps and the Edge Runtime are not in scope of CVE‑2025‑66478. Still apply later December updates for related fixes as recommended. (nextjs.org)
We run behind a VPN. Are we safe?
Reducing exposure helps, but the exploit is pre‑auth and trivial once reachable. Treat any reachable Server Function endpoint as potentially exploitable until you verify patched packages and redeploy.
Let’s get practical: a fast verification checklist
Run this in each affected repo:
- Search for
react-server-dom-packages and confirm patched versions (≥ 19.0.1/19.1.2/19.2.1; then ≥ 19.0.3/19.1.4/19.2.3 for the full DoS fix). (react.dev) - Confirm Next.js version is one of the patched lines for your minor (e.g., 15.0.5+ initially; follow the December 11 security post for later bumps). (nextjs.org)
- Rebuild and redeploy; purge CDN; run an RSC smoke test.
- Rotate secrets if you were exposed after December 4, 2025. (nextjs.org)
- Hunt for IoCs (unexpected users, SSH key changes, miner processes, IMDS requests, downloads from temporary Cloudflare tunnel endpoints). (microsoft.com)
Risks, trade‑offs, and edge cases
• Canary releases: Some teams rely on canary builds to unlock PPR and other features. Next.js published fixed canaries; upgrade to the specific canary versions called out in the advisory rather than jumping blindly to latest. (nextjs.org)
• Third‑party code paths: If your RSC layer calls out to internal services, audit those for credential leakage and IMDS exposure. Microsoft saw actors pivot via cloud tokens and secret discovery tools after initial access. (microsoft.com)
• False sense of safety from WAFs: React coordinated temporary mitigations with hosts, but the fix is to update. Don’t stop at an edge rule. (react.dev)
• Regression risk: December 11’s DoS follow‑ups are a reminder that early patches often evolve. Make verification repeatable and lean on canary deployments and synthetic checks to avoid breaking prod. (react.dev)
What to do next (developers)
- Finish patching React and Next.js to the current recommended versions and pin them.
- Add an automated “RSC smoke” E2E test to CI/CD and run it on every deploy.
- Write a one‑page runbook: how to rotate secrets, where to look for IoCs, who signs the change ticket.
- Schedule a 30‑minute tabletop on Monday to walk the on‑call through the playbook.
What to do next (engineering leaders and product owners)
- Approve a short maintenance window to complete patching and secret rotation across all services with RSC traffic.
- Ask for a post‑incident memo that answers: what was exposed, how long, what evidence we collected, and what we changed to prevent a repeat.
- Fund hardening work: authentication in front of Server Functions, secret rotation automation, and dependency drift alerts.
Need a partner?
If you want a second set of hands to get this over the line, our team can help with emergency patching, compromise assessments, and post‑fix load testing. Explore our secure web application assessment services, see relevant case studies in our portfolio, or reach out via contacts for a rapid response engagement.
For deeper playbooks on safe patching windows and proof strategies, see our recent pieces: Next.js Security Update: Patch, Prove, Repeat and React2Shell Aftershocks: Patch, Prove, Don’t Break Prod. If you also manage Node.js fleets, our Node.js Patch & Prove guide walks through a similar 48–72 hour rhythm.
Zooming out
Here’s the thing: this class of bug isn’t going away. The more logic we run in server runtimes glued to front‑end frameworks, the more we inherit low‑friction RCE risk from serialization, prototype pollution, and “it works by default” configurations. The answer isn’t to abandon RSC; it’s to build muscle memory around patch cadence, canaries, and crisp incident response. React2Shell won’t be the last time those habits pay off. (react.dev)
