Affected frameworks (when using vulnerable React packages): Next.js 15.x / 16.x (App Router), React Router, Waku, RedwoodSDK, Parcel RSC, Vite RSC plugin.

CVSS v3.1 Breakdown

Vector string: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

How the Vulnerability Works

React Server Components use a binary wire format called the Flight protocol to stream component trees from server to client. The same protocol handles Server Functions (formerly Server Actions) — callable endpoints that accept serialised arguments from the browser.

The vulnerability is in the deserialiser: when React processes a Flight payload it can be tricked into instantiating arbitrary server-side objects, leading to full RCE. Because the Flight endpoint is exposed by default whenever RSC is enabled, and because no authentication gate exists at the protocol level, exploitation requires only network access to the server.

Nuclei Template

The included template CVE-2025-55182.yaml uses three complementary detection methods.

Request 1 — Generic RSC Flight Endpoint Probe

Sends a minimal POST with Content-Type: text/x-component to the root path. A vulnerable (or reachable) RSC server responds with the same content-type and a Flight stream body whose rows begin with alphanumeric row IDs followed by a colon (e.g. 0:, 1:) or React reference sigils ($L, $S, $I, $@).

Match condition: HTTP 200 + text/x-component header + Flight stream regex in body.

Request 2 — Next.js App Router RSC Probe

Next.js signals RSC requests via the RSC: 1 header and ?_rsc= query parameter. This request mimics a browser prefetch to confirm the App Router Flight endpoint is reachable.

Match condition: HTTP 200 + text/x-component header.

Request 3 — Server Function (Action) Endpoint Probe

Posts a minimal malformed Flight payload alongside a Next-Action header (the mechanism used to invoke Server Functions). A vulnerable server attempts to deserialise the payload; even an error response that includes RSC-specific headers confirms the endpoint exists.

Match condition: HTTP 200/400/500 + text/x-component or x-action-revalidated header.

File-Based (Passive) Detection

Scans local *.json files (e.g. package-lock.json, yarn.lock) for the vulnerable package names combined with a version regex matching 19.0.0, 19.1.0, 19.1.1, or 19.2.0. Useful for auditing repositories or CI pipelines without sending any network traffic.

Usage

Prerequisites

• Nuclei v3.x or later

Active scan — single target

Active scan — list of targets

Passive scan — local project directory

Verbose output with JSON reporting

Scan with rate limiting (recommended for production targets)

Remediation

Upgrade immediately to a patched version:

Minimum safe versions per branch:

Temporary mitigations (if upgrading is not immediately possible):

• Block HTTP POST requests to RSC/Flight endpoints at the WAF or reverse-proxy layer.
• Disable React Server Components entirely until a patch can be applied.
• Deploy a WAF rule targeting the text/x-component content type on inbound POST requests (Google Cloud Armor rules are publicly available for this CVE).

Notes & Limitations

• A positive match on the HTTP probes confirms the Flight endpoint is reachable, which is a strong indicator of vulnerability. Exact version confirmation requires inspecting package-lock.json, node_modules, or an SBOM.
• The template does not send a weaponised payload; it is detection-only and safe to run against production systems.
• Applications that do not use React Server Components (client-side-only React apps) are not affected.

References

• React official advisory — react.dev
• GitHub Security Advisory — GHSA-fv66-9v8q-g76r
• NVD — CVE-2025-55182
• Zscaler ThreatLabz — React2Shell
• Google Cloud Blog — Threat Actors Exploit React2Shell
• Palo Alto Unit 42 — CVE-2025-55182 Exploitation

Disclaimer

This template is intended for authorised security testing and vulnerability assessment only. Running it against systems you do not own or have explicit written permission to test may be illegal. The authors accept no liability for misuse.