✉️info@mh-service.de | 📞+49 (7275) 9692381
Contact EN DE
Critical RCE · CVSS 10.0 · In-the-wild exploitation

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

React2Shell (CVE-2025-55182 and CVE-2025-66478) is a pre-auth remote code execution vulnerability in the Flight protocol used by React Server Components. Exploitation can lead to full server compromise, access to secrets and downstream impact on your customers.

Call 24/7 Hotline Request Incident Response Support
10+ years incident response & DFIR EU-based digital forensics & IR team React / Next.js / modern web stacks
CVE
CVE-2025-55182
CVE-2025-66478
Rating
CVSS 10.0 (critical)
Attack type
Pre-auth RCE via unsafe deserialization (Flight protocol)
Status
Active scanning & exploitation, patches available
(as of approx. 08 Dec 2025)

Executive summary

What is React2Shell?

React2Shell is a vulnerability in how React Server Components accept and process data from the client. Attackers can send specially crafted Flight payloads that cause the server to misinterpret internal structures – up to and including execution of attacker-controlled code.

Who is affected?

Any application that uses React Server Components in vulnerable versions – either directly or indirectly via frameworks such as Next.js (App Router), React Router with RSC, Waku, RSC plugins for Parcel/Vite, or Redwood/Expo. Classic “client-only” React SPAs without RSC are not affected by this specific bug.

Why is it critical?

The vulnerability is remotely exploitable without authentication, has a CVSS score of 10.0, and affects a widely used technology ecosystem. Security vendors report active scanning and exploit attempts, including activity linked to state-sponsored groups.

Timeline (simplified)

  1. Late November 2025

    Responsible disclosure

    Researcher Lachlan Davidson reports a critical vulnerability in the Flight protocol of React Server Components to the React/Meta team.

  2. 3 December 2025

    Public advisories & patches

    React publishes an advisory for CVE-2025-55182; Next.js publishes its own advisory for CVE-2025-66478. Patched versions of the RSC packages and Next.js are released.

  3. Shortly after disclosure

    Proof-of-concepts & scanning

    Initial (partly broken) PoCs appear publicly. Security vendors observe automated internet-wide scans for vulnerable Next.js/RSC applications.

  4. Following days

    In-the-wild exploitation

    Threat intelligence feeds report exploitation “in the wild”, including attempts by APT groups and opportunistic attacks such as cryptomining and backdoors.

Affected components & versions

React Server Components (RSC)

The core vulnerability resides in the React server libraries that implement the Flight protocol:

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

Explicitly vulnerable versions

  • 19.0.0
  • 19.1.0
  • 19.1.1
  • 19.2.0

Patched versions

  • ≥ 19.0.1
  • ≥ 19.1.2
  • ≥ 19.2.1

Other React 19.x versions not explicitly listed as vulnerable or patched should be checked against the current advisory.

Classic client-only React apps without an RSC server are not affected by React2Shell itself, although they may be vulnerable through other issues.

Next.js (CVE-2025-66478)

Next.js integrates RSC functionality and exposes it via the App Router and server actions. For many organisations, this is the most relevant attack surface.

Vulnerable releases (selection)

  • 14.3.0-canary.77+ (certain canaries)
  • 15.x before fixed releases
  • 16.x before fixed releases

Patched releases (selection)

  • 15.0.5
  • 15.1.9
  • 15.2.6
  • 15.3.6
  • 15.4.8
  • 15.5.7
  • 16.0.7
  • 15.6.0-canary.58
  • 16.1.0-canary.12

Even with patched Next.js versions, you should verify that lockfiles and transitive dependencies no longer reference vulnerable RSC packages.

Other affected frameworks & ecosystems

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

React Router (RSC mode) Waku @parcel/rsc @vitejs/plugin-rsc RedwoodSDK Expo with RSC support

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

Attack path – technical overview

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.
PoC note: Many public “proof-of-concept” scripts are incomplete or exploit sloppy application logic (for example calling child_process.exec directly) instead of the underlying bug. Such PoCs should not be used blindly against production systems.

