React2Shell: Your 72‑Hour Patch‑and‑Prove Plan

React2Shell—tracked as CVE‑2025‑55182—is a pre‑auth remote code execution flaw in React Server Components with a CVSS of 10.0. It was disclosed on December 3, 2025, and exploitation was observed as early as December 5. If you run React 19 with RSC or frameworks that embed it (notably Next.js App Router), assume exposure until you prove otherwise. This isn’t academic; default setups were vulnerable, PoCs circulated quickly, and several providers pushed temporary WAF mitigations while teams scrambled to upgrade.

You need two outcomes in the next 72 hours: stop the exploit path and generate proof you did. Here’s a clear, battle‑tested plan, with exact versions and practical checks that work in real deployments.

What changed this month—and why it matters

Let’s anchor the timeline. On November 29, 2025, the bug was reported privately. On December 3, 2025, the React team published fixes for the RCE. Within days, threat actors were scanning and dropping miners on unpatched servers. Then on December 11, additional related issues (DoS and source exposure) were disclosed, prompting follow‑up patches. If you only grabbed the first set of updates, you may still be out of date.

Impacted ecosystem highlights:

• React Server Components packages in React 19 (19.0, 19.1.0, 19.1.1, 19.2.0) were vulnerable.
• Frameworks using RSC are affected: Next.js App Router, React Router’s RSC mode, Waku, Parcel RSC, Vite’s RSC plugin, and others that embed the Flight/RSC decoder.
• Next.js Pages Router and Edge Runtime are not in scope for the RCE, but verify your actual runtime and build.

Which versions fix React2Shell?

There are two layers of “fixed” to track—first for the RCE, then for the follow‑on vulnerabilities disclosed December 11.

Minimum to stop the RCE (CVE‑2025‑55182)

React packages: 19.0.1, 19.1.2, or 19.2.1 (or later in those lines). These contain the hardened RSC deserializer that closes the pre‑auth RCE.

Next.js initial patched lines (December 3 advisory): 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, and 16.0.7. If you stopped here, keep reading—there were subsequent updates.

Current recommended patches (adds DoS and source exposure fixes)

React follow‑ups: 19.0.3, 19.1.4, and 19.2.3 are listed as safe after an incomplete DoS fix required a second patch pass. Aim for these or newer.

Next.js security update (December 11): 15.0.7, 15.1.11, 15.2.8, 15.3.8, 15.4.10, 15.5.9, and 16.0.10, plus canaries 15.6.0‑canary.60 and 16.1.0‑canary.19. If you’re on a canary older than those, move to these or back to the latest stable.

Special notes:

• Next.js 13.x and stable 14.x are not affected by the RCE; however, if you used late 14.x canaries (14.3.0‑canary.77+), follow the guidance to downgrade to stable 14.x or upgrade into the patched 15/16 lines.
• Monorepos with React Native: you may need to bump only RSC packages (react‑server‑dom‑webpack / parcel / turbopack) to avoid version skew with react and react‑dom.

15‑minute triage: Are we affected?

Don’t boil the ocean; answer these fast:

1. Does the app use React 19 with RSC? Search your lockfile for react‑server‑dom‑webpack, react‑server‑dom‑parcel, or react‑server‑dom‑turbopack. If present at 19.0, 19.1.0, 19.1.1, or 19.2.0, you’re exposed.
2. Are you on Next.js App Router? If your repo has an app/ directory and you’re on 15.x or 16.x, check the exact version. Compare to the patched lists above.
3. What’s internet‑facing? Inventory public URLs behind reverse proxies, CDNs, serverless functions, containers, and edge nodes. Prioritize anything that processes RSC traffic.
4. Was your app online and unpatched on or after December 4, 2025 at 1:00 PM PT? If yes, put “rotate secrets” on your same‑day checklist.

If you answered “yes” to any exposure, move immediately to remediation. If “no,” collect evidence anyway—auditors and customers will ask.

The React2Shell 72‑hour fix playbook

