React Server Components RCE (CVE-2025-55182)

Why does this disclosure matter?

On December 3, 2025, the React team disclosed CVE-2025-55182, a CVSS 10.0, unauthenticated RCE in React Server Components (RSC). The flaw lives in the RSC Flight protocol decoding path, meaning a single crafted request can reach server-side execution before routing/auth on many default setups, especially Next.js App Router deployments. 

This is a protocol-boundary issue, not a niche plugin bug. Treat it as incident-critical: patch first, use WAF/Cloud Armor rules only as a temporary seatbelt during rollout, then verify via SBOM/lockfiles that every running artifact has moved to patched lines.

What Actually Broke in React Server Components

React 19’s Flight protocol takes serialized data from the browser and decodes it on the server. A flaw in that server-side deserialization lets a crafted but valid payload slip past checks and reach evaluation paths before your routing/auth middleware, enabling one-shot remote code execution (RCE) on typical Node-based RSC servers.

Why this is different from “ordinary SSR”

• It’s not a template bug in your app; it’s a protocol/implementation bug in the RSC layer many frameworks embed by default.

• Because it sits pre-auth, any internet-reachable RSC endpoint on vulnerable versions is a viable entry point.

• The affected code ships via packages like react-server-dom-* and through frameworks (e.g., Next.js App Router), so transitive pulls matter, check SBOMs, not just package.json.

That said, the risk is structural: client → Flight payload → server decode → code path reached pre-auth. Fixing means upgrading the RSC packages/framework everywhere they run, not just patching app code.

Affected Ecosystem and Exact Patched Versions to Target

This bug isn’t limited to React’s core libraries, it spans the broader ecosystem of frameworks and bundlers that include React’s server components. Key affected stacks include:

• React 19 RSC libraries: Any use of react-server-dom-webpack, react-server-dom-parcel, or react-server-dom-turbopack at versions 19.0.0 – 19.2.0 is vulnerable. Upgrading those packages to 19.2.1 (or 19.0.1/19.1.2) patches the flaw.

• Next.js: All App Router releases from 14.3.0-canary.77 and up through stable 15.x and 16.x are affected. The Next.js team published a separate advisory (CVE-2025-66478) with patched versions (e.g. Next.js 15.0.5, 15.1.9 … 16.0.7) that include the fix. (If you’re on a 14.x canary, downgrade to the latest stable 14.x.)

• Other React frameworks: Any platform bundling React’s server components is likely at risk. This includes frameworks like React Router (RSC preview), Expo, RedwoodJS SDK, Waku, and similar. Most use the same vulnerable react-server-dom-* code.

• Bundlers/Plugins: Tools like Vite’s RSC plugin, Parcel’s RSC plugin, Turbopack, etc., are affected because they embed the unsafe React server packages.

• Node.js servers: Even plain Node servers that import React 19 RSC components (e.g. standalone server-action endpoints) are vulnerable if they use the affected packages.

• Safe cases: Client-only apps or servers without RSC support are not affected. However, given how easy it is to accidentally include RSC (e.g. by upgrading React or using a new template), auditing your SBOM/dependencies is crucial.

In short, if your stack pulled in React 19’s server components (even indirectly), assume it’s vulnerable until proven otherwise. 

Impact and Urgency

This vulnerability lands before your app’s routing and auth, which means a single crafted request against an RSC endpoint can execute code on the server. In practical terms, that opens the door to credential theft, arbitrary process execution, file reads/writes, and lateral movement from the web tier. Because modern React/Next stacks often enable RSC by default, the exposure surface is wider than teams assume.

Expect the internet to react quickly. Once details circulate, opportunistic scanners will probe any publicly reachable RSC routes. Major providers 

Major vendors are treating it like a crisis. Cloudflare, Google Cloud, Fastly, Vercel and others deployed emergency WAF rules to block the exploit patterns for their customers. However, security teams emphasize that network filtering is only a stopgap, the true fix is patching your code.

Takeaway: treat this as a top-tier incident for any service that could accept RSC traffic. Prioritize internet-facing workloads first, then complete organization-wide verification to ensure no workload is still running vulnerable react-server-dom-* or unpatched framework versions. With the risk framed, here’s the shortest path to remediation.

The 90-minute Remediation Playbook (prioritized)

Objective: remove exploitability fast, prove it’s gone, and stop it from coming back.

0) Preconditions (5 min)

• Freeze non-security deploys for services that may accept RSC traffic.

• Open a single incident ticket: scope, owners, deadlines, status board link.

1) Patch fast (30–40 min total)

Owners: Service Owners + DevInfra

