React Server Components Vulnerability: 72‑Hour Plan

On December 3, 2025, the React team disclosed a critical remote code execution issue in React Server Components—now tracked as CVE‑2025‑55182 with a CVSS score of 10.0. If your apps use React 19 RSC or frameworks that integrate it (notably Next.js App Router), you must treat this like an incident, not routine patching. React shipped fixes in 19.0.1, 19.1.2, and 19.2.1; Next.js shipped patched lines across 15.x and 16.x. (react.dev)

Within 48 hours, the ripple effects were obvious: Cloudflare briefly broke its own dashboard while fast‑tracking a firewall mitigation tied to the disclosure, a good reminder that emergency controls can have side‑effects. That outage resolved quickly, but the message for engineering leaders is clear—plan for both the fix and the fallout. (reuters.com)

What changed this week: dates, versions, and scope

Here’s the timeline you can share with your execs and customers:

Dec 3, 2025 — React discloses CVE‑2025‑55182 (RSC RCE). Affected packages: react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack in 19.0.0, 19.1.0, 19.1.1, and 19.2.0. Fixed versions: 19.0.1, 19.1.2, 19.2.1. (react.dev)

Dec 3–4, 2025 — Next.js issues an advisory for App Router users; patched versions include 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, and 16.0.7. Canary users starting at 14.3.0‑canary.77 should downgrade or move to a fixed line. (github.com)

Dec 4–5, 2025 — National CERTs and security vendors publish advisories and WAF guidance, noting the risk to downstream frameworks and plugins (Vite/Parcel RSC, React Router preview, Redwood, Waku). Some advisories report exploitation attempts; regardless, treat internet‑exposed RSC as actively targeted. (cert.europa.eu)

Who’s actually affected—and how to check fast

If you’re on React 19 and have RSC enabled—or you run Next.js with the App Router—you’re squarely in scope. The twist: you can be vulnerable even if you don’t explicitly use Server Functions; the underlying RSC plumbing can still be reachable. (react.dev)

Quick triage checks

Start with your production artifacts, not just repo HEAD. If you build many microfrontends or have separate SSR renderers, inventory each service:

• Inspect lockfiles and containers: npm ls react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack for the deployed commit. Look for 19.0.0/19.1.0/19.1.1/19.2.0.
• For Next.js, query the exact runtime version: node -e "console.log(require('next/package.json').version)" in the running container or instance.
• Search your code for RSC/Server Actions usage and any custom Server Function endpoints exposed via adapters.

Downstream risk exists for frameworks bundling RSC pieces: Vite and Parcel RSC plugins, React Router’s RSC preview, Redwood SDK, and Waku. Track and upgrade those transitive deps too. (cert.europa.eu)

React Server Components vulnerability: the 72‑hour incident playbook

Here’s a pragmatic, time‑boxed plan we’ve used on real incidents. Adapt the checklists to your SDLC and change windows, but stay inside the 72‑hour envelope.

Hour 0–6: Stabilize and reduce blast radius

Goal: make exploitation harder while you prepare verified upgrades.

• Freeze non‑essential deploys. Tag the release you’ll patch against and notify stakeholders of emergency change windows.
• Put a protective ring around RSC endpoints. If you front with a WAF, enable the vendor’s emergent rule set for this CVE. Cloudflare, Radware, and others pushed rules quickly; validate they’re actually being hit in logs. Expect some false positives. (reuters.com)
• Restrict by identity where feasible: require session auth for any Server Function invocation paths and enforce method allowlists for those routes.
• If you run centralized ingress (Kubernetes or multi‑tenant edge), isolate RSC traffic paths and apply temporary rate limits and anomaly detection per path. Our 90‑day ingress playbook has a good pattern library you can adapt for emergency routing.

Hour 6–24: Patch with the exact fixed versions

Goal: upgrade deterministically and prove the vulnerable code is gone.

• React: bump to 19.0.1, 19.1.2, or 19.2.1 for the react-server-dom-* packages. Don’t rely on caret ranges—pin and commit. (react.dev)
• Next.js App Router: move to a patched release line: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, or 16.0.7. If you’re on canary builds from 14.3.0‑canary.77 or later, downgrade to the latest 14.x stable or jump to a fixed 15/16 line. (github.com)
• Regenerate lockfiles and rebuild containers to eliminate stale layers. Verify at runtime (containers, lambdas, or edge functions) that the fixed versions are loaded.
• Stand up a one‑off canary in production with WAF in “observe” mode for an hour, then roll forward region by region.

Hour 24–48: Verify closure and hunt for exposure

Goal: ensure you didn’t just “update”—you remediated.