Here’s a pragmatic sequence we’ve run on client estates this month. Tailor it to your stack, but keep the order.

Hour 0–6: Stop the bleeding

• Patch to the latest recommended versions in your release line. For Next.js, you can run npx fix-react2shell-next to get deterministic bumps in CI.
• Force rebuilds and redeploys. On serverless hosts, a version bump doesn’t take effect until you redeploy the functions. Invalidate CDN and build caches.
• Add temporary WAF rules if available (Cloudflare, Azure, Google Cloud, etc.). Treat these as shields, not substitutes for patching.
• Disable unnecessary Server Actions/Functions endpoints if you expose any by convention. Fewer attack surfaces, fewer surprises.

Hour 6–18: Verify and hunt

• Prove versions. Capture CI logs showing installed versions, plus npm ls react-server-dom-webpack and npm ls next outputs per service.
• Review logs for RSC endpoint anomalies starting December 3. Look for unusual POSTs with malformed payloads, spikes in 5xx, or sudden CPU thrash on Node processes.
• Scan assets. Use a software bill of materials (SBOM) or dependency scanner to ensure no transitive RSC artifact is stuck in an internal cache or private registry.
• Rotate secrets if you were online and unpatched after December 4, 2025 1:00 PM PT—start with cloud keys, database credentials, CI tokens, and any server‑side tokens referenced by RSC handlers.

Hour 18–36: Close gaps and regressions

• Pin versions with package manager “overrides” or “resolutions” so future installs don’t pull vulnerable ranges.
• Rebuild base images. If you bake node_modules into container images, update the base and clear your artifact repository’s cached layers.
• Retest production. Synthetic checks against known RSC paths help confirm that patched code is live in front of load balancers and CDNs.

Hour 36–72: Prove and communicate

• Assemble an evidence bundle: before/after lockfile excerpts, CI output, version screenshots, redeploy IDs, scanner reports, and a list of rotated secrets with timestamps.
• Write a one‑pager for leadership: business impact, what changed since Dec 3 and Dec 11, current risk posture, and owner sign‑off.
• Create a follow‑through ticket to replace temporary WAF rules once the entire estate is proven patched.

Serverless, containers, and other gotchas

Here’s the thing: most teams “patch” and still serve old code for hours. Three common traps:

Serverless hosts (e.g., Vercel, Netlify, Cloudflare): dependency bumps require a fresh build and deployment to rehydrate functions. Ensure the lockfile is committed and the build step isn’t pruning overrides. Confirm the deployed function version by checking the provider’s deployment dashboard.

Containers: rebuild base images rather than npm install inside running pods. Clear your private registry cache. Rolling updates should drain old pods and warm new ones—watch for sticky sessions pinning traffic to unpatched instances.

CDNs and edge caches: flush route caches for RSC endpoints after deploy. Some providers cache 500 responses aggressively; you may think you’re fixed while the edge keeps serving stale results.

Proving you’re safe: a simple checklist

Use this as your auditor‑friendly proof pack. It’s short by design.

• Dependency truth: show react-server-dom-* at 19.0.3/19.1.4/19.2.3+ and framework versions within the patched Next.js ranges (e.g., 15.0.7, 16.0.10).
• Runtime truth: link the deployment ID or image digest to the commit that contains the version bumps.
• Traffic truth: a time‑boxed log search from Dec 3 onward with no confirmed exploit hits and reduced anomalies post‑patch.
• Compromise truth: results from EDR/WAF/IDS covering the same period, plus any incident response artifacts (if indicators surfaced).
• Secrets truth: a table of rotated secrets with rotation timestamps and blast radius coverage.

People also ask: key questions your team will face

Is the Next.js Pages Router affected?

No for the RCE, according to the vendor advisory; the issue sits in the RSC path used by the App Router. Still, verify you’re not running a hybrid that wires in RSC packages via plugins or experimental flags.

Do I still need to patch if I’m not using Server Actions?

Yes. Apps can be affected if RSC support is present, even without explicit Server Actions. The vulnerable decoder sits in the server pipeline used by RSC‑aware frameworks.

