React2Shell is the primary keyword you need to care about right now. On December 3, 2025, the React team disclosed CVE‑2025‑55182—an unauthenticated RCE in React Server Components (RSC) affecting react‑server‑dom‑* packages in React 19.0 through 19.2.0. A week later, on December 11, two more RSC issues were published: CVE‑2025‑55183 (source code exposure) and CVE‑2025‑55184 (DoS). Next.js tracked the upstream bug as CVE‑2025‑66478 for App Router apps. Hosting providers rolled out mitigations, but that doesn’t replace patching. Here’s what changed, what’s still at risk, and a concrete plan to patch, prove, and harden—without derailing your roadmap.
What changed since December 3?
First, the fix for the original React2Shell RCE shipped on December 3 in React 19.0.1, 19.1.2, and 19.2.1 for the affected RSC packages. Second, research following the patch surfaced two additional vulnerabilities on December 11: a high‑severity Denial of Service and a medium‑severity source code disclosure. Importantly, those follow‑ups do not re‑enable remote code execution if you’re on the patched lines, but they do mean staying current is not optional. Third, ecosystems moved quickly: Next.js published downstream advisories and patched release lines; Deno shipped a runtime‑level mitigation for the DoS variant in Deno Deploy the same day; multiple security orgs reported broad scanning and opportunistic attempts.
For leaders: this compresses your timeline. The window between disclosure and mass scanning was measured in hours, not weeks. Expect customers to ask for attestation that your internet‑facing RSC endpoints are no longer exploitable—and that you’ve addressed the follow‑up CVEs too.
Who’s actually vulnerable?
Here’s the thing: the exploit path is in the RSC protocol, not your business logic. That means:
• You’re vulnerable if your app supports React Server Components on a server (Next.js App Router; frameworks or bundlers integrating React’s RSC runtime; self‑hosted Node environments running RSC).
• You’re not vulnerable if your React app is purely static (no server) or you’re not using a framework/bundler that supports RSC.
Next.js specifics: default App Router apps (13.3+ through 16, plus later 14.x canaries) integrate the RSC runtime. If you self‑host and expose the app directly to the internet, prioritize patching and compensating controls. If you’re on a managed platform with a web application firewall, you still need to patch—provider mitigations reduce risk but don’t eliminate it.
React2Shell: the short, factual timeline
• November 29, 2025: Vulnerability privately reported to Meta/React.
• December 3, 2025: Public advisory and patched releases for the RCE (CVE‑2025‑55182). Next.js publishes a downstream advisory (CVE‑2025‑66478).
• December 4–6, 2025: Multiple proof‑of‑concepts appear; broad scanning observed.
• December 11, 2025: Two additional RSC CVEs disclosed: CVE‑2025‑55183 (source exposure) and CVE‑2025‑55184 (DoS). Next.js publishes an accompanying security update. Deno Deploy ships a runtime mitigation for DoS.
“But our app doesn’t use Server Actions—do we still need to patch?”
Yes. The original advisory makes it explicit: apps can be vulnerable even if they don’t implement Server Actions or custom Server Function endpoints. If your framework supports RSC and the affected packages are present, treat it as exploitable until you update.
How to tell if you’re exposed (fast)
Start with what you actually run in production, not what’s in the monorepo. Pull the exact package.json and lockfile from each deployed artifact. Then:
• Inspect your dependency tree for RSC packages: `react-server-dom-webpack`, `react-server-dom-parcel`, or `react-server-dom-turbopack`.
• Verify installed versions are patched: React 19.0.1, 19.1.2, or 19.2.1 for the RSC packages (or newer).
• If you run Next.js with the App Router, note your framework version and release line. Confirm you’re on a fixed build per Next.js’ security notes for December 3 and December 11.
On the network side, look for requests indicative of RSC payloads to dynamic routes. In Next.js, RSC responses often use the `text/x-component` content type and query strings with `_rsc=...` during navigations. Those patterns are legitimate—what you’re hunting for is anomalous request volume, unusual payload sizes, or bursts to endpoints that shouldn’t be callable unauthenticated.
Patch status by ecosystem
• React: Update the affected RSC packages to 19.0.1, 19.1.2, or 19.2.1 (or newer). This addresses the RCE (CVE‑2025‑55182). Apply the December 11 updates that close CVE‑2025‑55183 and CVE‑2025‑55184 on your track.
• Next.js: Follow the December 3 advisory (CVE‑2025‑66478) and the December 11 security update, then lock your builds to the fixed lines for your major version.
• Deno Deploy: Runtime‑level guardrails for the DoS were enabled December 11, but you should still update your app dependencies.
• Other RSC adopters: React Router RSC, Waku, Parcel RSC, Vite’s RSC plugin, Redwood SDK—check each project’s guidance and ensure your lockfiles carry the patched React packages.
Use this 7‑step Patch‑and‑Proof Checklist
Don’t just “npm update and hope.” You need to show evidence. Here’s a concrete workflow we’ve used with engineering teams this week:
1) Inventory what’s truly exposed
List every internet‑reachable service that renders React with RSC enabled. Include preview deployments. Record: domain, path patterns, framework version, and RSC package versions as deployed.
2) Pin and update
Pin React and affected RSC packages to the fixed lines in your package manager manifests. For Next.js, pin to the patched release for your major/minor. Avoid floating ranges that might resolve to an unfixed build in CI.
3) Rebuild from clean cache
Blow away caches that might retain old transitive deps. For Node, that means removing the lockfile and node_modules in a temporary branch to prove the resolver path, then restoring a locked, patched set. In CI, invalidate artifact caches so your build image doesn’t smuggle older RSC code into production.
4) Deploy in waves with guards
Stage rollouts behind a feature flag or routing rule. Keep a WAF or reverse proxy rule to rate‑limit and size‑limit RSC requests during rollout. If you can, add a simple allowlist check for authenticated RSC endpoints in administrative areas.
5) Verify at runtime
After deploy, sample responses and headers from a representative set of routes. Confirm the server process is loading the patched versions (e.g., print dependency versions at boot) and that your asset hashes changed. In Next.js, validate that the server instance actually restarted—not just the edge CDN layer.
6) Hunt for compromise
Search logs for spikes of requests to routes that return `text/x-component`, repeated POSTs with unusual sizes, or bursts from single IPs. On hosts, look for new system services, rogue Node processes, or shell histories you didn’t create. If miners or persistence are present, assume credential exposure: rotate secrets and invalidate tokens.
7) Capture proof
Package the bill of materials (SBOM), lockfile diffs, and deployment timestamps. Attach your runtime verification notes and log excerpts. Store them in your security evidence repository so customer security reviews and SOC 2 requests don’t burn cycles later.
Practical Next.js guidance
• App Router baseline: if your App Router app predates December 3, 2025 and hasn’t been redeployed with patched RSC packages, treat it as vulnerable. Update, rebuild, and redeploy.
• Self‑hosted Node: drop root, run with a restricted user, and enable a seccomp profile (or container runtime default). Lock down egress to only what your app needs. A successful RCE that can’t dial out is far less useful to an attacker.
• Proxies and CDNs: configure caching so RSC payloads aren’t cached as primary HTML (a known foot‑gun). Respect the framework’s `Vary` headers and avoid serving `text/x-component` to browsers directly.
People also ask: common questions we keep hearing
Do static exports need action?
If there’s truly no server and no RSC runtime at the edge, you’re not affected. Validate this is actually the case in production (no server, no SSR, no RSC).
Are provider mitigations enough?
No. WAF signatures and runtime mitigations reduce blast radius and can stop commodity probes, but they are not a substitute for updating the vulnerable packages. Treat them as seatbelts, not the brakes.
Do we have to rotate secrets?
If you find signs of exploitation or you cannot verify that vulnerable builds were never internet‑facing, yes—rotate. Prioritize cloud credentials, database passwords, OAuth secrets, and any long‑lived tokens.
What versions should we be on today?
React RSC packages at 19.0.1, 19.1.2, or 19.2.1 (or newer) for the original RCE. Apply the December 11 updates covering the DoS and source exposure on your track. Next.js users should be on the patched releases listed in the December 3 and December 11 security posts for their major version.
Operational guardrails to keep
• Lockfiles are contracts: regenerate only when you intend to, then pin.
• Prove what’s running: print dependency versions to logs at startup, and surface them on a protected health endpoint for verification.
• Least privilege hosts: non‑root, read‑only file systems, no shell tools in containers, and egress allow‑listing.
• Watch the protocol surface: treat RSC endpoints like APIs—rate‑limit, log, and alert on anomalies.
• Practice rollbacks: ship a canary, validate, then promote within a change window you control.
When you need a deeper plan
If you’re coordinating a multi‑app response or you already suspect compromise, use a structured plan. We’ve published step‑by‑step playbooks you can run with your team:
• A two‑week remediation and evidence plan: React2Shell: Your 14‑Day Patch and Proof Plan.
• A focused, post‑patch hardening pass: React2Shell Aftershocks: Patch, Verify, Lock Down.
• Next.js downstream specifics: Next.js CVE‑2025‑66478: Patch, Prove, Harden.
Zooming out: what this means for your roadmap
React Server Components are here to stay; the model is now stable in React 19, and framework adoption is only increasing. That makes the RSC protocol a durable part of your attack surface. Treat it like you treat your GraphQL or REST layer—observable, rate‑limited, and version‑pinned. Also, build “security SLOs” you can meet under pressure: 24 hours to inventory exposure, 48 hours to patch, 72 hours to deliver evidence to customers.
If you need hands‑on help testing and shipping patches without breaking releases, our team does this work weekly for product orgs shipping at scale. See our services or contact us to get an emergency slot.
What to do next
Here’s your short list for today:
• Confirm your production versions for React RSC packages and Next.js. If any are pre‑patch (pre‑Dec 3) or missing the Dec 11 updates, schedule a deploy window now.
• Pin, rebuild, redeploy—then verify at runtime. Save the evidence bundle (SBOM, lockfile diff, timestamps).
• Enable basic guards: rate‑limit RSC endpoints, cap request sizes, and ensure `text/x-component` payloads aren’t cached as HTML.
• Hunt for compromise: check logs for suspicious RSC request patterns and hosts for persistence. Rotate secrets if uncertain.
• Book a hardening pass this week. Don’t let the follow‑up CVEs stack up in your backlog.
React2Shell won’t be the last RSC‑related advisory, but it can be the last one that blindsides your team. Patch promptly, prove it clearly, and keep the small, boring protections in place. That’s how you ship fast and sleep well.
Want more hands‑on playbooks like this? Browse our latest posts on the blog or learn about how we ship secure upgrades in client portfolios on our portfolio page.
