Critical Vulnerability in React Server Components (RSC)

Photo by Lautaro Andreani on Unsplash

React has disclosed a critical unauthenticated remote-code-execution (RCE) vulnerability in its Server Components (RSC) system.

Gist

• The vulnerability is tracked as CVE-2025-55182, with a maximum severity score (CVSS 10.0).

• It arises from unsafe deserializatio. React decodes payloads sent to Server Function / RSC "Flight" endpoints in a way that allows attacker-controlled data to execute as arbitrary code on the server.

• Affected packages: react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack on versions 19.0.0 , 19.1.0 / 19.1.1 and 19.2.0.

• If your React app uses RSC, even without explicit Server Function endpoints, it may be vulnerable when used with frameworks/bundlers that rely on these packages. For example, Next.js, React Router, Vite (with RSC plugin), Parcel (with RSC plugin) or other RSC-enabled bundlers.

• React maintainers released fixed versions: for RSC packages: 19.0.1, 19.1.2, 19.2.1. Immediate upgrade is strongly recommended.

What You Should Do Immediately

• Audit your project dependencies (including sub-dependencies) to detect if any vulnerable react-server-dom-* packages are in use.

• Upgrade all affected packages to the patched versions.

• If using a framework like Next.js, upgrade to a patched release as per React's advisory.

• If immediate upgrade is not possible, consider mitigating via network-level protections (WAF, firewalls), restricting access to server-side endpoints, and auditing server request handling for unexpected payloads.

Sample Code: How to Test Locally for Vulnerability

Below is a minimal example showing how you might set up a toy Next.js + React Server Components project and manually craft a "malicious" HTTP request to test whether a local server is vulnerable. This is strictly for local, controlled testing only.

# 1. Bootstrap a new Next.js app (or use existing)
$ npx create-next-app@latest my-rsc-test
$ cd my-rsc-test

// 2. Ensure you install a potentially vulnerable version (for testing only)
"dependencies": {
  "react": "^19.2.0",
  "react-dom": "^19.2.0",
  "next": "^16.0.6"
}

$ npm install

// 3. Add a trivial React Server Component (or leave default). For example:
// pages/app/page.server.jsx
export default function Page() {
  return <div>Hello from RSC test</div>;
}

$ npm run dev

# 4. From another terminal: craft an HTTP POST that mimics a malformed Flight payload
$ curl -X POST http://localhost:3000/your-react-flight-endpoint \
  -H "Content-Type: text/x-component" \
  --data-binary $'/* malicious serialized payload here */'

In reality, the attacker-generated "serialized payload" would need to match the internal format used by React’s Flight protocol — including module references and metadata — in order to trigger unsafe deserialization. Because details are withheld until after fix rollout, building a real exploit manually is non-trivial. But, if your server crashes or executes unexpected behavior after such a request, that indicates a problem.

Alternatively, you can use a scanner tool such as React2Shell Scanner (or something similar — provided by security-vendors) to emulate exploit attempts and detect vulnerable setups.

Why This Is Particularly Dangerous (for Developers & Ops)

• This is unauthenticated RCE; An attacker does not need credentials to exploit.

• It affects default configurations in widely used frameworks. A freshly scaffolded app (e.g. via create-next-app) can be vulnerable out-of-the-box.

• Exploitation only requires an HTTP request, no additional attack chain; Making automated, large-scale scanning and exploitation feasible.