If you shipped emergency updates for React2Shell the first week of December, you did the right thing—but the story didn’t end there. The React team disclosed a critical RCE in React Server Components (CVE‑2025‑55182) on December 3 with patches in 19.0.1, 19.1.2, and 19.2.1. A week later, two more RSC issues were published, and one early fix turned out to be incomplete—requiring another round of upgrades. Here’s the plan to finish the job and prove you’re safe. (react.dev)
What changed since the first React2Shell patch?
On December 3, the React team confirmed a pre‑auth RCE in the RSC “Flight” protocol and shipped fixes. Affected packages included react‑server‑dom‑webpack, react‑server‑dom‑parcel, and react‑server‑dom‑turbopack; the patched versions were 19.0.1, 19.1.2, and 19.2.1. (react.dev)
On December 11, researchers reported two follow‑up vulnerabilities in RSC: a High‑severity Denial of Service (CVE‑2025‑55184, later superseded by CVE‑2025‑67779) and a Medium‑severity Source Code Exposure (CVE‑2025‑55183). React backported complete fixes to 19.0.3, 19.1.4, and 19.2.3, and explicitly noted that some earlier patches (e.g., 19.0.2/19.1.3/19.2.2) were incomplete. If you stopped at the first patch wave, you need to update again. (react.dev)
Next.js tracked the upstream issues and published a version matrix. If you’re on the App Router with RSC enabled, you should be on one of the fixed lines—14.2.35 for 14.x users, or 15.0.7 / 15.1.11 / 15.2.8 / 15.3.8 / 15.4.10 / 15.5.9 / 16.0.10 for the respective branches. A canary line was also patched. (nextjs.org)
Is my app actually vulnerable?
Ask yourself three fast questions:
First: Do you run any framework or bundler that implements React Server Components? If you use the Next.js App Router, unstable RSC APIs in React Router, or plugins like @vitejs/plugin‑rsc, assume exposure until you confirm versions. (react.dev)
Second: Which versions are deployed? For React RSC packages, vulnerable ranges began at 19.0.0 and extended through the incomplete fixes; safe lines include 19.0.3, 19.1.4, and 19.2.3 and later. For Next.js App Router, match your branch to the patched versions above. Pages Router apps aren’t affected by the RSC protocol bugs, but upgrading to the fixed line is still recommended to avoid transitive surprises. (react.dev)
Third: Was your environment internet‑facing and unpatched during the first week of December? Exploitation attempts were observed as early as December 5, and Microsoft has documented real‑world intrusions. If you were online and unpatched, plan on deeper forensics and possible secret rotation. (microsoft.com)
React2Shell: the second‑wave vulnerabilities, explained
1) Denial of Service (CVE‑2025‑55184 → CVE‑2025‑67779)
A crafted RSC request could trigger an infinite loop that ties up CPU and hangs the process. The initial patch didn’t cover all paths; the complete fix is tracked as CVE‑2025‑67779. If you’re on React 19.0.2 / 19.1.3 / 19.2.2, you’re not done—move to 19.0.3 / 19.1.4 / 19.2.3. (react.dev)
2) Source code exposure (CVE‑2025‑55183)
Under specific conditions, a malicious request could cause a Server Function to return its compiled source. Secrets hardcoded in code could leak; environment variables aren’t directly affected, but any constant inlined by the bundler might be. The current React patches prevent stringifying source in these replies. (react.dev)
“Do we need to rotate secrets?” (Yes—if you were unpatched)
Next.js explicitly advised secret rotation if your app was online and unpatched as of December 4, 1:00 PM PT. If that describes you, rotate the crown‑jewel credentials first: database passwords, cloud access tokens, webhook signing keys, and any long‑lived API tokens. (nextjs.org)
A 72‑hour patch‑and‑prove plan your team can run now
Let’s get practical. Use this as your runbook. If you own multiple services, tackle internet‑facing workloads first, then high‑blast‑radius internal apps.
Hour 0–6: Identify and freeze
• Inventory RSC usage. In each repo or container image, look for react‑server‑dom‑webpack, react‑server‑dom‑parcel, react‑server‑dom‑turbopack, and framework packages like next. Record current versions and where they’re deployed. (microsoft.com)
• Freeze deploys. Hold feature releases until you land patches and verification.
• Add a WAF rule as a seatbelt while you patch. If you’re on Azure Application Gateway or Front Door, enable the built‑in React2Shell rule (DRS 2.1, ID 99001018) or apply the published custom rules. Do not treat this as a substitute for patching. (techcommunity.microsoft.com)
Hour 6–24: Patch with confidence
• Upgrade React RSC packages to 19.0.3, 19.1.4, or 19.2.3 depending on your line. Confirm lockfiles updated; rebuild and redeploy. (react.dev)
• On Next.js App Router apps, bump to the fixed release for your branch. If you’re unsure, run npx fix-react2shell-next and follow the prompts; it checks your versions and performs deterministic bumps to the recommended targets. (nextjs.org)
• For canary users, make sure you’re on the patched canary versions called out by Next.js. (nextjs.org)
• Rebuild Docker images to avoid lingering vulnerable layers. Tag and sign artifacts.
Hour 24–48: Verify and watch
• Confirm fix is live by diffing package-lock.json/pnpm-lock.yaml in the running container or instance. Validate that runtime modules resolve to patched versions (e.g., npm ls react-server-dom-webpack in prod shells). Pair this with synthetic requests to known RSC endpoints.
• Turn on heightened telemetry. Microsoft observed threat actors dropping RATs and coin miners post‑exploit; watch egress, process tree anomalies, and unusual persistence (cron, systemd units, authorized_keys edits). (microsoft.com)
• Review WAF logs for hits on React2Shell signatures. Use that to focus forensics where needed. (techcommunity.microsoft.com)
Hour 48–72: Rotate and remediate
• If you were exposed during the initial disclosure window, rotate secrets. Prioritize database and cloud credentials, then third‑party API keys. Document scope and timestamps of rotations for audit trails. (nextjs.org)
• Hunt for indicators. Leverage your SIEM detections for domains, hashes, and common post‑exploitation commands flagged by Microsoft. (microsoft.com)
• Close the loop with a post‑incident memo: exposure window, mitigations, residual risk, and tracking for follow‑up CVEs.
People also ask
Are Pages Router apps affected?
The RSC protocol issues impact App Router deployments. Pages Router apps aren’t directly affected, but upgrading to the fixed release line is recommended to keep transitive dependencies aligned and to simplify future upgrades. (nextjs.org)
Do I need to update twice if I already patched on December 3–6?
Most teams that landed the first React2Shell fix still need to pick up the December 11 patches for DoS and source exposure—especially because an initial DoS fix was incomplete and replaced by CVE‑2025‑67779. Verify you’re on React 19.0.3 / 19.1.4 / 19.2.3 or later, and the matching Next.js versions for your branch. (react.dev)
We patched and see no alerts—are we done?
Not quite. Microsoft telemetry shows exploitation attempts began December 5, with coin miners common across Windows and Linux. If your app was reachable and unpatched in that window, complete the secret rotation and conduct a lightweight compromise assessment before standing down. (microsoft.com)
Edge cases and gotchas I’ve seen in real teams
• Monorepos with mixed React Native and web: RN apps don’t use react‑dom, but the RSC packages can be present in workspace roots. Don’t blanket‑bump react in RN packages; follow the React guidance and update only the impacted RSC packages to avoid mismatches. (react.dev)
• Canary builds: Some teams stayed on canaries for PPR features. Next.js shipped patched canaries; take them or move to the nearest stable branch noted in the matrix. (nextjs.org)
• Partial container rebuilds: If you patched the app layer but not the base image, you might still be running old lockfiles or cached layers. Force a clean build with --no-cache and confirm the resolved versions inside the container.
• “WAF only” thinking: Azure WAF added a CVE‑specific rule (and published custom patterns for older rulesets), but these are compensating controls. Your proof of remediation should rest on package versions, not WAF hits. (techcommunity.microsoft.com)
Data that matters: versions, dates, and where you should be by now
• December 3, 2025: React discloses RCE CVE‑2025‑55182; fixes in 19.0.1, 19.1.2, 19.2.1. (react.dev)
• December 11, 2025: React publishes DoS (CVE‑2025‑55184 → CVE‑2025‑67779) and Source Exposure (CVE‑2025‑55183), with backports to 19.0.3, 19.1.4, 19.2.3. (react.dev)
• December 11, 2025: Next.js releases a full version matrix and the npx fix-react2shell-next helper. (nextjs.org)
• December 5 onward: Exploitation observed in the wild; coin miners and RATs are common payloads. (microsoft.com)
What to do next (developers)
• Patch to the exact fixed versions for your line, not just “latest.” Log immutable evidence (commit SHAs, lockfile diffs, artifact SBOMs).
• Add a regression test that requests a dummy RSC Server Function and asserts the response shape—not source code strings or pathological loops.
• Wire an alert for spikes in 5xx rates on your RSC endpoints; DoS variants often show up as sudden concurrency drops.
• Keep a short‑lived feature freeze until you’ve completed secret rotation and basic hunting.
What to do next (business owners and CTOs)
• Approve an emergency change window to land these patches across public‑facing apps and high‑risk internal tools.
• Ask for a one‑page memo by date: exposure window, patch versions, verification steps, and whether secrets were rotated.
• Require a quick tabletop on incident response paths if an alert fires—who’s on call, who pulls logs, who talks to customers.
• Fund a small hardening backlog: SBOM generation in CI, weekly dependency review, and WAF log shipping to your SIEM.
Useful resources on our site
If you want a shorter, prescriptive plan, see our 7‑day patch and prove playbook. For Next.js‑heavy stacks, start with our Next.js patch‑twice checklist, then skim the lessons learned in Patch Fast, Prove Safety, Avoid Traps. If you’d like help coordinating a multi‑app rollout and verification, our services overview explains how we run security sprints with minimal product downtime.
A quick verification framework you can copy
Here’s a lightweight framework I use with teams when we need to prove remediation in hours, not weeks:
1) Evidence of fix: Capture lockfile diffs and resolved versions in running containers. Keep screenshots and CLI outputs in a ticket.
2) Behavioral checks: Hit a canary Server Function with a harmless request and verify response shape. No source strings, no loop stalls. Roll this into CI as a smoke test.
3) Telemetry review: Correlate 24‑hour windows of WAF hits, 5xx spikes, process creation, and outbound DNS from app nodes. You’re looking for “weird right after deploy.” (techcommunity.microsoft.com)
4) Secret stability: If rotation occurred, validate new credentials in code paths (DB pool, queue producers, third‑party SDKs). Watch for auth failures or throttling.
5) Post‑mortem: Write the memo. It’s your artifact if customers, auditors, or leadership ask why you’re confident.
Zooming out: why this won’t be the last holiday sprint
Critical CVEs often reveal neighboring flaws once researchers probe the patch surface area. React called this out explicitly in its follow‑up post—and it mirrors what we saw after Log4Shell: the first fix closes the front door, then the community finds side windows. Build that reality into your playbooks: fast patching, yes, but also fast verification and measured rotation. (react.dev)
If you need a structured partner for the next sprint, we’ve run these playbooks end‑to‑end for product teams under load. Reach out via our contact page and we’ll map a 72‑hour plan to your stack.
