React2Shell is the rare bug that forces even mature teams to move fast and keep receipts. After the initial critical advisory, the React team and Next.js shipped additional fixes that developers must apply—yes, again. If your production uses React Server Components via the Next.js App Router, you should treat this like an incident, not a routine update.
What changed since the first React2Shell advisory?
On December 3, 2025, the React team disclosed CVE‑2025‑55182, a pre‑auth RCE in the React Server Components (RSC) protocol, and pushed fixes. That was the emergency patch many of us rushed to ship. A week later, on December 11, React followed with more RSC issues—CVE‑2025‑55183 (source code exposure) and CVE‑2025‑55184 (denial of service)—and then clarified an incomplete DoS fix with CVE‑2025‑67779. Translation: if you only patched once, you’re not done.
These updates affect the same RSC packages (react-server-dom-* across webpack, parcel, and turbopack) and require specific patched versions. React’s posts explicitly direct teams to update again because earlier fixes for DoS were incomplete. (react.dev)
Next.js security update: which versions are actually safe?
Next.js published a downstream advisory on December 11, 2025, mapping the React vulnerabilities to App Router builds and listing fixed versions to install immediately. Pages Router apps aren’t affected by the RSC protocol issues, though the project still recommends upgrading to a patched release line.
Per the Next.js team, the patched targets include: 14.2.35 (for 14.x), 15.0.7, 15.1.11, 15.2.8, 15.3.8, 15.4.10, 15.5.9, 15.6.0‑canary.60, 16.0.10, and 16.1.0‑canary.19. If you’re on >=13.3, you should move to the latest 14.2.x or the latest in your current major as listed. (nextjs.org)
React2Shell exploitation: why urgency still matters
Security teams have tracked real‑world exploitation of the original RCE, including coin‑miner deployments and persistence attempts against Linux and Windows servers. The risk profile is rough: default configurations are vulnerable, it’s pre‑auth, and reliable public exploits exist—so unpatched internet‑facing apps become low‑effort targets fast. (microsoft.com)
Primary question: who’s vulnerable now?
If your production builds rely on React Server Components (RSC) through the Next.js App Router, you’re in scope. Even apps without explicit Server Functions can be vulnerable if RSC is supported at all. Teams running classic Pages Router only are not in scope for the RSC protocol bugs, but still consider upgrading to aligned patched versions to avoid dependency drift and to land any hardening that ships with the release. (react.dev)
React2Shell mitigation checklist: patch twice, verify, rotate
Here’s a pragmatic checklist you can run in a half day if your codebase is tame, and a day or two if you’ve got a large monorepo with shared tooling.
1) Inventory and confirm exposure
In each deployable, run a fast inventory to confirm whether RSC packages exist and which versions you’ve pinned:
• npm ls react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack next
• Check lockfiles for transitive pins, especially in workspace roots (npm, pnpm, Yarn Berry).
• Inspect your runtime image or Lambda/edge bundle manifest to ensure the patched versions actually ship.
If you see React RSC versions 19.0.0–19.2.2 in any of those packages, or a Next.js App Router version in the vulnerable ranges, you’re exposed and must upgrade. (react.dev)
2) Patch to known-good versions
Pick one of the explicitly patched Next.js versions for your major. For 14.x, upgrade to 14.2.35. For 15.x or 16.x, choose the fixed build listed in the official table. Don’t chase “latest” blindly—install a version the Next.js advisory names so auditors can trace your fix to the documented CVEs. (nextjs.org)
For React RSC packages, move to the fixed backports the React team noted: 19.0.3, 19.1.4, or 19.2.3. If you previously landed 19.0.2, 19.1.3, or 19.2.2, update again due to the incomplete DoS fix now tracked as CVE‑2025‑67779. (react.dev)
3) Verify with evidence
Teams get tripped up by “it built on CI, so we’re safe.” Prove it:
• Freeze a build artifact hash (container digest, or bundle checksum).
• Export SBOMs before and after the patch (Syft, npm sbom) and staple them to the change ticket.
• Run curl against a representative Server Function endpoint with innocuous payloads to ensure the server responds cleanly post‑patch.
• Confirm npm ls and runtime introspection show the patched versions in the shipped image, not just in the dev environment.
4) Rotate secrets and check blast radius
React’s source exposure bug can reveal compiled server function code; if secrets are inlined in code (don’t do this), rotate now. Even if you follow 12‑factor and pull from runtime env, rotate high‑value credentials for any app that was publicly reachable and unpatched during the window between December 3–11. If you patched later than December 11, widen the rotation scope. Next.js explicitly urged secret rotation for unpatched apps during the initial response window. (nextjs.org)
5) Hunt for signs of compromise
On hosts that ran a vulnerable build, scan for common post‑exploitation patterns: new users, modified authorized_keys, RMM agents you didn’t deploy (e.g., MeshAgent), suspicious processes masked with bind mounts, outbound beacons to unusual Cloudflare Tunnel endpoints. Prioritize internet‑facing services and anything Defender or your EDR flags as externally exposed. (microsoft.com)
Data you can take to leadership
• December 3, 2025: React discloses CVE‑2025‑55182 (RCE) and publishes patches.
• December 11, 2025: React discloses CVE‑2025‑55183 (source exposure) and CVE‑2025‑55184 (DoS), then adds CVE‑2025‑67779 to cover incomplete DoS cases; directs teams to update again.
• December 11, 2025: Next.js publishes a downstream advisory listing fixed versions for App Router users.
• Mid‑December: Security vendors observe exploitation activity in the wild and recommend immediate patching, inventory, and threat hunting.
Those bullets, plus SBOM diffs and build digests, are usually enough to close an incident ticket and satisfy customer security questionnaires without a long email thread. (react.dev)
People also ask: do I have to update React if I only use Next.js?
In practice, you’ll update both. The Next.js advisory pins safe framework versions, and React’s posts declare the safe RSC packages (19.0.3, 19.1.4, 19.2.3). Because Next.js integrates RSC through its own release lines, the clean path is to upgrade Next.js to a named safe version and ensure your lockfile resolves RSC to safe backports. That’s what your SBOM and npm ls checks will verify. (nextjs.org)
Are Pages Router apps completely safe?
They’re not affected by the RSC protocol bugs because they don’t rely on RSC. That said, organizations often standardize on a single Next.js minor across services. Upgrading anyway reduces drift, aligns your toolchain, and keeps you off unsupported canaries. (nextjs.org)
Edge cases and gotchas from shipping these patches
• Monorepos with React Native: React’s guidance notes you don’t need to bump react and react-dom in RN workspaces; only patch the RSC packages if present. Avoid version mismatch errors by scoping changes to the affected packages.
• Canary bleed: If you pulled a canary to land a hotfix, back it out to a stable tagged build from the advisory list once you’ve verified parity.
• Lockfile inertia: CI might reuse an older lockfile that still resolves a vulnerable transitive. Recreate the lockfile and compare SBOMs to be sure your runtime image changed.
• Edge functions and lambdas: Validate cold starts and memory ceilings after the patch—serialization changes can affect payload size and CPU in tight environments.
• WAF and rate limits: If you applied emergency WAF patterns during the first advisory, retest them. Drop any bypass rules you temporarily added.
These are small but real paper cuts that can turn a one‑hour patch into a long afternoon if you don’t plan for them. (react.dev)
How this connects to broader software supply chain risk
React2Shell isn’t an npm account takeover or malicious package incident—it’s a logic flaw in a core protocol. But the lesson is the same as recent npm supply‑chain waves: you need fast inventory, environment‑level detection, and a habit of producing artifacts that prove the change happened. The days of “we think we updated” are over in audit land.
Let’s get practical: a one‑pager you can paste into your ticket
Objective
Patch React2Shell and follow‑on RSC vulnerabilities across all Next.js App Router services; verify with artifacts; rotate exposed secrets; hunt for compromise indicators; communicate status.
Steps
1) Inventory
• npm ls react-server-dom-* next
• grep lockfiles for 19.0.0–19.2.2 and vulnerable Next.js minors.
• Export pre‑patch SBOMs.
2) Patch
• For 14.x: npm i [email protected].
• For 15.x/16.x: choose the fixed version from the advisory table.
• Ensure react-server-dom-* resolves to 19.0.3, 19.1.4, or 19.2.3.
• Rebuild containers/edge bundles and redeploy.
3) Verify
• npm ls in the runtime image.
• Attach SBOM diffs to ticket.
• Hit a Server Function endpoint with a benign payload; confirm healthy behavior.
• Capture container digest and artifact checksums.
4) Secrets
• Rotate any secrets exposed to an unpatched internet‑facing app between December 3–11 (or your later patch date).
• Confirm no secrets are embedded in compiled code; move everything to runtime env.
5) Hunt
• Check for new users, modified authorized_keys, suspicious RMM agents, unusual Cloudflare Tunnel domains in logs.
• Prioritize internet‑facing services; escalate if anything’s off.
6) Communicate
• Share a short note: scope, fixed versions, artifact hashes, SBOM diffs, and whether secrets were rotated. Link to the official advisories.
What to do next (today, not tomorrow)
• Pick the safe Next.js version for your line and land it before traffic ramps again.
• Update RSC packages to the safe backports React calls out.
• Rotate secrets if you had exposure; don’t debate this in Slack all afternoon.
• Produce SBOMs and digests to close the loop.
• Schedule a retro on your inventory and patch‑rollout mechanics; this won’t be the last protocol‑level bug you see.
Further help and related playbooks
If you need a structured plan, we’ve published practical playbooks our clients use during these windows. For a deeper runbook with day‑by‑day tasks and evidence collection, see our holiday patch playbook for React2Shell, and when a vendor drops a late‑breaking fix, follow the cadence in Next.js: Patch Twice, Verify Now. If you’re still catching up from earlier advisories, our piece on week two response and proof can help you close out audits faster. And if this surfaced bigger security debt, our services page outlines how we triage, patch, and validate at scale.
Zooming out
Here’s the thing: frameworks like Next.js made RSC easy enough to adopt that many teams didn’t fully internalize the new threat model. That’s normal. What matters now is operational maturity—fast patches, verifiable changes, clear comms. Ship the named safe versions, rotate, hunt, and move on. The next advisory will be easier because you practiced on this one.
