React2Shell is the kind of bug that rewrites your week. On December 3, 2025, the React team disclosed CVE‑2025‑55182, a pre‑auth remote code execution flaw in React Server Components (RSC) with a maximum CVSS 10.0 rating. Patches landed quickly in React 19, but for real apps the story didn’t end there—Next.js advisories, follow‑on bugs, and active exploitation forced most teams to patch more than once and then prove the fix worked. If you’re running RSC anywhere near production, treat this as an incident, not a memo. (react.dev)
What ‘React2Shell’ changed for React 19 and Next.js
The root issue lives in the RSC “Flight” protocol: affected versions accept attacker‑controlled payloads that deserialize into server‑side execution. React listed the vulnerable packages—react‑server‑dom‑webpack, react‑server‑dom‑parcel, and react‑server‑dom‑turbopack—and shipped fixes in 19.0.1, 19.1.2, and 19.2.1. That’s your baseline. If your dependency tree pulls a vulnerable RSC package, you were exposed whether or not you explicitly enabled Server Actions. (react.dev)
Next.js was impacted downstream. The Dec 3 advisory introduced hardened builds for 15.x and 16.x, plus guidance for canary users and a handy one‑shot tool, npx fix-react2shell-next, to push deterministic version bumps. That specific guidance matters because a lot of teams were on canary for features like Partial Prerendering; the advice was to either update to fixed canaries or drop back to the latest stable 14.x. (nextjs.org)
Then came the second wave. On December 11, Next.js published two additional RSC issues—DoS (CVE‑2025‑55184, later completed under CVE‑2025‑67779) and Source Code Exposure (CVE‑2025‑55183)—and urged another round of updates. These did not re‑open RCE, but they did change the “safe” versions list, which is why some teams patched twice. If you fixed React2Shell early and stopped, you likely need to patch again. (nextjs.org)
Yes, exploitation is happening—assume compromise if you were exposed
Microsoft’s telemetry saw exploitation attempts starting December 5. Most successful hits dropped miners and commodity RATs, but there were also real intrusions with persistence tactics—new users, SSH key tampering, RMM tooling, and cloud metadata theft for pivoting. If your app was internet‑facing and unpatched after disclosure, you should operate on the assumption that secrets may have leaked and hosts may have run untrusted code. (microsoft.com)
That last point is the operational difference between “upgrade a library” and “run an incident.” Don’t just bump a version and call it done. Patch, rotate, and verify.
Am I affected if I don’t use Server Actions?
Probably, if you support React Server Components at all. The vulnerable boundary is any Server Function endpoint, and React’s own write‑up says apps using RSC can be affected even without custom endpoints. If you shipped App Router with RSC features in production, treat yourself as impacted. (react.dev)
Which versions are actually safe today?
Match your line to the fixed builds. On the React side, install 19.0.1, 19.1.2, or 19.2.1 for the RCE. On the Next.js side, the Dec 11 advisory lists the current fixed releases that also cover the DoS and source exposure findings. Highlights:
• For 14.x users on 13.3+ or stable 14.x: go to 14.2.35.
• For 15.x: 15.0.7, 15.1.11, 15.2.8, 15.3.8, 15.4.10, 15.5.9, or 15.6.0‑canary.60.
• For 16.x: 16.0.10 or 16.1.0‑canary.19.
• If you were on [email protected]‑canary.77+, downgrade to stable 14.x. (nextjs.org)
Command‑line reality check: npm ls react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack next. If any line shows a vulnerable version or an unfixed Next.js, update and redeploy now. (react.dev)
Quick triage: how to tell if you were popped
You’re not going to find a single “you were hacked” log line. Look for patterns Microsoft and defenders observed in real attacks:
• Unexpected CPU spikes, especially from Node/Nginx/PM2 processes.
• New system users; ~/.ssh/authorized_keys modified; SSH config changes.
• Dropped RMM tools (MeshAgent) or miners (XMRig).
• Outbound traffic to temporary tunnels (e.g., trycloudflare domains).
• curl/PowerShell grabs of one‑liner payloads; sudden downloads of TruffleHog or Gitleaks.
• Credential access from cloud metadata endpoints (AWS, Azure, GCP). (microsoft.com)
Let’s get practical: a 72‑Hour React2Shell response plan
Hour 0–6: Freeze, patch, redeploy
• Block traffic to known malicious IPs and pause non‑essential deploys.
• Upgrade React packages to fixed RSC versions (19.0.1/19.1.2/19.2.1).
• Upgrade Next.js to your line’s fixed build. If you’re on canary for PPR, choose the fixed canary listed above or drop to stable 14.2.35.
• Redeploy immediately and invalidate cache/CDN where applicable. (react.dev)
Hour 6–24: Validate the fix and hunt
• Confirm the fix with curl tests against Server Function endpoints and a synthetic RSC request if you have one.
• Baseline CPU and memory on the hosts and containers running Node.
• Search logs for anomalous POST requests to RSC endpoints; flag unusual user‑agent strings and bursts of 5xx during exploit windows.
• Grep for indicators: meshagent, xmrig, trycloudflare, cobalt, and recent changes to authorized_keys. (microsoft.com)
Hour 24–48: Rotate, then rotate again
• Rotate cloud credentials, API keys, and database passwords. Prioritize anything your app can reach from the server process (env vars, instance metadata tokens).
• If your app was online and unpatched after December 4, 2025 at 1:00 PM PT, treat the rotation as mandatory, starting with the most sensitive secrets. (nextjs.org)
Hour 48–72: Rebuild trust
• Reimage or rebuild affected hosts and containers if you found persistence.
• Force sign‑out for app users and rotate signing/encryption keys if tokens could be abused.
• Add WAF rules for suspicious RSC patterns; enable rate limiting and tighten firewall sources.
• Document what happened, what you changed, and how you’ll detect it next time.
People also ask: Do I need to rotate secrets if I patched quickly?
If your public app was reachable while running a vulnerable build, rotate. The payload runs server‑side code in your process context; even if you didn’t spot exfiltration, the blast radius includes in‑process secrets and metadata tokens. Teams that patched within hours often skip rotation; don’t. Next.js explicitly advised rotation for unpatched apps beyond the early window. (nextjs.org)
Are Pages Router apps safe?
Pages Router apps aren’t affected by these RSC protocol bugs, per the framework advisories. If you’re hybrid or mid‑migration, verify that no RSC endpoints are exposed and still take the opportunity to bump dependencies. (nextjs.org)
What about managed hosting—wasn’t this mitigated?
Several providers pushed temporary mitigations, but the React team made it clear those aren’t a substitute for upgrading. If you rely on a platform to block a protocol‑level flaw, you’re one config change away from exposure. Upgrade anyway. (react.dev)
Production‑ready checklist: ship the right fixes
Use this as a merge‑request template for your patch PR to avoid “we thought we fixed it” surprises.
• Lock React to a fixed RSC version: 19.0.1, 19.1.2, or 19.2.1 in package.json.
• Lock Next.js to your line’s fixed build and commit package-lock.json/pnpm-lock.yaml.
• Run npx fix-react2shell-next and commit the diff if you’re on Next.js.
• Regenerate server images; don’t in‑place patch a long‑lived host.
• Add a WAF rule that rate‑limits or blocks suspicious RSC paths.
• Confirm no canary versions re‑entered the tree (CI job to fail on canary unless allow‑listed). (nextjs.org)
Version and timeline recap (so your execs stop asking)
• Nov 29, 2025: Researcher report to Meta Bug Bounty.
• Dec 3: React discloses CVE‑2025‑55182; patches in React 19.0.1/19.1.2/19.2.1.
• Dec 3: Next.js advisory issues patched lines for 15.x/16.x and tool npx fix-react2shell-next.
• Dec 5+: Exploitation attempts observed in the wild; miners and RATs most common.
• Dec 11: New DoS and Source Code Exposure bugs disclosed; users told to upgrade again; incomplete DoS fix replaced by CVE‑2025‑67779. (react.dev)
Risk framing: where teams tripped in week one
• Canary debt: Many canary users didn’t realize they’d opted into the affected protocol earlier than stable and hesitated to downgrade. For production, track canary usage like a risk—owned, reviewed, time‑boxed.
• Partial patching: Upgrading React without bumping Next.js (or vice versa) leads to mismatches and a false sense of safety. Patch the stack, not a package.
• No rotation: Secret rotation is boring until your cloud bill spikes. Automate it; don’t debate it.
• Untested rollback: Some teams rolled back builds to “stable before the bug,” accidentally landing on vulnerable versions again.
What to do next (developers)
• Add a CI job that fails any PR that introduces vulnerable RSC or pre‑fix Next.js versions (npm audit + custom semver guard).
• Ship a simple “prove it” endpoint health check that exercises a Server Function and alerts on serializing anomalies.
• Deploy an agentless log pipeline for 7–14 days to a sandbox SIEM and hunt for the IoCs above.
• Replace long‑lived app credentials with short‑lived, scoped tokens (OIDC workload identity, IAM roles) so a leak ages out fast.
What to do next (business & ops leaders)
• Budget time for a second maintenance window to absorb the Dec 11 follow‑up patches; communicate that the first patch was not the last.
• Ask for a one‑page after‑action: exposure window, patched versions, rotation status, and hardening steps.
• Get written confirmation from any vendor running your code (agencies, platform providers) that they upgraded beyond Dec 11 versions.
Want a deeper playbook?
If you’re coordinating multiple teams, use our focused guides to structure the sprint. Start with a React2Shell patch playbook you can run this week, then hand your PM a condensed 7‑day patch‑and‑prove plan. If your stack is heavily Next.js, our Next.js update brief maps the right target versions and common migration snags. You can also see how we approach production upgrades on the services side on what we do.
Edge cases and gotchas
• Monorepos with mixed React Native: The fix targets server‑side RSC packages; don’t blindly bump react/react‑dom in a way that breaks RN. The React post outlines what to pin in RN monorepos. (react.dev)
• Bundler plugins: If you’re using @vitejs/plugin‑rsc, Parcel RSC, or Waku, make sure their RSC dependencies are on patched lines; don’t assume your application’s react/next bumps transitively solved it. (react.dev)
• Containers: Upgrading the app is step one; then rebuild images so your base layers aren’t carrying old packages. Attackers observed by Microsoft hid in container mounts and used bind mounts to dodge monitoring—fresh images help flush that out. (microsoft.com)
FAQ lightning round
“Can I firewall my way out of this and skip the upgrade?”
No. Providers deployed mitigations, but the official guidance is clear: upgrade anyway.
“How do I prove to my auditors we’re safe now?”
Attach the version matrix from this brief, a list of patched repos and environments, rotation evidence (key IDs, last‑rotated timestamps), and a short threat‑hunting report covering the IoCs above. Tie each step to a ticket.
“Is there a single command to fix Next.js?”
Use the vendor‑supplied utility: npx fix-react2shell-next. It checks and bumps to the recommended patched versions for your line, then you redeploy. (nextjs.org)
Zooming out
Here’s the thing: RSC is powerful—and young. Protocol‑level flaws will happen. Your defense is boring discipline: lock versions, avoid long‑lived creds, don’t run unreviewed canaries in production, and practice incident hygiene so “patch, rotate, verify” is muscle memory. Ship the fixes, run the playbooks, and write down what you learned. Your future self will thank you.
