React2Shell (CVE-2025-55182): 72‑Hour Patch Plan

React2Shell (CVE‑2025‑55182) is a maximum‑severity remote code execution flaw in React Server Components (RSC). If you’re on React 19 with RSC—directly or via frameworks like Next.js App Router—you must upgrade now. Patches shipped as React 19.0.1, 19.1.2, and 19.2.1, and downstream Next.js fixes landed across supported 15.x and 16.x lines. Public proofs‑of‑concept surfaced within days of disclosure, and automated scanners are already trawling the web. This piece gives you a concise, field‑tested plan to get safe in 72 hours without breaking your roadmap.

What just happened? Key dates, impact, and who’s affected

Here’s the timeline that matters to your team. On November 29, 2025, the issue was privately reported to the React team. On December 3, 2025, the vulnerability was disclosed with patches for the affected RSC packages: react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack. In the following days, exploit code became public and several security teams observed scanning and exploitation attempts in the wild. That compressed window is why you’re seeing urgent advisories from vendors and clouds.

Impacted software and fixed versions you can act on today:

• React RSC packages: vulnerable in 19.0, 19.1.0, 19.1.1, 19.2.0; fixed in 19.0.1, 19.1.2, 19.2.1.
• Next.js App Router: affected across 15.x and 16.x; patched lines are available (e.g., 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7). Edge Runtime and Pages Router are not in scope.

Are you affected even if you never wrote Server Actions? Possibly. If your framework enables RSC by default, the vulnerable code path can exist even without custom endpoints. That’s the trap here: configuration and defaults matter as much as your application code.

React2Shell (CVE-2025-55182) at a glance

At its core, React2Shell is an unsafe deserialization bug in the RSC protocol. An attacker can send a crafted request to a server function endpoint and get code to run on the server—pre‑auth. That’s a clean RCE: no tricksy chains or edge‑case headers required. Because RSC is a protocol used by multiple bundlers and frameworks, the blast radius spans more than one package or vendor.

Quick check: am I in the blast radius?

Run these checks before you declare victory:

• Does your repo include any react-server-dom-* dependency at versions 19.0, 19.1.0, 19.1.1, or 19.2.0? Search lockfiles and container images.
• Are you on Next.js 15.x or 16.x with the App Router? If yes, assume vulnerable until you land the patched release on your line.
• Is your app deployed as a serverful Node.js process (not pure static export)? If so, prioritize this patch ahead of UI‑only tasks.
• Did you scaffold with defaults (e.g., create‑next‑app) during the React 19 era? Treat those apps as in scope.

Your 72‑Hour React2Shell Response Playbook

Here’s a sequence we’ve used with real teams. It minimizes downtime, keeps risk bounded, and avoids dead ends.

Hour 0–6: Freeze, find, and filter

• Implement a change freeze for all internet‑facing services using React/Next.js.
• Inventory vulnerable packages: grep -R \"react-server-dom-\" in source and npm ls | grep react-server-dom in builds. Don’t forget monorepos and Docker layers.
• Turn on or tighten your WAF managed rules. Most major providers shipped emergency signatures that flag/block RSC exploit payloads. Use them for breathing room, not as a substitute for patching.
• Log tailing: watch for spikes in POSTs to RSC endpoints, unusual content-type combinations, or suspicious action headers. If you have centralized logs, add a real‑time dashboard to keep eyes on attempted probes.

Hour 6–24: Patch React and Next.js, then verify

For React projects using RSC directly:

# npm\ nnpm install [email protected] [email protected] [email protected]\nnpm install react@latest react-dom@latest\n\n# yarn\nyarn add [email protected] [email protected] [email protected]\n\n# pnpm\npnpm add [email protected] [email protected] [email protected]

For Next.js App Router apps, jump to your patched line and clear duplications in your node_modules tree:

# Examples—pin to your maintained branch\nnpm install [email protected]  # or 15.5.7 / 15.4.8 / 15.3.6 / 15.2.6 / 15.1.9 / 15.0.5\n\n# ensure React is consistent\nnpm install [email protected] [email protected]\n\n# clean + rebuild to avoid stale transitive deps\nrm -rf node_modules package-lock.json && npm ci && npm run build

Verification checklist before you roll:

• Lockfiles: package-lock.json/yarn.lock/pnpm-lock.yaml reflect patched versions only (no duplicate vulnerable ranges).
• Bundle analysis: your server bundle resolves to the patched RSC packages. If you’re on a monorepo, run dependency dedupe.
• Smoke tests: SSR pages, dynamic routes, and Server Actions still work. Pay special attention to streaming responses and form actions.

Hour 24–48: Hunt for compromise, rotate secrets

• Scan logs for suspicious requests to RSC endpoints (for example, requests carrying action identifiers or atypical payloads), spikes in 5xx near disclosure dates, and any anomalous child process execution on app hosts.
• Rotate application secrets (.env, API keys, tokens) that could be present on compromised hosts. Assume the worst for internet‑facing instances from December 3 onward.
• Rebuild containers from a clean base image. Don’t apt‑get install your way out of this—immutability matters.
• Add explicit outbound egress rules to block unexpected callbacks from compromised workloads while you complete the patch cycle.

Hour 48–72: Harden, observe, and unfreeze

• Deploy the patched builds to all regions and environments. Avoid canaries that leave a vulnerable zone unprotected on the public internet.
• Enable or tune WAF analytics to alert on future RSC exploit attempts. Keep the rules on for at least two weeks.
• Backfill SCA (software composition analysis) into CI to block merges that re‑introduce vulnerable versions. Make \"block on critical\" your default posture.
• Run a blameless retro: where did detection lag? How quickly could you roll a coordinated bump in a monorepo? Document the answers.