Detection & telemetry

Infrastructure & runtime view

  • Process monitoring: unexpected child processes (shells, cryptominers, tools) spawned by Node/Next.js servers.
  • File activity: newly created binaries or scripts in app/temp directories.
  • Network behaviour: connections from web server containers to unknown command-and-control hosts.
  • Security sensors: eBPF/syscall-based tools (e.g. Falco rules) that detect suspicious system calls originating from Next.js/Node processes.

HTTP, logs & application view

  • HTTP patterns: large, binary or oddly structured requests to routes associated with server components or server actions.
  • Error patterns: clusters of 5xx errors with RSC/Flight related stack traces, especially from a small set of source IPs.
  • WAF/IDS rules: enable current React2Shell signatures from your vendors; log and review blocked requests.
  • Threat hunting: correlate suspicious HTTP requests with system events (process creation, tools being launched, config changes).

Recommended actions & prioritisation

1. Patching & version management (top priority)

  • Update React: upgrade affected RSC packages to patched versions (at least 19.0.1, 19.1.2 or 19.2.1); inspect lockfiles and transitive dependencies.
  • Update Next.js: move to one of the documented fixed versions (e.g. 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).
  • 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.

2. Hardening & temporary protections

  • WAF rules: enable React2Shell signatures; block suspicious multipart/binary requests to RSC/server action routes.
  • Reduce attack surface: disable unused RSC/server action endpoints; avoid exposing internal RSC functionality directly to the internet.
  • Least privilege: keep permissions for app containers and service accounts minimal (no unnecessary access to critical backend systems).

3. Forensics & incident response

  • Review logs and telemetry since the advisories were published for any exposed Next.js/RSC applications.
  • Focus on systems where suspicious HTTP requests and unusual process activity coincide.
  • In case of suspicion: isolate affected systems, preserve artefacts (container images, logs, memory dumps) and run structured incident response according to your playbooks.

FAQ for customer conversations

“We use React in the frontend – are we automatically affected?”

Not necessarily. React2Shell primarily affects React Server Components on the server. Classic SPAs that run entirely in the browser and do not use an RSC server are not affected by this specific vulnerability, even though other risks may exist.

“We have already patched – are we done?”

Patching is the most important step but not the end. You should verify that patched versions have been deployed everywhere, check for suspicious activity prior to patching, and assess whether unnecessary RSC functionality was exposed.

“Are there already active attacks?”

Yes. Security vendors report automated scanning and exploitation attempts, including actions attributed to known APT groups. Organisations with internet-facing Next.js/RSC applications should prioritise log and telemetry review.

“How should we prioritise React2Shell vs. other vulnerabilities?”

Where React Server Components are exposed to the internet, React2Shell should be treated as a top priority (P1). In environments without RSC servers, the priority is lower but it should still be addressed promptly as part of regular patch management.

How we can support you with React2Shell

As a specialised security team, we help organisations handle React2Shell in a structured, risk-based way:

  • Remote discovery & pre-assessment: identify Next.js/RSC assets and provide an initial risk picture (e.g. passive stack checks, safe remote scans).
  • Repository & build analysis: analyse dependencies, lockfiles and CI/CD pipelines to locate vulnerable versions and RSC usage.
  • Patching & hardening: support with React/Next.js upgrades, configuration changes, WAF rules and platform hardening.
  • Detection engineering & IR: build detection rules (SIEM, EDR, WAF) and perform forensics/IR if compromise is suspected.

Next steps for interested organisations

  1. Quick scoping: which applications use React / Next.js / modern React frameworks, and where are they exposed?
  2. Provide basic information (tech stack, hosting, cloud/on-prem setup, logging/monitoring status).
  3. Jointly prioritise critical targets and plan assessment, patching and – where needed – forensic activities.

On request, we provide lightweight scripts customers can use to scan their own repositories and deployments for React2Shell exposure (for example, version checks for React RSC & Next.js).