Can a WAF fully block React2Shell?

Treat WAFs as seatbelts, not roll cages. Providers shipped rules that blunt common exploit patterns, but these are heuristics. Patch first, then keep the rules during your verification window.

We updated on Dec 4. Are we done?

Likely not. Follow‑on DoS and source exposure issues landed December 11 with additional patches. If you only jumped to React 19.0.1/19.1.2/19.2.1 or the first wave of Next.js fixes, plan another update to the latest recommended ranges.

Risk you might be underestimating

Transitive dependencies and private caches. Internal registries or artifact mirrors sometimes pin older artifacts. If your SBOM scan says “fixed” but your runtime hash differs, you may still be serving vulnerable code. Refresh caches and re‑run scans at the image or function artifact level.

Monorepos with mixed stacks. We’ve seen React Native monorepos accidentally hoist vulnerable RSC packages. For those, bump only the affected RSC packages and avoid unrelated major upgrades that could break mobile builds.

Partial environment rollouts. If you deploy canaries, ensure the bulk of traffic isn’t stuck on unpatched blue nodes. Validate with real request sampling at the load balancer.

False confidence from public PoCs. Several circulating PoCs are broken. A failed PoC doesn’t prove safety. Your proof should be versions + runtime artifacts + logs, not just exploit scripts.

Let’s get practical: the “PARC” framework

Use this lightweight framework to drive the war room and keep everyone aligned:

• Prioritize: identify public‑facing RSC apps and the environments they run in (prod first, then staging if it’s internet‑exposed).
• Act: patch React and your framework to the recommended versions; redeploy; add temporary WAF rules.
• Review: verify versions in runtime, scan for indicators since Dec 3, rotate secrets if you were exposed on or after Dec 4 at 1:00 PM PT.
• Certify: compile your evidence bundle and executive note; schedule a week‑out recheck to ensure drift hasn’t reintroduced vulnerable ranges.

What to do next (engineers)

• Bump React RSC packages to 19.0.3/19.1.4/19.2.3 or later; for Next.js, target 15.0.7/15.1.11/15.2.8/15.3.8/15.4.10/15.5.9/16.0.10 or newer in those lines.
• Run npx fix-react2shell-next if you’re on App Router; commit the lockfile; redeploy; invalidate caches.
• Capture proof: CI logs, npm ls outputs, deployment IDs, scanner reports.
• Rotate secrets if you were online and unpatched after Dec 4, 2025 1:00 PM PT.
• Keep WAF rules in place for a week while you monitor.

What to do next (business/IT leaders)

• Approve an emergency change window even during a code freeze; this is a security fix, not a feature.
• Ask for the evidence bundle and a plain‑English one‑pager that addresses impact, coverage, and residual risk.
• Fund a post‑mortem to harden dependency management: SBOM in CI, version overrides, and artifact cache policies.

Related resources and expert help

We’ve been tracking this closely and publishing hands‑on remediation notes throughout December. If you need a structured sprint, start with our 10‑day holiday patch sprint and the concise holiday briefing to patch, rotate, verify. If you’re coordinating multiple teams and environments, our week‑three lock‑down checklist helps ensure drift doesn’t re‑open the hole. And if you’d rather have a partner lead the effort end‑to‑end, our team handles emergency upgrades, incident response, and proof packages—see our application security reviews or talk to us.

Zooming out: what this teaches us

React2Shell isn’t just “another CVE.” It’s a reminder that performance‑oriented features like RSC can shift trust boundaries in ways security models don’t anticipate. Serialization borders are execution borders. When they blur, default configurations can carry surprising risk. The answer isn’t “don’t use RSC”—it’s to treat framework features as privileged surfaces, put SBOMs in CI, and pressure‑test how quickly you can patch and prove during peak season. The teams that did this well had fewer late nights this month.

If you ship on the modern web, this is the job: fast fixes, clean evidence, minimal downtime. Do that consistently, and you earn the right to keep shipping the features that actually move your business.