How to patch correctly (and avoid gotchas)

Most missed patches trace back to version drift and transitive deps. Here are the sharp edges:

• Duplicate trees: In monorepos, one package.json can pin a patched RSC while another holds the vulnerable range. Use npm dedupe or your workspace tool’s resolutions to force a single patched version.
• Partial upgrades: Upgrading Next.js without aligning react and react-dom can leave you with a hybrid dependency graph that still resolves to old RSC packages. Pin React 19.2.1+ alongside the Next.js fix.
• Lockfile staleness: CI often caches lockfiles. Purge caches, npm ci from scratch, and verify the resolved graph in the build logs.
• Container layering: Multi‑stage Dockerfiles can hide outdated lockfiles in earlier layers. Rebuild with --no-cache.

“Do WAFs save me?” The short answer

WAF vendors and clouds pushed emergency signatures for React2Shell within hours of disclosure. Turn them on—they’re valuable. But treat them as airbags, not seatbelts. Signatures can miss variants, and a single bypass leaves you exposed. The only complete fix is upgrading to the patched React and Next.js versions. Keep WAF rules enabled for visibility and insurance while you patch and monitor.

Detection tips: What should I look for in logs?

Start with your web access logs and application logs around December 3–10, 2025. You’re looking for requests that target RSC endpoints or demonstrate unusual payloads and follow‑on behavior.

• Spikes in POST requests to RSC‑related routes, especially around disclosure dates.
• Suspicious headers or parameters suggesting an RSC action invocation.
• Application logs showing unexpected child_process, file writes in /tmp or your app directory, or encoded payloads (base64/hex) immediately after odd requests.
• WAF/edge logs flagging newly added rules that reference the React CVE.

If anything looks off, assume compromise and proceed with containment: isolate the host, snapshot forensics, rotate credentials, and redeploy from a known good state. Our earlier playbook for package ecosystem incidents includes a solid containment checklist—see our 72‑hour recovery plan for npm attacks and adapt it to this context.

People also ask

Is React 18 affected by React2Shell?

No. The vulnerability is in the React 19 RSC packages listed above. If you’re on React 18 without RSC, you’re not in scope. Still, audit your dependencies to be sure nothing pulled in an RSC preview or plugin.

Are static‑exported sites affected?

Pure static exports with no server runtime are not affected by a server‑side RCE. Verify that your deployment doesn’t invoke a Node.js server for SSR, API routes, or server actions.

Can I disable RSC to mitigate instead of upgrading?

In many frameworks there’s no reliable configuration switch that fully removes the vulnerable code path while keeping your app functional. The safe path is to upgrade to the patched versions.

Are Next.js Pages Router and the Edge Runtime impacted?

Pages Router and the Edge Runtime are not implicated in this RCE. The issue centers on the App Router’s use of the RSC protocol with the affected React 19 packages.

Post‑incident hardening: make the next patch easy

Here’s the thing: this won’t be the last urgent patch. The teams that ride these storms best build muscle around inventory, controlled rollouts, and automated policy.

• SBOM by default: Generate a software bill of materials on every build. Store it. Make it searchable. Tie it to deployments so you can answer “where are we vulnerable?” in minutes, not days.
• Block on criticals in CI: Wire your SCA tool to fail builds on critical advisories for production branches. Allow controlled overrides with an expiry if you absolutely must ship.
• One‑click dependency rollouts: Maintain automation to bump, test, and deploy dependency patches across services (a bot + CI template works wonders in monorepos).
• Golden base images: Rebuild images weekly; avoid hand‑patched servers. Use immutable infrastructure so rollback is a redeploy, not a midnight SSH session.
• Runtime guards: Keep emergency WAF signatures on and alerting. Pair them with anomaly detection for process launches and outbound egress.

If you run a portfolio of apps and need a repeatable capability model for these events, our team has shipped this pattern across startups and large enterprises. See how we approach production‑grade delivery on our What We Do page and browse recent work in our portfolio.

What to do next (developers)

• Patch today: upgrade React to 19.0.1/19.1.2/19.2.1 and Next.js to the fixed version in your line.
• Verify: dedupe lockfiles, rebuild clean, and confirm no vulnerable transitive deps remain.
• Monitor: enable emergency WAF rules and create alerts for suspicious RSC requests.
• Hunt: review logs from December 3 onward; rotate secrets if exposure is possible.
• Automate: add SBOM+SCA gates in CI so the next dependency RCE is a routine bump, not an all‑hands.

What to do next (business & product leaders)

• Authorize a short change freeze while patches land across environments.
• Fund the boring work: SCA licensing, SBOM storage, and dependency automation are cheap compared to breach response.
• Hold a retro focused on time‑to‑inventory and time‑to‑patch. Set service level objectives for both.
• Decide ownership: security can advise, but engineering owns patching SLAs.

Need a second set of hands?

If you’re staring at a mixed fleet of apps, we can help you inventory, patch, and harden without grinding product to a halt. Start with our concise backgrounder on RSC risks—React Server Components: 48‑Hour Fix—then get in touch via engineering services or contact us. We’ll bring a playbook that’s pragmatic, battle‑tested, and tailored to your stack.

Bottom line

React2Shell (CVE‑2025‑55182) is the kind of bug that collapses the distance between a small oversight and a production incident. The fix is straightforward: upgrade React’s RSC packages and, if you’re on Next.js App Router, move to your patched line. The work is everything around it—inventory across repos, lockfile hygiene, clean rebuilds, and honest monitoring. Take the 72‑hour plan above, run it now, and keep the automation in place. You’ll sleep better the next time a CVE drops on a Wednesday afternoon.