securityreactnextjskubernetesincident-notes•

Critical React Server Components RCE (CVE-2025-55182) — What Next.js/React Teams Should Do Now

A serious vulnerability in React Server Components (RSC) has been disclosed that can lead to unauthenticated remote code execution (RCE) on the server. The upstream CVE is CVE-2025-55182 (CVSS 10.0) and it’s being treated as “patch immediately.”

If you run modern React frameworks (especially Next.js App Router), this is one of those “stop what you’re doing and upgrade” moments.

TL;DR

  • Risk: attacker-crafted requests can reach the RSC decoding/deserialization path and trigger server-side execution in unpatched environments.
  • React fix: upgrade to patched React server packages (19.0.1 / 19.1.2 / 19.2.1).
  • Next.js fix: if you use App Router + RSC, upgrade to a patched Next.js version in your release line (examples below).
  • WAF mitigation: Cloudflare and others shipped temporary WAF rules, but don’t rely on WAF as your only fix — patch anyway.

What’s actually vulnerable (plain language)

RSC lets the browser and server exchange structured “Flight” payloads so the server can render parts of the UI and run server-side actions. The issue is that malformed/adversarial payloads can be processed in a way that influences server-side execution, leading to RCE in unpatched setups.

The important part: this can be unauthenticated, meaning the attacker may not need an account depending on your exposure.

Who’s affected?

React packages

The vulnerable versions include 19.0, 19.1.0, 19.1.1, 19.2.0 of:

  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack

Next.js (downstream impact)

Next.js confirms App Router + RSC apps are affected when running:

  • Next.js 15.x
  • Next.js 16.x
  • Next.js 14.3.0-canary.77+ (canary line)

Not affected (per advisory):

  • Next.js 13.x
  • Next.js 14.x stable
  • Pages Router apps
  • Edge Runtime

What to do right now (recommended order)

1) Patch (don’t debate it)

React: upgrade to a fixed React release (19.0.1 / 19.1.2 / 19.2.1).

Next.js: upgrade to the latest patched version in your line (examples):

# Next.js patched lines (examples)
npm install [email protected]   # for 15.0.x
npm install [email protected]   # for 15.1.x
npm install [email protected]   # for 15.2.x
npm install [email protected]   # for 15.3.x
npm install [email protected]   # for 15.4.x
npm install [email protected]   # for 15.5.x
npm install [email protected]   # for 16.0.x

# If you're on Next.js 14.3.0-canary.77+:
npm install next@14

Also note: there is no config flag to disable the vulnerable code path in Next.js — patching is the fix.

2) Add WAF protection as a speed bump (not a cure)

If you proxy traffic through a WAF (Cloudflare, etc.), enable the vendor mitigation rules — but still patch everywhere.

3) Watch your logs like it’s incident day

Until everything is patched:

  • monitor requests to Server Action / server function endpoints
  • look for malformed payloads, weird POST spikes, and unusual Node process behavior

Quick self-checks (5 minutes)

  • Are we using Next.js App Router? (If yes → treat as affected until proven otherwise.)
  • Are we using React 19 RSC packages in the dependency tree?
npm ls react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack
npm ls react react-dom next
  • Are any of these apps internet-exposed without strong auth gating in front of them?

Final note

This is the kind of vuln that turns “modern default” into “modern attack surface” overnight. Patch fast, validate, and then go back and improve your guardrails (dependency alerting, faster roll-forward deploys, and WAF baselines).

Stay safe !