• React RSC packages: upgrade to 19.2.1 (or backports 19.0.1 / 19.1.2) and rebuild.

• Next.js (App Router): jump to your nearest patched minor (e.g., 15.5.7 or 16.0.7). Rebuild.

• Other frameworks/bundlers: pull latest that includes patched RSC.

• Deploy to internet-facing services first; verify health probes pass.

Verification: SBOM/lockfile shows patched versions; build artifact IDs captured in the ticket.

2) Edge protections while rollouts finish (10–15 min)

Owners: SRE/Platform

• Enable managed edge rules for the RSC CVE in block mode once the first patched wave is live.

• Add a short-lived dashboard: RSC route hits, blocked events, 4xx/5xx spikes.

Verification: rule ID(s) + screenshot/URL attached to the ticket.

3) Sweep for stragglers (10–15 min)

Owners: AppSec + DevInfra

• SBOM sweep across repos and container images for react-server-dom-* and unpatched Next.js minors.

• Failing items: auto-open bump PRs; mark affected services on the status board.

Verification: exported SBOM query (CSV/JSON) attached; list of remaining services (if any).

4) Logs & keys (10–15 min)

Owners: AppSec + SRE/Platform

• Log review (last 14–30 days): unusual hits to RSC endpoints; serialization errors near disclosure time; Node child process spawns.

• Rotate credentials for exposed services if unpatched during that window (DB creds, API tokens, signing keys).

Verification: log query links + rotation checklist attached.

5) Gates to prevent re-introduction (10 min)

Owners: DevInfra

• Turn on CI quality gates to block merges/deploys that re-introduce vulnerable ranges (including transitives/base images).

• Nightly re-scan job to reopen tickets if drift reappears.

Verification: screenshot of gate policy + green pipeline proving gates are active.

You’ve contained the blast radius; now assign ownership so the fix sticks.

Organizational Response & Best Practices

Goal: Patch fast, verify thoroughly, and prevent re-introduction of vulnerable ranges.

Who does what (single-glance swimlanes)

AppSec (Owner: Head of AppSec)

• Inventory & exposure map: Run the canonical SBOM query for react-server-dom-* and affected framework minors across repos and images.

• Detections: Ship rules for unusual RSC/Flight requests; enable alerts on hits.

• Closure criteria: Each service closed only when patched + logs reviewed + risks documented.

SRE / Platform (Owner: SRE Lead)

• Edge protections: Enable managed RSC rules at the edge (see Playbook step 4) during rollout.

• Observability: Raise sampling on edge and app logs; add a short-lived dashboard for RSC route traffic, errors, and block events.

• Stability guardrails: Track error budgets while patches roll out; flag regressions.

DevInfra / Tooling (Owner: DevInfra Lead)

• CI quality gates: Fail builds introducing vulnerable RSC ranges (including transitives/base images).

• Automated bumps: Auto-open version PRs where applicable; enforce “green SBOM scan” before deploy.

• Drift control: Nightly job to re-scan lockfiles/images and reopen tickets if regressions appear.

Engineering Managers / Service Owners

• Patch by exposure: Public internet–facing services first; then internal surfaces.

• Single source of truth: Maintain a status board (service → fixed versions → envs) with owners and due dates.

• Post-patch checks: Confirm running containers match patched versions; sign off after AppSec log review.

Minimal timeline (can drop into a ticket)

• Day 0 (today): Freeze feature deploys; enable edge protections; start SBOM sweep; begin upgrades on public endpoints.

• Day 1: Complete upgrades for internet-facing services; verify logs; rotate high-value credentials if warranted.

• Day 2: Finish remaining services; turn CI gates to block; publish after-action with version matrix and lessons learned.

Acceptance criteria (done = done)

• All affected services on patched RSC/framework versions and running containers verified.

• CI gates block re-introduction of vulnerable ranges.

• Detections live and quiet (no unexplained hits).

• Status board closed with owners, dates, and artifacts (SBOM query, logs, and sign-offs).

Conclusion

The lesson isn’t “patch faster.” It’s “see sooner, block sooner.” Modern web stacks embed server-side protocols; without SBOM-visible builds and merge-time gates, every release can quietly re-introduce critical risk.

CodeAnt AI Security makes that discipline routine:

• Org-wide dependency visibility

• Merge blockers on vulnerable ranges

• Boundary-aware code review for RSC/serialization code

• Continuous supply-chain hygiene (secrets, images, drift)

If you want a 48-hour RSC Hardening Pack (SBOM queries, CI gate templates, and a rollout checklist), ping us: codeant.ai/sales.