React2Shell – critical RCE vulnerability in React Server Components & Next.js

Other affected frameworks & ecosystems

Beyond Next.js, any framework that uses React Server Components or the Flight protocol may be affected, including:

In many SBOMs/SCA reports, these components only appear indirectly via React. A deeper dependency-tree analysis is therefore recommended.

The vulnerability is based on unsafe deserialization of Flight payloads in the React server. RSC clients send structured data representing component trees and server function calls. During decoding, some structures and keys are not validated strictly enough. Attackers can manipulate internal objects and reach code paths where attacker-controlled values are executed.

1. Endpoint identification: RSC/server action endpoints can be discovered via typical routes, response headers, and framework signatures (e.g. Next.js App Router).
2. Crafted Flight payload: Instead of legitimate data, the attacker sends a crafted payload that pollutes prototypes or abuses internal type markers.
3. Unsafe decode & dispatch: The Flight decoder turns this into JavaScript objects and hands them to server logic. Insufficient validation allows attacker-controlled values to reach places that were not designed for user input.
4. Gadget chain to RCE: By leveraging existing code paths (“gadgets”), attackers can ultimately execute arbitrary JavaScript in the context of the Node/Next.js process.
5. Post-exploitation: Once code execution is achieved, typical follow-ups include access to secrets, planting backdoors, cryptomining, or lateral movement within internal networks.

Observed exploitation chains in the wild

• Espionage-focused activity: China-nexus clusters use React2Shell to deploy tooling such as the MINOCAT tunneler (Fast Reverse Proxy client), SNOWLIGHT downloader (part of VSHELL), COMPOOD and HISONIC implants, and ANGRYREBEL.LINUX, often targeting Linux/cloud infrastructure in APAC and global VPS providers.
• Cryptomining & crimeware: financially motivated actors run simple one-shot commands from the compromised web process to download small shell scripts that install and persist XMRig cryptocurrency miners, sometimes under innocuous names and systemd services like “system-update-service”.
• Infrastructure changes: scripts often create hidden directories (for example under a user’s home directory), masquerade binaries as common tools (such as sshd or vim), timestomp files and clear shell history to hinder forensics.
• Exploit ecosystem: public exploit repositories have evolved from mostly non-functional examples to fully working payloads, including obfuscated variants and “web shell in one request” toolkits for Next.js.

Selected indicators & hunting ideas

Threat intelligence providers have shared useful indicators and behaviours that defenders can look for in logs and EDR data:

• Domains & IPs (examples): reactcdn.windowserrorapis[.]com (used by SNOWLIGHT), 82.163.22[.]139, 216.158.232[.]43, 45.76.155[.]14 (staging/command servers in observed campaigns).
• Filesystem artefacts: hidden directories such as $HOME/.systemd-utils, binaries masquerading as sshd or vim in unusual locations, timestomping of newly dropped files.
• Persistence mechanisms: new cron jobs, systemd units or rc scripts created shortly after suspicious HTTP activity; services with names that mimic legitimate update tooling (e.g. “system-update-service”).
• Process lineage: system utilities like curl or wget spawned from the Node/Next.js process, immediately followed by execution of a new local binary or shell script.

Always combine these indicators with your own telemetry and up-to-date threat intel – lists are incomplete by design and evolve as new campaigns emerge.

1. Patching & version management (top priority)

Many organisations patched quickly after the first advisory – but only for the initial RCE. With the additional CVEs and the incomplete DoS fix in 19.2.2, patching needs to be revisited.

• Update React RSC packages:
  • For CVE-2025-55182 (RCE): at least 19.0.1, 19.1.2 or 19.2.1 depending on your branch.
  • For CVE-2025-55183 (info disclosure): at least 19.2.2.
  • For CVE-2025-55184 and CVE-2025-67779 (DoS, including incomplete fix in 19.2.2): update to 19.2.3.
  • In practice, aim for 19.2.3 or newer across all RSC packages to avoid a patchwork of slightly different residual risks.
• Update Next.js: move to one of the documented fixed releases (for example 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7 or the respective canaries) and keep tracking the official security advisories for new patch trains.
• Other RSC frameworks: follow vendor advisories for React Router, Waku, Redwood, Expo, etc., and apply recommended updates.
• Rebuild & rollout: after updating, rebuild artefacts and roll out updated deployments so that old vulnerable bundles are removed from all environments (production, staging, “forgotten” test systems).

2. Hardening & temporary protections

• WAF rules: enable React2Shell signatures from your WAF vendor and cloud platform. Some providers ship pre-defined rulesets specifically for CVE-2025-55182 and related payload formats. Treat them as a safety net while patching – not as a permanent replacement for fixes.
• Reduce attack surface: disable unused RSC/server action endpoints; avoid exposing internal RSC functionality directly to the internet; consider segmentation between public frontends and sensitive internal systems.
• Least privilege: keep permissions for app containers and service accounts minimal (no unnecessary access to critical backend systems, cloud control planes or credential stores).

3. Forensics & incident response

• Review the time since the first advisory: specifically investigate the period between initial disclosure (early December) and your most recent patch rollout – even if you already applied some fixes.
• Focus on systems where suspicious HTTP requests, new files and unusual process activity (e.g. tunnellers, backdoors, cryptominers) coincide.
• In case of suspicion: isolate affected systems, preserve artefacts (container images, logs, memory dumps) and run structured incident response according to your playbooks – or with external DFIR support.