React2Shell CVE-2025-55182: critical RSC RCE

CVE-2025-55182, known as React2Shell, is a critical React Server Components vulnerability rated CVSS 10.0. A crafted unauthenticated HTTP request can execute server-side code while React Flight data is decoded. The flaw affects selected React 19 releases of react-server-dom-webpack, react-server-dom-parcel and react-server-dom-turbopack, plus frameworks embedding those packages—most notably Next.js.

Act immediately: upgrade vulnerable RSC packages to 19.0.1, 19.1.2, 19.2.1 or a later safe branch release, and move Next.js to a current fixed version. Audit indirect dependencies, built images, deployment caches and serverless revisions. Google confirmed broad exploitation by financially motivated and espionage actors.

Confirmed React2Shell facts

Attribute	Value
CVE	CVE-2025-55182
Name	React2Shell
CVSS 3.x	10.0 — critical
Affected packages	`react-server-dom-webpack`, `-parcel`, `-turbopack`
Vulnerable versions	19.0.0, 19.1.0, 19.1.1 and 19.2.0
Initial fixed versions	19.0.1, 19.1.2, 19.2.1
Access	remote, unauthenticated, no user interaction
Impact	code execution with application-server process privileges
Public PoCs	yes, multiple implementations and research projects
Exploitation	broad campaigns observed shortly after disclosure

The React Team published its advisory on 3 December 2025 and warned that an application may be vulnerable even when it defines no custom React Server Functions; framework support for React Server Components may be enough.

How the React Flight flaw works

React Server Components use the Flight format to exchange references to components, modules and data. The server decodes multipart requests and resolves references pointing into other model chunks.

In affected releases, reference-path resolution could traverse object properties without sufficiently limiting access to owned fields. Controlled data could construct an object behaving like an internal chunk/thenable and guide deserialization toward a code-execution function. The dangerous operation happened before the framework effectively validated the action identifier.

Defenders need to know that:

exploitation occurs during server-side request deserialization;
no valid business action or user account is required;
the presence of affected RSC packages on a live path may create exposure;
this is a server vulnerability, not ordinary browser-only React code;
Next.js App Router is important but not the only affected use case.

Not every React site is vulnerable. A static SPA with no server components and no vulnerable server package lacks this path.

Next.js and transitive dependencies

Next.js embeds React Server Components, so the issue was initially also tracked as CVE-2025-66478 before being marked a duplicate. Next.js fixed-version guidance evolved with later security updates. Use the current Next.js advisory and a supported branch rather than a version list copied from an old news story.

Inventory must include:

package-lock.json, pnpm-lock.yaml, yarn.lock and monorepos;
Next.js standalone artefacts and container layers;
serverless and edge functions with separate deployment cycles;
preview deployments and old PaaS revisions;
framework dependencies bringing RSC transitively;
build cache, golden images and disaster-recovery environments.

Changing package.json does not patch an already-built image. Rebuild, redeploy and remove old replicas.

Public PoC and fake exploit risk

The freeqaz/react2shell repository provides analysis, a vulnerable lab server, detection tooling and a comparison of public PoCs. It is offensive code and belongs only in an isolated lab or authorised test.

Google Threat Intelligence Group warned that many non-functional, AI-generated and malicious repositories circulated after disclosure. Some fake PoCs delivered malware to researchers. Therefore:

prefer repositories referenced by established research teams;
inspect commit history, author, dependencies and install scripts;
run code without credentials on a disposable host detached from corporate networks;
never submit real production addresses to untrusted scanners;
base production decisions on SBOM and version evidence, not RCE proof.

Updating React and Next.js

React’s initial fixed versions were 19.0.1, 19.1.2 and 19.2.1. Additional denial-of-service and source-exposure issues were later found in the same packages, so deploy the latest fixed version in the selected branch, not merely the earliest React2Shell patch.

The process is:

locate all three react-server-dom-* variants and dependent frameworks;
update lockfiles on a controlled branch;
run functional and security tests;
perform a clean rebuild without old cache;
sign and deploy the new image or artefact;
remove old revisions and invalidate preview deployments;
confirm the running version from runtime/SBOM evidence, not repository intent.

A WAF may temporarily block known request patterns but is not a complete fix. Google and other providers deployed protective rules, yet payload variation and encoding reduce signature certainty.

Confirmed post-disclosure campaigns

GTIG observed broad exploitation from 5 December 2025. Actors deployed XMRig miners, the MINOCAT tunneller, SNOWLIGHT downloader, and HISONIC and COMPOOD backdoors. Google linked some activity to China-nexus espionage clusters and also observed financially motivated and Iran-nexus operations.

The diversity shows why one IOC is insufficient. React2Shell became a general initial-access vector whose final payload depended on the operator.

Detection and threat hunting

Review:

