On December 3, 2025, the React team disclosed a critical React Server Components vulnerability that enables unauthenticated remote code execution (RCE) via the RSC “Flight” protocol. Patched React and Next.js builds shipped within days. If you run Next.js App Router or any framework that implements RSC, treat this as a production incident, not a routine dependency bump. Below is a practitioner’s plan to triage, patch, and validate in 48 hours—without creating new blast radius.
What changed this week (dates, versions, impact)
Here’s the thing: we have concrete dates and versions, so you can act decisively. The vulnerability (CVE‑2025‑55182) affects react-server-dom‑* packages in React 19.0, 19.1.0, 19.1.1, and 19.2.0. Fixed builds landed as 19.0.1, 19.1.2, and 19.2.1. For Next.js (CVE‑2025‑66478), the patched releases are 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, and 16.0.7; canary lines received 15.6.0‑canary.58 and 16.1.0‑canary.12. If you’re on Next.js 14.3.0‑canary.77 or later canaries, the official guidance is to downgrade to the latest stable 14.x—or move to a patched 15/16 release line.
Timeline you can share with your stakeholders: November 29, 2025 (report received), December 1 (fix prepared and validated with hosts/frameworks), December 3 (public disclosure and npm releases), December 6 (utility published to help Next.js apps upgrade more deterministically). This is a fast‑moving situation with active exploitation, so speed and discipline both matter.
Who’s actually affected?
If you run Next.js App Router, you’re squarely in scope. Other frameworks and bundlers implementing the RSC protocol are also affected: React Router’s unstable RSC APIs, Waku, Parcel RSC, Vite’s RSC plugin, Turbopack variants, and any platform bundling react-server-dom‑webpack, react-server-dom‑parcel, or react-server-dom‑turbopack. If your app doesn’t use RSC or doesn’t execute server functions, you’re likely out of the danger zone—but verify, don’t assume.
Production reality check: many teams adopted RSC via framework defaults or templates without explicitly listing react-server-dom‑* in package.json. Your CI may be pinning Next.js but floating transitive RSC versions. That’s why inventorying lockfiles and images is step one.
48‑Hour Patch Playbook (use this)
This is the fastest safe path I’ve used with client teams. Tailor to your release policy, but resist scope creep. The goal is to reduce exposure first, then harden.
Hour 0–4: Contain and verify
1) Freeze deploys that aren’t security‑related. 2) Enumerate exposure: search all repos for RSC indicators—react-server-dom-, serverActions, App Router usage in Next.js (app/ directory), and any RSC‑capable bundlers/plugins. 3) Pull the SBOM or lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock) and identify versions of react, react-dom, and react-server-dom-*. 4) Snapshot production: record image digests, AMIs, and edge config so you can quickly roll back if needed.
Optional but pragmatic: if your platform supports emergency rules, deploy a narrow WAF rule or edge filter to reduce obviously malformed RSC requests while you patch. Don’t rely on this as a fix; treat it as turbulence control during the upgrade window.
Hour 4–18: Patch and ship
For Next.js, upgrade to the patched release in your current line (15.x or 16.x) or move stably off affected canaries. Keep the change minimal: bump only the framework and React family to the fixed versions. If you’re on Next.js canary solely for features like Partial Prerendering, use the patched canary recommended for this incident. If your stack directly imports react-server-dom‑*, pin to a fixed React set: 19.0.1, 19.1.2, or 19.2.1 across react, react-dom, and the react-server-dom‑* package you use.
Run a clean install, rebuild server images, and redeploy to a non‑prod environment. Exercise a thin set of smoke tests: SSR paths, server actions, mutations that cross the RSC boundary, and auth flows. Verify logs for unexpected server exceptions or serialization warnings. When green, promote to production during a staffed window.
Hour 18–36: Validate and rotate
After production deploy, prove to yourself it’s clean. Hunt for anomalies during the vulnerable window: spikes in 5xx around server action endpoints, requests with unusual content types or large payloads to RSC routes, or odd process ancestry on hosts (unexpected shells, node children that aren’t yours). If you find any indicator of compromise, rotate credentials (cloud access keys, DB passwords, JWT signing keys) and purge long‑lived tokens. Assume anything accessible to the app could have been read if you saw signs of execution.
If your runtime is containerized, rescan images and nodes; compare the production digest to the expected immutable artifact. Lock the known‑good image and block drift using deployment policies until the incident window closes.
Hour 36–48: Close the loop
Finish the paper trail: changelog entry, incident doc, and a short Loom or README for future on‑call context. Add a regression test that asserts patched versions in CI and fails on downgrade. If you maintain multiple services, centralize the dependency policy so all RSC consumers pin to fixed ranges.
People ask us...
How do I know if my app actually uses RSC?
Look for a Next.js app/ directory, server actions, or any react-server-dom‑* in your lockfile. If your framework docs mention “React Server Components,” you likely implement the protocol even if you never wrote an explicit server function. When in doubt, deploy the patched framework anyway; the cost is trivial compared to the risk.
Are Pages Router apps or Edge Runtime affected?
Pages Router and the Edge Runtime aren’t impacted by the RSC protocol flaw described here. That said, teams often run mixed apps or shared packages. Verify at the repo and image level—don’t rely purely on project structure.
Can I mitigate at the edge or with a WAF instead of upgrading?
No. An edge rule might reduce exploit noise, but it’s not comprehensive and it’s brittle under protocol variations. The only reliable fix is to upgrade to the patched React and framework versions.
The quick version map (paste this into the ticket)
React patched versions: 19.0.1, 19.1.2, 19.2.1. Next.js patched versions: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7 (and canaries 15.6.0‑canary.58, 16.1.0‑canary.12). If you’re on unstable 14.3.0‑canary.77 or later, get off that train—either stabilize on 14.x or upgrade to a patched 15/16 release. These numbers matter; use them exactly.
Post‑patch: how to prove you’re clean
Because this is an RCE, treat validation seriously. Practical checks you can run today:
- Audit server and function logs over the exposure window for spikes in 5xx,
SyntaxError/deserialization exceptions, or unknown routes targeting server actions. - Search process trees for suspicious binaries, crypto miners, or shells spawned by the app process. If you find any, assume credential exposure and begin containment.
- Compare active containers or hosts against your deployment manifest. Any drift from known‑good digests or AMIs deserves investigation.
- Rebuild from source with patched deps and redeploy to replace any potentially tainted runtimes. Immutable infrastructure speeds this up; if you don’t have it, schedule the migration.
If you want a deeper remediation sequence, our earlier write‑up on a week‑long response plan covers forensics and guardrails beyond the first two days. See our 7‑day React Server Components fix playbook for the extended checklist.
How we got here (and how to avoid a repeat)
The RSC protocol shifts work to the server for performance and developer ergonomics. The trade‑off: everything riding that protocol becomes part of your trusted compute path. Serialization formats, edge adapters, and framework helpers aren’t just plumbing—they’re security boundaries. When a deserialization flaw exists at the protocol layer, the exploit surface spans every framework implementing it.
That’s why the long‑term answer includes people and process, not only patches. Consider this hardening checklist for teams that build with RSC:
- Pin transitive dependencies that define wire protocols (like react-server-dom‑*). Floating transitive versions are convenient until they aren’t.
- Gate RSC‑related upgrades behind smoke tests that exercise server actions and SSR paths. If you don’t have them, write two or three tiny tests now; they’ll pay for themselves.
- Adopt SBOM generation in CI and track critical packages over time. Even basic tooling that flags “RSC protocol changed” is useful.
- Prefer immutable infrastructure: deploy images by digest, forbid in‑place mutations, and use allowlists for egress so compromised apps can’t exfiltrate freely.
- Decide your release channel policy. If you rely on canaries for features, mirror production and keep canary pins explicit with a documented rollback path.
- Practice key rotation. It’s easy to say and hard to do under fire; automate what you can so rotation isn’t a second incident.
For a deeper root‑cause analysis of this class of bug and the RSC protocol’s attack surface, read our technical breakdown: what to patch and why this broke.
What leadership needs to know
Risk: this is unauthenticated code execution on the server, not a client‑side bug. If exploited, attackers can read environment variables, pivot to data stores, and drop persistent implants. The good news is that upstream fixes are available and narrow in scope; a focused 48‑hour push resolves the acute risk. Expect a short, planned maintenance window and some developer time to validate adjacent services.
Budget: most teams can deploy this as a standard dependency bump plus a one‑time audit of secrets and logs. The cost driver is staff time, not new tooling. If you discover compromise, factor in key rotation and incident response hours.
Roadmap: don’t pause feature work indefinitely. Finish the patch and validation, then invest a sprint or two in security hygiene: SBOM automation, version pinning, and immutable deploys. These actions reduce blast radius the next time a core protocol changes.
Let’s get practical: commands and checks
Use your package manager’s selective upgrades to minimize diff noise:
- NPM:
npm install [email protected] [email protected] [email protected](adjust versions per your release line). - PNPM:
pnpm up [email protected] [email protected] [email protected] -r. - Yarn:
yarn add [email protected] [email protected] [email protected].
After deploy, validate expected versions in production by printing process.versions and inspecting node_modules metadata in the built image (or use your SBOM tool). Confirm cache invalidation at the edge so users aren’t served stale code paths.
What to do next
Developers:
- Patch to a fixed React and Next.js release now and redeploy with immutable artifacts.
- Audit logs for unusual RSC traffic and rotate secrets if you see anything suspicious.
- Add a CI check that fails builds if vulnerable RSC versions are introduced.
Engineering leaders:
- Schedule a two‑day incident window and track it like an outage: owner, timeline, success criteria.
- Fund one sprint for supply‑chain hygiene: SBOM, version pinning, and a minimal RSC test harness.
- Engage a partner for a focused hardening review if you run sensitive workloads. Our security and cloud hardening services cover this playbook end‑to‑end.
Where we can help
If you’re juggling multiple services and compliance constraints, we can triage and patch with you, then build the guardrails to keep you safe. Start with an initial consult via our contacts page, browse examples in our portfolio, or keep learning on our blog. If you need deeper RSC context first, read our 7‑day fix playbook and the technical root‑cause article on React2Shell.
Bottom line
Patching this React Server Components vulnerability is a two‑day job with the right sequence: inventory, upgrade, validate, rotate, and document. Treat it as a small incident, not a multi‑week fire drill. Get current, prove it, and then invest a small slice of time in the supply‑chain guardrails that will make the next protocol‑level surprise far less dramatic.
