React2Shell is the critical React Server Components (RSC) remote code execution bug disclosed on December 3, 2025 as CVE‑2025‑55182. It allows unauthenticated RCE via crafted requests to Server Function endpoints in default configurations of popular stacks, notably Next.js App Router. A week later, on December 11, the React team shipped additional patches for a medium source code exposure (CVE‑2025‑55183) and a high‑severity denial of service (CVE‑2025‑55184). If your production runs RSC, treat this as a live‑fire incident. This guide gives you a pragmatic, 10‑day React2Shell response that patches fast, proves safety, and prevents a repeat.
What changed since the first disclosure?
Here’s the timeline you should anchor on, because dates matter when you’re accounting for exposure windows:
• December 3, 2025: CVE‑2025‑55182 (React2Shell) disclosed. Affected packages include react‑server‑dom‑webpack, react‑server‑dom‑parcel, and react‑server‑dom‑turbopack in versions 19.0, 19.1.0, 19.1.1, and 19.2.0. Patched versions: 19.0.1, 19.1.2, and 19.2.1.
• December 11, 2025: Two related RSC issues disclosed and patched: CVE‑2025‑55183 (source code exposure, medium) and CVE‑2025‑55184 (DoS, high). These don’t re‑introduce RCE, but they do matter for secrets in source and for availability.
• Next.js downstream advisory: Next.js tracked the upstream RCE as CVE‑2025‑66478 for App Router apps and issued patches. Fixed releases include 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, and 16.0.7. There’s an addendum that the initial DoS fix needed a follow‑up (tracked separately) and has since been completed.
By mid‑December, this is not a “wait for the next sprint” situation; it’s an incident. Treat unpatched windows between December 3 and your patch date as potentially compromised, especially if you logged unusual errors on RSC routes or saw spikes on multipart/form‑data requests that map to Server Functions.
Am I actually vulnerable?
Short answer: if you support React Server Components, assume “yes” until you’ve verified package versions in production and confirmed you’re absorbing the December 11 fixes.
Do I need to enable Server Functions to be affected?
No. Even if you didn’t explicitly implement Server Functions, applications that support RSC can still deserialize attacker‑controlled payloads at Server Function endpoints exposed by the framework.
Which Next.js versions are affected?
Next.js App Router in 15.x and 16.x is in scope, as well as 14.3.0‑canary.77 and later canaries. Pages Router apps and the Edge Runtime aren’t affected by the RCE. Production builds from a default create‑next‑app App Router project were vulnerable before patching.
What if I pinned React but not the RSC packages?
Check your lockfile. The RSC packages often resolve transitively via framework and bundler plugins. You must confirm actual versions on the server match the patched sets. If you containerize, verify the image layers and artifact repository, not just the package.json.
React2Shell 10‑Day Patch & Proof Plan
This is the playbook I’ve used across multiple teams this month. It assumes you can ship hotfixes and run post‑incident verification in parallel without stalling feature work for more than a few days.
Day 0–1: Patch fast, everywhere
• React/RSC packages: upgrade to 19.0.1, 19.1.2, or 19.2.1 for react‑server‑dom‑webpack, react‑server‑dom‑parcel, and react‑server‑dom‑turbopack.
• Next.js: upgrade to one of the fixed lines: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, or 16.0.7. If you’re unsure, run npx fix-react2shell-next to automate the patch and verify dependency alignment.
• Rebuild base images and invalidate caches. Don’t trust layer caching to pull the new RSC modules.
• Deploy behind WAF rules that block suspicious multipart RSC payloads while your fleet rolls forward.
Tip: Don’t co‑mingle feature changes. Keep a clean, auditable hotfix branch so you can roll forward or back without collateral risk.
Day 2–3: Prove the patch in production
• Version attestation: expose dependency SBOMs per service (CycloneDX or SPDX) and store them alongside release metadata.
• Runtime checks: add a startup assertion that logs the exact RSC and Next.js versions. Grep logs cluster‑wide to verify there are no stragglers.
• Synthetic probes: hit a known Server Function endpoint with benign payloads to confirm patched behavior (for example, attempts to stringify Server Function source code should be blocked after the December 11 patch). Record HTTP status/latency deltas pre/post patch.
Day 4–5: Hunt for compromise
• Logs and telemetry: search for spikes in 4xx/5xx on RSC routes, unusual multipart boundaries, and payloads with unexpected symbol references.
• System artifacts: scan for suspicious Node processes, web shells, and temp files dropped by your app user. Validate integrity of your .next build output and server directories.
• Secrets: if you were online and unpatched after December 3, rotate critical credentials (DB users, signing keys, API tokens). Prioritize the blast radius of the app’s runtime identity.
Day 6–7: Close variant gaps
• Pull in the December 11 fixes for CVE‑2025‑55183 (source exposure) and CVE‑2025‑55184 (DoS) and verify you’re on the releases that include the follow‑up fix for the DoS edge case.
• Review bundler settings: ensure your production bundles aren’t inlining secrets. The exposure bug is limited to code in the Server Function, but over‑aggressive inlining can widen what’s visible.
• Add input validation to Server Functions. Even with upstream fixes, defense‑in‑depth helps absorb future parser oddities.
Day 8–10: Prevent a repeat
• Dependency hygiene: lock minor/patch ranges for server‑critical packages and automate daily update PRs with SCA gates. The goal isn’t to avoid updates; it’s to apply them quickly and predictably.
• Security SLOs: add a “time‑to‑patch critical upstream CVEs” target (e.g., 72 hours). Track it like an uptime SLO.
• Chaos drift checks: weekly job that compares production SBOMs to your package.json to catch transitive regressions.
• Playbooks: write a two‑page “RSC incident runbook” that any on‑call can follow at 2 a.m.—commands, dashboards, and the clean rollback path.
Version matrix you can copy into your runbook
React Server Components packages affected by the RCE (CVE‑2025‑55182): 19.0, 19.1.0, 19.1.1, 19.2.0. Patched: 19.0.1, 19.1.2, 19.2.1.
Next.js (App Router) downstream RCE advisory (CVE‑2025‑66478): patch to 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, or 16.0.7. Pages Router and Edge Runtime aren’t affected by the RCE.
Additional RSC CVEs disclosed December 11, 2025: CVE‑2025‑55183 (medium, source code exposure) and CVE‑2025‑55184 (high, DoS). Ensure your packages include the complete follow‑up fix for the DoS case as noted in vendor advisories.
How attackers have been approaching this—so you can detect them
Most opportunistic activity looks like wide scanning for RSC endpoints, followed by payloads that try to coerce deserialization into executing attacker‑controlled references. In practice, that shows up as odd multipart boundaries and parameters that map to internal module exports. On compromise, you may see transient shells or script runners spawned by your Node process. If your egress is open, the process often attempts to beacon out to commodity C2 over HTTPS.
Network clues: outbound connections from web tiers that don’t normally call the public Internet; new DNS queries post‑deployment; sudden spikes in node child processes. Filesystem clues: unexpected temporary files under /tmp or your app’s working directory; altered next.config.js or injected files with innocuous names but recent mtime.
Let’s get practical: a checklist you can run today
Use this as a working card for the on‑call and the EM:
1) Identify exposure
• List all services using Next.js App Router or custom RSC.
• Extract SBOMs from currently deployed images; confirm RSC package versions and Next.js versions.
2) Patch
• Upgrade to React RSC 19.0.1/19.1.2/19.2.1 and Next.js 15.0.5+ or 16.0.7.
• Run npx fix-react2shell-next if you’re on Next.js to automate the dependency corrections.
3) Verify
• Add startup logs of exact package versions; scrape fleetwide for matches.
• Run synthetic probes against Server Function endpoints; watch for stable 2xx and no stringified source in responses.
4) Hunt
• Query logs for RSC path anomalies, multipart payload spikes, and 5xx bursts since December 3.
• Scan hosts for suspicious node children and unexpected files.
5) Recover
• Rotate credentials for any app that was online and unpatched after December 3.
• Rebuild images from patched bases; redeploy with cache busting.
6) Prevent
• Add weekly SBOM drift checks; set a 72‑hour SLO for critical CVEs; document the rollback path.
People also ask
Is React2Shell fixed now, or do I need more than one update?
The original RCE fix (December 3) is addressed in the patched RSC versions and corresponding Next.js releases. You should also ensure you’ve absorbed the December 11 fixes for the source exposure and DoS cases. Some advisories noted a small follow‑up to complete the DoS mitigation—make sure your versions include it.
We never added any Server Functions. Should we still rotate secrets?
If your app was online and in scope during the vulnerable window, rotate the high‑impact secrets anyway. The cost to rotate a database password is small compared to the cost of missing a silent foothold.
Should we pause RSC adoption?
No—but you should treat RSC as server‑side code with all the scrutiny that entails. Keep dependency ranges tight, instrument the endpoints, and design for safe failure modes. The performance and DX wins are real; so are the responsibilities.
What good looks like one week from now
Your fleet is on patched RSC and fixed Next.js lines. You can produce an SBOM and release artifact that proves it for any service. You’ve searched logs back to December 3 and found no credible indicators—or you did, and you’ve contained and rebuilt. You have a standing playbook for “upstream critical CVE with remote exploitation” that on‑call can run in their sleep.
Useful resources from our team
If you want deeper dive steps and tooling, we’ve been publishing focused guides as the situation evolved. Start with our field guide to the React2Shell aftershocks, then grab the Next.js Dec 11 patch playbook and the companion note on the Dec 11 fixes you need now. If you’d rather not do this alone, our security hardening services include dependency governance, SBOM pipelines, and incident drills, and you can talk to us today.
What to do next (developers)
• Ship the patches today; don’t bundle with features.
• Add package version logs and SBOMs to every deployment.
• Write a one‑page runbook for RSC incidents and put it next to your on‑call rotations.
• Automate weekly dependency drift checks and alerts.
What to do next (engineering leaders)
• Define a 72‑hour SLO for critical upstream CVEs and hold teams to it.
• Fund WAF rules and egress controls for web tiers that run server‑side JS.
• Require environment‑level secret rotation as a first‑class capability.
• Make “security regression” a release gate like performance and accessibility.
Zooming out
React2Shell wasn’t a logic bug in your code; it was a deserialization flaw in a widely adopted server runtime path. When the ecosystem moves server logic into shared protocol layers, the blast radius of an upstream mistake is measured in hours, not days. The answer isn’t fear—it’s muscle memory: fast patch, visible proof, targeted hunting, then institutional learning. If you ingrain that now, the next bulletin won’t own your roadmap.
