React2Shell: What Broke, What’s Fixed, What to Do Now

If you ship React at scale, React2Shell isn’t “one more advisory”—it’s a pre-auth remote code execution in React Server Components (RSC) with real-world exploitation and a crisp set of fixes. The difference between patched and proven-safe is where many teams stumble. Let’s close that gap today.

On December 3, 2025, the React team disclosed CVE‑2025‑55182, a CVSS 10.0 RCE in RSC packages. It affects common defaults and can be triggered by a single malicious HTTP request to server function endpoints. Follow‑on advisories on December 11 added a DoS (CVE‑2025‑55184, plus CVE‑2025‑67779) and a source‑code exposure bug (CVE‑2025‑55183), with framework patches shipping fast.

What just happened—and why it matters

The vulnerability sits in how RSC decodes payloads sent to server function endpoints. In affected versions, crafted input can get interpreted as trusted structures on the server, leading to code execution under your Node.js runtime. That’s pre‑auth, default‑config impact—exactly the kind of failure attackers love. Microsoft has observed active exploitation attempts and post‑exploitation behaviors ranging from cryptominers to persistent RATs.

Timeline check: disclosure on December 3, 2025; exploitation observed as early as December 5; additional issues disclosed December 11 with coordinated framework fixes. If you paused releases for the holidays, assume your internet‑facing RSC apps were probed.

Am I affected by React2Shell?

You’re affected if your app supports React Server Components and uses any of these versions: 19.0, 19.1.0, 19.1.1, or 19.2.0 of react-server-dom-webpack, react-server-dom-parcel, or react-server-dom-turbopack. Many frameworks pull these in transitively, so “we didn’t install them directly” isn’t a safe answer.

React shipped fixes in releases 19.0.1, 19.1.2, and 19.2.1. If you’re on an affected line, you must update—there’s no safe workaround that neutralizes RCE.

Which frameworks need action?

Next.js apps using the App Router with RSC are in scope. The Next.js team issued a December 11 security update with precise “fixed in” versions per line (for example, 14.2.35 on 14.x, 15.0.7 on 15.0.x, 15.1.11 on 15.1.x, 15.2.8 on 15.2.x, 15.3.8 on 15.3.x, 15.4.10 on 15.4.x, 15.5.9 on 15.5.x, and 16.0.10 on 16.0.x), plus a canary bump. They also published npx fix-react2shell-next to deterministically land known‑good versions.

Other ecosystems called out by the React team include React Router’s unstable RSC APIs, Waku, Parcel RSC, and Vite’s RSC plugin—each with their own update guidance. Don’t mix “front-end only” mental models with RSC; your server is in play.

FAQ: A few quick realities

“We don’t expose server functions—are we safe?”

Maybe, but not automatically. The React advisory notes that even if you don’t explicitly add server functions, your app can still be vulnerable if it supports RSC and the vulnerable packages are present. Verify versions, don’t assume.

“We upgraded the framework; do we also need to bump React?”

For Next.js, upgrading to a patched framework version is the priority because Next can bundle compatible React internals. Still, confirm your lockfile resolves to fixed React RSC packages or that your framework update pulled them in. Then prove in production (not just dev) that the patched code shipped.

“Any evidence attackers are actually using this?”

Yes. Microsoft reported observed exploitation attempts starting December 5, including post‑exploitation persistence and lateral movement patterns typical of web‑RCE campaigns. Assume opportunistic scanning and harden accordingly.

React2Shell response sprint: a 72‑hour plan

Here’s the thing: response is about sequence and proof, not panic. Below is a tight three‑day sprint we’ve run with clients to patch, verify, and watch for aftershocks.

Hour 0–12: Inventory and freeze risky changes

1) Identify where RSC is enabled. Search your repos and containers for the packages listed above. In Node projects: npm ls react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack next | cat. In images: docker run --rm yourimage sh -lc "cat package-lock.json || cat pnpm-lock.yaml || cat yarn.lock".

2) Pause deploys that widen blast radius (feature toggles, infra drift) but keep emergency change windows open. RCE beats aesthetics; treat this like a production outage.

3) Triage external exposure. Prioritize internet‑facing and high‑privilege workloads. If you operate WAFs, add temporary deny rules for suspicious RSC payload patterns while you patch. Microsoft and major vendors have shared baseline rules; use them, but don’t rely on them as the fix.

Hour 12–36: Patch fast, then cut a proving build

4) Patch frameworks and RSC packages to known‑good versions. For Next.js, use the security table and bump within your major line (e.g., 15.3.x to 15.3.8) or apply the recommended 14.2.35 if you’re on 13.3+ moving to 14.x. Consider npx fix-react2shell-next to script the exact versions.

5) Lock it in. Regenerate lockfiles, clear caches, and pin

• NPM: npm ci in CI/CD to enforce lockfile fidelity.
• PNPM/Yarn: ensure immutable installs (--frozen-lockfile or --immutable).
• Containers: rebuild base images so patching isn’t left to a later layer.

6) Cut a proving build and deploy to a small production slice (e.g., 5–10%). Watch error rates and performance. RSC version skews can surface as subtle hydration mismatches; better to catch them on a canary than at full traffic.

Hour 36–72: Verify the fix landed and hunt for residue

7) Verify in prod, not just in the repo. Grep live containers: node -p "require('react-server-dom-webpack/package.json').version" and confirm patched versions. If you can’t shell into containers, export SBOMs and diff them between builds.

