React2Shell: Patch Now—A Pragmatic Playbook

React2Shell is the kind of bug that stops roadmaps. A critical remote code execution in React Server Components (RSC) and downstream frameworks like Next.js, it was publicly disclosed on December 3, 2025 with a maximum CVSS score of 10.0 and patches released the same day. Exploits emerged shortly after. If you operate any RSC app—especially Next.js 15.x or 16.x with the App Router—treat this as an incident, not a routine dependency bump.

What happened, exactly?

On November 29, 2025, a researcher reported a vulnerability in the RSC protocol that allowed attacker-controlled requests to be decoded in a way that could lead to server-side code execution. Fixes were published on December 3, 2025 for React 19 (19.0.1, 19.1.2, 19.2.1). Next.js issued patched releases the same day across supported lines: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, and 16.0.7. If you ran an affected app in production on or after the disclosure window, assume probing and plan secret rotation once you patch.

Two CVEs track the issue: CVE‑2025‑55182 (React) and CVE‑2025‑66478 (Next.js downstream impact). The flaw centers on unsafe handling of serialized data sent to server functions in RSC. In practical terms: a crafted request can push your server into running code paths you didn’t intend.

Am I affected?

Use this quick decision tree:

• Next.js App Router on 15.x or 16.x? Yes—affected. Patch to your line’s fixed version immediately.
• Next.js 14 canary after 14.3.0‑canary.76? Affected. Either upgrade to a patched 15/16 or drop to stable 14.x.
• Next.js Pages Router (classic) or Edge Runtime only? Not affected by this specific RSC issue, but still review your dependency tree.
• Other RSC stacks (React Router RSC, Vite RSC, Parcel RSC, Waku, etc.)? Affected—update to React 19.0.1/19.1.2/19.2.1 and your framework’s patched version.

React2Shell: your 24‑hour triage checklist

The goal in Day 0 is to get safe quickly without creating new outages. Do this in order:

1. Inventory quickly. Search repos and images for react-server-dom-* and framework versions. In monorepos, scan lockfiles and containers. Flag every public endpoint using RSC.
2. Freeze deploys to vulnerable versions. Block merges of unpatched Next.js or RSC packages in CI while you remediate.
3. Patch the app—don’t rely on the WAF. For Next.js, upgrade within your release line:

   npm i [email protected]    # if on 15.0.x
   npm i [email protected]
   npm i [email protected]
   npm i [email protected]
   npm i [email protected]
   npm i [email protected]
   npm i [email protected]    # if on 16.0.x

   If you need a guided bump, run npx fix-react2shell-next. For other stacks, bump React to 19.0.1, 19.1.2, or 19.2.1 accordingly.
4. Redeploy everything that serves traffic. That includes preview/staging apps exposed to the internet. Patch and redeploy workers, serverless functions, containers, and any long‑lived instances.
5. Add temporary mitigations while you roll. Turn on or tighten WAF rules. Managed platforms (Akamai/Fastly/Cloud Armor and hosting providers) published virtual patches; enable them but don’t treat them as the fix.
6. Traffic review. Inspect logs since December 3 for unusual _rsc or server function endpoints, odd payloads, spikes in 5xx, or new outbound connections. Tag suspicious IPs and request patterns.

If your app was publicly reachable and unpatched on December 4, 2025 at roughly 1:00 PM PT, plan to rotate secrets after you deploy the fix. That includes environment variables, API keys, DB credentials, and tokens. Prioritize high‑blast‑radius secrets first.

72‑hour hardening: go beyond the hotfix

Now that you’ve stopped the bleeding, make it stick:

1. Pin and audit dependencies. Lock patched versions in package.json and regenerate the lockfile. Add CI checks that fail builds if vulnerable versions reappear.
2. Turn on defense‑in‑depth. Keep WAF rules active for a week while new exploit variants circulate. Add allowlists around server function endpoints where feasible.
3. Secrets rotation and blast‑radius reduction. Rotate anything the app could access. Move long‑lived keys to short‑lived, scoped credentials where possible; enforce least privilege on service accounts.
4. Runtime policy. If you’re on containers or serverless, set outbound egress controls, read‑only filesystems, and process/ptrace restrictions. Even if an attacker got a foothold, limit lateral movement.
5. Observability coverage. Add structured logging around server function entry points; forward to your SIEM. Create alerts on anomalous call volumes and payload sizes.
6. Chaos test and rehearse. In a non‑prod environment, simulate noisy RSC traffic to validate that WAF + app still behave and that alerts actually fire.

7‑day audit: validate, document, and prevent regressions

By the end of the week, you should be able to answer these questions confidently:

• When did we first become vulnerable, when did we patch, and which environments were exposed?
• Which secrets were rotated, and which still need work?
• What telemetry and rules are in place to catch future RSC abuse?
• How will we prevent accidental downgrades or canary reintroductions?

Codify the answers in a short post‑incident doc. Add a regression test: a CI step that rejects vulnerable versions and a security linter that flags RSC endpoints for review.