unusual multipart requests and Server Action-related headers;
increased 500/303 responses and App Router path anomalies;
Node.js child processes: shells, curl, wget, interpreters and system tools;
outbound DNS/HTTP from application servers to new domains;
hidden directories, new systemd services, cron and shell-profile changes;
cryptominers and sudden CPU load;
application files changed after deployment and unknown npm packages;
new keys, tokens and CI/CD secrets used from unusual locations.

If Node launched a command, isolate the workload, preserve its image and logs, rotate every environment secret and examine the build/deployment platform. Rebuild from clean dependencies and a signed artefact.

The broader AppSec lesson

A modern frontend framework can be a full application server with its own RPC and deserialization protocol. SCA must cover runtime dependencies, while web application penetration testing should examine framework paths, not only business endpoints documented by the team. Combine SBOM, automated updates, preview testing and server-process monitoring.

Root cause and attack-surface boundaries

The confirmed weakness is in server-side React Flight decoding within affected react-server-dom-* packages. Impact occurs before application authentication, so user login, MFA and correct business-endpoint authorisation do not remove the flaw. Code runs with the Node or serverless process privileges; blast radius depends on that process’s secrets, filesystem, egress and cloud role.

Attack surface is not equivalent to every site using React. Establish whether the deployment runs server-side RSC and whether an affected package is on the active path. Include:

public Next.js App Router applications;
internal and preview applications behind SSO or VPN;
serverless, edge and regional function copies;
old revisions still receiving traffic;
DR and autoscaling images;
monorepos where one lockfile feeds several services;
platforms and frameworks bringing RSC transitively.

A static browser-only frontend without server RSC does not have this path. Conversely, absence of custom Server Functions is not sufficient exclusion, as the React advisory explains.

Safe exposure validation

There is no need to exploit production. Build a consistent evidence chain:

generate an SBOM and dependency tree from the lockfile for the specific artefact;
identify the framework and build containing the affected package;
map active revisions, functions, Regions, previews and DR;
confirm that the artefact handles server-side RSC;
obtain the image digest or deployment identifier of each running replica;
compare with current React and framework advisories;
reserve dynamic testing for a disposable local lab without credentials.

Connect this process to CycloneDX/SPDX SBOM and VEX and container-image security. A repository scan is insufficient when production runs an older layer. Likewise, a clean workspace does not exclude an affected package bundled into a standalone artefact.

Telemetry and triage from request to workload

Google documented several tool families used after initial access. Do not base detection only on their names or hashes. Correlate behaviour:

Layer	Evidence	Triage question
CDN/WAF	request ID, method, content type, headers and status	did it reach an origin, and which Region?
application	route, stack trace, 500/303 and deployment ID	did the RSC decoder process the request?
runtime	Node parent/child, command line, user and hash	did the application launch an unusual child?
container/serverless	image digest, revision, cold start and file write	which artefact and instance were active?
network	DNS, HTTP egress and new destination	did outbound communication follow the request?
identity/cloud	role, token and secret use	did access expand beyond the application?
CI/CD	build, signer, provenance and deployment actor	was the supply chain changed afterwards?

Triage first identifies the running artefact and timeline. It then links request ID to application event, child process, egress and cloud-identity use. A 500 response has many benign causes and is not exploitation proof. An unexplained child process under Node is high-value evidence even without a known indicator.

Maintain these analytics through a detection engineering and Sigma lifecycle, with regression fixtures for legitimate App Router errors and controlled canary events.

React2Shell decision tree

Does the artefact contain an affected react-server-dom-* release?

No: preserve SBOM and lockfile evidence for the running deployment and monitor later advisories.
Yes or unknown: prioritise update and establish whether server-side RSC is active.

Was the vulnerable artefact reachable from the Internet or a low-trust network?

Yes: hunt requests, processes, filesystem, egress, secrets and cloud activity from the exposure start.
No: patch anyway and prove the network control; phishing, SSRF or an internal foothold can alter reachability.

Did Node launch an unexpected process, write a file or exercise a secret?

Yes: isolate the workload, preserve image and logs, revoke roles and tokens, inspect CI/CD and rebuild from trusted sources.
No: complete a clean rebuild, remove old revisions and run a telemetry retest.

Rotate tokens and keys through the secrets-management process, including preview and deployment-platform credentials.

Hardening and remediation verification

Deploy the latest safe patch in a supported line and perform a clean rebuild. Then apply a read-only filesystem where feasible, non-root UID, constrained egress, short-lived workload identity and a runtime image without administrative tools. SAST, DAST, SCA and IAST answer different questions, as explained in SAST vs DAST vs IAST.

The retest should prove:

a safe version in the SBOM of the running digest, not only the repository;
no stale revision, cache or unpatched function remains;
RSC and Server Action functionality still works after upgrade;
the pipeline blocks publication of an affected artefact;
a harmless request and canary child-process test are visible;
no unexpected egress and minimum workload permissions;
closure or rotation of every secret reachable from an affected instance.

The public PoC is not part of a production retest. A laboratory may use it to establish that the patched version no longer follows the vulnerable path, while production verification relies on version, artefact, telemetry and deployment controls.