• Run SCA and advisory checks: npm audit, Dependabot, and GitHub Advisory DB for GHSA‑tracked items tied to CVE‑2025‑55182. (github.com)
• Add a targeted security test: replay a harmless synthetic request matching known RSC exploit traffic shape and confirm it’s rejected at the app and the WAF.
• Greedy log search: cluster 48 hours of logs for anomalous requests to Server Function endpoints from new ASNs or TOR exit nodes. If anything looks off, treat it as potential compromise and do forensics.
• If you’re on managed platforms (Vercel, Cloudflare, Netlify), confirm their advisories and platform mitigations; don’t assume they patched your app’s dependencies. (community.vercel.com)

Hour 48–72: Hardening you should keep

Goal: reduce the chance the next deserialization bug burns your weekend.

• Enforce auth and least privilege for server actions: require authenticated sessions and scope tokens for any tool/action the server can perform.
• Adopt request‑level allowlists for RPC‑style endpoints and limit accepted content types. Treat RSC traffic as privileged RPC, not a public API free‑for‑all.
• Keep the WAF rule active in block mode for a week. Consider a per‑route rate limit based on historical 95th percentile.
• Instrument end‑to‑end observability for agents and server actions as first‑class workloads so you can spot bizarre tool invocations quickly. If you’re building AI agents, we’ve covered operational guardrails in our Cloudflare AI Bot Protection guide and an AgentCore adoption playbook.

People also ask: common questions we’re hearing

Are Next.js 14 apps affected?

The official advisory calls out Next.js 15.x and 16.x, plus canary builds starting at 14.3.0‑canary.77. If you’re on stable 14.x and not pulling RSC canaries, you’re outside the explicit affected set—but audit transitive dependencies and confirm RSC isn’t enabled. When in doubt, upgrade the React RSC packages and avoid risky canaries. (github.com)

Can I rely on a WAF instead of patching?

No. WAF rules are a speed bump, not a fix. They buy you time and visibility, and they can reduce exploit surface (several vendors pushed emergency signatures), but you still need the patched packages live in production. (radware.com)

We’re on a managed edge or PaaS—are we covered?

Platform providers applied mitigations at the edge, but they can’t rewrite your lockfile. Follow their advisories, then verify your app resolves to fixed versions at runtime. Cloudflare’s quick firewall change—and its small self‑inflicted outage—shows platforms will move fast, which may affect your operations while you patch. (reuters.com)

Why this happened: the architecture insight

RSC’s power comes from the “Flight” protocol that lets the client trigger work on the server, streaming component trees and server actions back and forth. The flaw that React fixed centered on how RSC decoded untrusted payloads reaching Server Function endpoints—classic deserialization risk territory. That means the bug isn’t just “in React” in the abstract; any framework that wired up those vulnerable packages inherited the issue. (react.dev)

Here’s the thing: the more we turn UI frameworks into distributed systems with client‑triggered server execution, the more those edges begin to look like RPC interfaces—and they deserve the same discipline you’d apply to an internal service mesh: strict schemas, identity, authz, rate limiting, and observability. Treat Server Actions as an API surface, not a convenience.

The cut‑and‑ship checklist (copy this into your tracker)

Upgrade targets

• React RSC packages to 19.0.1, 19.1.2, or 19.2.1 (whichever line you’re on). (react.dev)
• Next.js to any patched version: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, or 16.0.7; avoid 14.3 canaries from .77 onward. (github.com)
• Audit transitive frameworks/plugins bundling RSC: Vite/Parcel RSC, React Router preview, Redwood, Waku. (cert.europa.eu)

Controls to keep

• Require auth for server actions; apply method allowlists and strict content types.
• WAF rule in block mode; per‑route rate limits.
• Centralized logging and anomaly detection for Server Function calls; alerts on new ASNs/source countries.

Proof you’re done

• Runtime version evidence from production containers/functions.
• Exploit‑shaped synthetic tests rejected at both app and WAF.
• 48‑hour log sweep with no suspicious RSC invocations post‑patch.

What to do next

For engineering managers, schedule a blameless post‑mortem in the next week. Make two decisions: 1) which emergency WAF rules you’ll keep as baseline controls, and 2) how you’ll gate canary dependencies in prod builds. If you want help designing that guardrail program, our services team does this work routinely across front‑end and platform teams.

For product leaders, message the update cleanly to customers: what you changed, when, and what you’re watching. Keep the version numbers and dates in your status page post. If you want templates and release choreography patterns, check our blog and what we do pages for examples you can adapt.

Zooming out

We’re shipping more logic server‑side and automating more actions with agents. That velocity is good for users—and brutal for security if you don’t treat these features like first‑class APIs. The react server components vulnerability is a wake‑up call to upgrade your mental model: UI code that triggers server work needs identity, policy, and continuous evaluation, just like a microservice. If you invest in those foundations now, the next RCE advisory is a routine patch, not a fire drill.

If you need a second set of eyes on your patch plan or want a tabletop exercise tailored to your stack, get in touch. We’ll help you turn this incident into durable operating practice.