People also ask: does a WAF fully protect me from React2Shell?

No. WAFs and managed virtual patches reduce risk while you patch, but attacker payloads evolve. Multiple providers shipped emergency rules within hours to days; use them, monitor for false positives, and keep them enabled for at least a week after patching. But the only durable fix is upgrading your framework and React packages.

People also ask: are Pages Router apps affected?

Classic Pages Router apps that don’t use RSC are not directly affected by this flaw. That said, many teams mix App Router features into legacy projects or run preview builds with experimental flags. Verify your codebase and lockfile rather than assuming you’re safe.

People also ask: how do I verify I’m actually patched?

Three checks:

1. Dependency diff: npm ls next react-server-dom-webpack react and confirm patched versions (Next.js fixed versions listed above; React 19.0.1/19.1.2/19.2.1).
2. Build banner: Confirm your build output references the patched framework release.
3. Runtime check: Log framework versions on boot and expose to a protected health endpoint for verification.

Why React2Shell broke things: the short version

RSC relies on a protocol that serializes and deserializes values between the client and the server. The vulnerable path allowed crafted inputs to influence server behavior during decoding. Combine that with reachable server function endpoints and you have pre‑auth code execution. It’s a reminder that serialization boundaries are security boundaries—treat them as such, and keep the attack surface small.

Platform notes: Vercel, Netlify, Cloud, and friends

Several hosting and cloud providers pushed emergency mitigations (for example, WAF signatures and deploy blocks). If you run on a managed platform, enable their protections, but still patch and redeploy your code. Don’t forget non‑production environments—pull‑request previews, staging, and sandboxes count if they’re internet‑exposed.

React2Shell hardening framework you can reuse

Here’s a lightweight framework I use with teams after any critical RCE in a web framework. Keep it somewhere visible:

1. Identify: Inventory affected apps, endpoints, and packages. Tag critical paths and internet exposure.
2. Contain: Freeze deploys of vulnerable code, enable WAF/IDS, reduce egress, and throttle suspicious traffic.
3. Eradicate: Upgrade to patched versions, redeploy all ingress paths (functions, containers, workers), and invalidate caches.
4. Recover: Rotate secrets, verify data integrity (audit logs, DB checks), and restore normal deploy cadence.
5. Improve: Add CI guards, write a short incident report, and schedule a dependency hygiene task monthly.

What to do next (developers)

• Run npx fix-react2shell-next (Next.js) or upgrade React to a fixed version if you’re using another RSC stack.
• Redeploy every environment that accepts traffic—including previews. Confirm versions at runtime.
• Enable provider WAF rules and keep them on for at least a week.
• Rotate high‑value secrets if you were exposed during December 3–6, 2025.
• Add a CI job that fails builds on vulnerable RSC/Next.js versions.

What to do next (engineering leaders)

• Timebox a 48–72 hour mitigation window and clear sprint capacity for it.
• Ask for a one‑page incident note with dates, impacted apps, and follow‑ups.
• Budget a small recurring task for dependency hygiene and runtime policy.
• Consider a retainer with a security partner for high‑severity triage.

Need a deeper dive?

If you want a blow‑by‑blow of the earlier RSC insecurity pattern and a weeklong remediation plan, our practical guide still applies—start with a hands‑on seven‑day fix for the React Server Components vulnerability. For a more opinionated take on this incident, see React2Shell: what to patch now and why it broke. And if you’d rather not do this alone, here’s how we help teams ship safely under pressure: secure engineering services and sane escalation paths.

Gotchas and edge cases we’ve seen this week

• Invisible exposure via previews. Teams often forget that every pull request spawns a public preview URL. Patch and redeploy those too, or restrict access temporarily.
• Stale lambdas/functions. Serverless platforms may keep old versions warm. Force a full redeploy or version invalidation, not just a code push.
• “We’re on 14, so we’re fine.” Some organizations quietly adopted 14.x canaries to test PPR. Those builds can be vulnerable. Check your actual deployed lockfiles.
• Containers with cached layers. If your base image captured vulnerable npm layers, bump and rebuild with --no-cache.
• Third‑party integrations. If partners hit your server function endpoints, coordinate maintenance windows and rotate any tokens you issued.

Zooming out: what this means for your stack

Server‑heavy UI patterns are here to stay, but they widen the blast radius of serialization bugs. Treat server function endpoints like APIs: rate‑limit them, authenticate where sensible, and log aggressively. Keep an eye on future RSC changes—when the plumbing evolves, so do the edge cases.

Here’s the thing: incidents like React2Shell are where engineering culture shows. Teams that patch quickly share three habits—clear ownership, boring automation, and good hygiene. If you’re missing any of those, this is your nudge to fix it.

Where to go from here

Don’t let this become a slow‑burn risk. Patch today, harden this week, and prevent regressions next sprint. If you need context on broader platform choices while you’re here, our recent pieces on cloud and app strategy can help—from practical multicloud planning to shipping AI features safely on Bedrock. Different topic, same muscle: clear steps, controlled risk, measurable outcomes.