8) Run an explicit regression probe on your RSC endpoints. Reproduce a benign request that should succeed; then check that known exploit payloads are blocked by patched code or WAF (use safe, non‑executing payloads from vendor guidance). Document the results for audit.

9) Threat hunt for post‑exploitation. Look for odd shells, new local users, reverse‑tunnel binaries, or miners. Rotate tokens that may have been exfiltrated from environment variables. Microsoft’s reporting includes TTPs and targets like cloud metadata endpoints—hunt there first.

The exact versions to aim for

React RSC packages fixed: 19.0.1, 19.1.2, 19.2.1. If you’re on any of 19.0, 19.1.0, 19.1.1, or 19.2.0, update immediately.

Next.js fixed lines: 14.2.35 (for 13.3–14.x users), 15.0.7, 15.1.11, 15.2.8, 15.3.8, 15.4.10, 15.5.9, and 16.0.10, with canaries 15.6.0‑canary.60 and 16.1.0‑canary.19. Use the official table to match your branch.

A minimal “prove‑you‑patched” checklist

This is the part auditors and incident responders will ask for. Make it easy on future you.

• Evidence of version bumps: PRs that show framework and RSC package updates, plus lockfile diffs.
• Build provenance: artifact digest(s) and SBOM for the patched release.
• Runtime verification: commands or SBOM scans from live containers confirming patched versions.
• Traffic check: canary rollout screenshots or logs showing healthy error rates post‑patch.
• Hunt notes: a short log of detections queried and findings (even “none found”).

Edge cases and gotchas we’ve seen

Monorepos and hoisting can hide stale copies. Don’t trust a single root lockfile; verify at the package boundary that ships to prod. If you use workspaces, run install in each deployable unit and inspect its lockfile or SBOM.

React Native in monorepos: RN isn’t using react-dom, but if you installed RSC packages for server‑like flows (or share deps across workspaces), you still need to update those specific packages without necessarily bumping React itself. The React team documented RN nuances—follow their guidance to avoid version mismatch errors.

Canary pitfalls: some orgs adopted canary releases during the scramble. That’s fine as a bridge, but move to a stable, patched line once tests pass. Keep a record of exactly which canary you shipped.

Containers and base images: if your Node runtime or package manager comes from a base image, rebuild from scratch. “npm update” in a later layer isn’t enough if CI pulled an old cache.

WAF band‑aids: useful, not sufficient. They can blunt mass scanning while you roll patches, but RCE defenses belong in code.

Why React2Shell wasn’t “just another CVE”

Pre‑auth + default configs + popular frameworks is the worst‑case trio. RSC shipped exactly to make modern data‑heavy UX sane, and it’s good tech. But when the server accepts client‑serializable structures, the validator must be bulletproof. This incident is a reminder to treat serialization boundaries as untrusted, even when coming from framework glue code.

There’s a silver lining: the coordinated patch cadence was quick, and the framework owners leaned in with deterministic tooling (like npx fix-react2shell-next) and precise version matrices. That minimized ambiguity for upgrade paths.

Hardening for 2026: make this routine, not chaos

Let’s get practical about preventing the next scramble.

• Adopt dependency ownership. For each production app, name an owner for framework and RSC upgrades. Make “who bumps Next and React” explicit.
• Automate with Renovate/Dependabot, but gate by impact. Security bumps auto‑merge to canary with alerts; feature bumps wait for human review.
• Generate SBOMs on every build and archive them. Provenance + SBOM is your time machine for “what was actually running?”
• Enforce immutable installs (npm ci, --frozen-lockfile) and fail builds when lockfiles drift.
• Practice “prove‑it” drills quarterly: pick a CVE, run the 72‑hour sprint, and capture artifacts. Muscle memory beats slides.
• Codify an emergency freeze policy that still permits security changes. Holiday freezes should never block a CVSS 10.0 patch.

Realistic scenarios you might face

Your head of product asks to unfreeze for a promo banner, but you’re mid‑patch. Push back. Show the risk model, the version you’re targeting, and the canary plan. Five hours later you’ll be live and safer.

Your SRE team finds outbound connections to an unfamiliar tunnel domain from a Node container. You rotate tokens, cut network egress, and rebuild images from patched base layers. That’s not paranoia—that’s hygiene in a world where RCE payloads often pivot to cloud credentials.

What to do next

Use this checklist today:

• Check your versions against the React and Next.js advisories and patch to the exact fixed lines.
• Prove the patch in production via SBOM or runtime version checks.
• Hunt for exploitation residue (new users, miners, odd tunnels) and rotate high‑value secrets.
• Automate dependency tracking and create a standing emergency change policy.

Further guidance and help

If you want an hour‑by‑hour playbook, our field guide in React2Shell: Your 72‑Hour Patch‑and‑Prove Plan breaks down sprints, verification artifacts, and team roles. For teams still catching up, see Patch, Prove, and Stay Patched Now for how to keep fixes sticky after the first wave. And if you need a quick read on CVE specifics, we keep a running brief at CVE‑2025‑55182: Patch, Verify, Prevent.

If your organization prefers a partner to run the sprint with you, our security engineering services team can help you cut a clean proving build, wire up SBOMs, and stand up a WAF safety net. Reach out via Bybowu contacts and we’ll scope a focused engagement around your stack.

Bottom line

React2Shell isn’t a theoretical bug; it touched defaults and saw exploitation attempts within days. The fixes are clear. Your job is to land them, verify them, and institutionalize a cadence so the next CVE is Tuesday work, not a fire drill. Patch, prove, and move on.