The React2Shell Crisis: Technical Deep Dive into CVE-2025-55182 and Widespread Exploitation Activity

December 17, 2025

Introduction

A new critical flaw has shaken the modern web ecosystem one that strikes at the heart of the rapidly expanding React Server Components architecture. In a landscape already strained by supply-chain risks and zero-day exploitation, CVE-2025-55182 arrived with the kind of impact that immediately alarmed defenders, researchers, and cloud vendors worldwide. What initially appeared to be a niche deserialization bug quickly revealed itself as a high-severity, unauthenticated RCE vector capable of compromising applications at scale, irrespective of how deeply they implemented React Server Components.

CVE-2025-55182, widely referred to as "React2Shell," emerged as one of the most disruptive vulnerabilities of the year. The vulnerability, disclosed publicly in early December 2025, allows unauthenticated remote code execution across systems using React Server Components even in applications that do not explicitly invoke server functions dramatically expanding its attack surface.  

What propelled CVE-2025-55182 into global focus was the speed and scale of exploitation: within hours of disclosure, threat groups such as Earth Lamia and Jackpot Panda began weaponizing the flaw against exposed systems. This was soon followed by widespread abuse from botnets including RondoDox and Mirai, which leveraged the vulnerability to deploy Linux backdoors, reverse proxy tunnels, cryptominers, and automated reconnaissance payloads. The rapid escalation in exploitation, combined with the ubiquity of React-based applications in modern web infrastructure, led to its urgent inclusion in the CISA Known Exploited Vulnerabilities (KEV) catalog.

What is CVE-2025-55182?

CVE-2025-55182, also known as React2Shell, is a critical unauthenticated Remote Code Execution (RCE) vulnerability in Meta's React Server Components caused by insecure deserialization in React Server Function endpoints. With a maximum CVSS v3.1 score of 10.0 and a CVSS v4 score of 9.3, the flaw allows attackers to execute arbitrary code by sending a single malicious HTTP request, enabling full compromise of the affected server with the privileges of the web process.  

Because the attack requires no authentication, user interaction, or complex exploit chain, it poses a high-value target for mass exploitation, automated scanning, botnets, and threat actors seeking to breach Node.js and React-based environments.

What are React Server Components?

React Server Components (RSCs) are a modern capability in React that allows components to run entirely on the server, enabling direct data access, smaller JavaScript bundles, and significantly improved application performance. Adopted by frameworks like Next.js App Router, where RSCs are the default, this model shifts rendering and logic execution away from the browser and into a controlled server environment.  

What are the affected versions?

Product / Package Affected Versions Patched Versions
react-server-dom-webpack 19.0.0, 19.1.0, 19.1.1, 19.2.0 19.0.1, 19.1.2, 19.2.1
react-server-dom-parcel Versions bundled with React 19 prereleases Patched updated release aligned with React 19.0.1+
react-server-dom-turbopack Versions included in React 19 prereleases Patched in 19.0.1+ and Next.js security updates
Next.js (RSC-enabled builds) Any version bundling vulnerable RSC packages Patched via Next.js update following React fix
Vite, Parcel, Waku, RedwoodJS RSC integrations All builds using the vulnerable RSC packages Updates required to ensure React dependencies resolve to fixed versions
Applications built with React Server Components Any deployment using affected packages, even if server functions are not explicitly used Must rebuild with fixed RSC package versions

Technical analysis of CVE-2025-55182

The root cause:

React Server Components rely on a custom Flight protocol to serialize and transmit component data between the server and client.

React decodes incoming RSC payloads using a deserialization mechanism that reconstructs component definitions, references, and function calls.  

The vulnerability arises because:

  • React trusts client-supplied RSC payloads,
  • performs insufficient type and object validation,
  • and reconstructs objects in a way that enables arbitrary function invocation.

This allows attackers to craft malicious RSC payloads that map to internal React server functions, resulting in execution of arbitrary JavaScript on the server.

Even apps not explicitly using server functions are affected because the vulnerable code is loaded by default when RSC packages are installed.

So, any internet-exposed RSC endpoint becomes an RCE vector.

The exploitation process:

Step 1 - Attacker sends a crafted HTTP request

Attackers identify React Server Component routes (commonly /react, /server, or framework-specific RSC endpoints like Next.js /_rsc).

The request contains a malicious RSC payload designed to instantiate server functions.

Step 2 - React Deserializes the Malicious Payload

React attempts to reconstruct the payload as a valid RSC message.

During deserialization, React:

  • interprets $f values as function references,
  • resolves object references without verifying source legitimacy,
  • passes reconstructed data directly into the server’s execution context.

Because React doesn’t validate whether the function is actually safe, the attacker can redirect React’s reconstruction process toward sensitive server-side APIs, such as child_process.exec, fs.readFile, or other privileged JavaScript capabilities.

Step 3 - Arbitrary Function Invocation

The payload causes React to call a server function that results in server-side command execution, not just JavaScript evaluation.  

This process can be triggered with a single HTTP POST request containing a malicious Flight payload, making exploitation trivial for automated scanners and botnets.  

Post Exploitation:

As soon as code execution is achieved, attackers deploy post-exploitation payloads including Linux backdoors, tunneling tools, implants, DDoS malware, and cryptominers. The vulnerability affects systems even when developers do not intentionally use server functions, because the vulnerable RSC deserialization logic loads by default through the affected react-server-dom packages.

Who Is Exploiting CVE-2025-55182?

Multiple APT groups, botnets, and malware families rapidly weaponized CVE-2025-55182, creating one of the broadest exploitation ecosystems observed for a modern web vulnerability.  

Nation-State / APT Threat Actors exploiting this React2Shell vulnerability

Botnets exploiting React2Shell

Malware families delivered through exploitation

  • Cryptominer XMRig
  • SNOWLIGHT
  • VShell Trojan
  • EtherRAT
  • KSwapDoor Linux backdoor
  • Noodle RAT Backdoor
  • Auto-Color Backdoor
  • PeerBlight Linux Backdoor
  • ZinFoq implant
  • BPFDoor

How to check whether your environment is vulnerable to CVE-2025-55182 (React2Shell)

Verify if Your Project Uses Vulnerable React Server Component Packages

CVE-2025-55182 affects applications that have any of the following packages installed at vulnerable versions:

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

Run:

npm list react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack

If any of these resolve to versions affected by the advisory (19.0.0 – 19.2.x before patched releases), the project is vulnerable.

Check Your Lockfile for Vulnerable Transitive Dependencies

Even if you do not explicitly install RSC packages, they may be bundled by frameworks such as Next.js, Vercel’s build system, Parcel, or Turbopack.

Inspect package-lock.json or yarn.lock:

Search for:

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

If present at pre-patch versions → your app is exploitable.

Determine Whether Your Application Exposes RSC Endpoints

React2Shell is exploitable when RSC endpoints are reachable over the internet.

Look for endpoints similar to:

  • /_rsc
  • /react
  • /server
  • /index.rsc

Next.js RSC routes under:  

  • /_next/data/...
  • /_next/static/...

To confirm:

grep -R "_rsc" -n ./src

Or check routing/middleware definitions.

If RSC endpoints are public-facing, risk = high.

Check Framework Versions (Next.js / Parcel / Turbopack)

React2Shell is inherited by frameworks that bundle vulnerable RSC logic.

For Next.js:

npm list next

Any build created before the patched Next.js releases (December 2025) is vulnerable.

Check .next/server/chunks/ for Flight protocol decoder files presence indicates RSC usage.

Analyze Server Logs for Suspicious RSC Payloads

Exploitation attempts often appear as unusual POST requests containing serialized Flight protocol structures.

Look for patterns like:

  • "$f"
  • "$L"
  • "$Rc"
  • "$K"

Or JSON-like structures in unexpected POST bodies to RSC endpoints.

Example log signature:

  • POST /_rsc 200 -
  • Content-Type: text/x-component
  • ["$f","eval","child_process.exec","uname -a"]

If such requests appear → exploitation was attempted.

Run Dependency Security Scanners

Automated tools can help confirm vulnerable package versions:

  • npm audit | grep react-server
  • yarn npm audit
  • snyk test
  • trivy fs .

If any flag react-server-dom-* packages → assess vulnerability.

Verify Whether Your Build Has Been Rebuilt After Patching

Even after updating packages, you remain vulnerable until the application is rebuilt and redeployed.

Check build timestamps:

  • ls -l .next/server
  • ls -l dist/
  • ls -l build/

If timestamps predate patch installation → deployment is still vulnerable.

Quick Defense Checklist for CVE-2025-55182 (React2Shell)

  • Update all vulnerable React Server Component packages - Upgrade react-server-dom-webpack, react-server-dom-turbopack, and react-server-dom-parcel to patched versions. Rebuild and redeploy your application.
  • Lock and pin dependencies - Use overrides or resolutions in package.json to prevent downgrades to vulnerable versions.
  • Restrict exposure of RSC endpoints - Block or limit access to /_rsc, /react, /server, and related paths via WAF, firewall, or reverse proxy.
  • Deploy WAF signatures - Block requests with suspicious RSC payload markers ($f, $L, $K, $Rc or text/x-component bodies).
  • Monitor logs for exploitation attempts - Look for abnormal POST traffic to RSC endpoints with serialized payloads resembling Flight protocol structures.
  • Harden runtime environments - Enforce read-only filesystems, disable unnecessary Node modules (child_process), and apply seccomp/K8s restrictions.
  • Use CI/CD guards and SBOM scanning - Fail builds containing vulnerable RSC packages; track dependency health with Syft/Grype/SBOM tools.

Will CVE-2025-55182 become the next Log4Shell?

Log4Shell - CVE-2021-44228, is remembered as one of the most catastrophic vulnerability in cybersecurity history because it delivered unauthenticated remote code execution across millions of systems that relied on Log4j a logging library so deeply embedded in enterprise and cloud software that many organizations didn't even know they were exposed. Its impact was amplified by universal adoption, trivial exploitation, and the immediate involvement of ransomware groups, botnets, nation-state actors, and automated worms. Log4Shell wasn’t just a software flaw; it triggered a global incident response effort that lasted months and reshaped supply-chain security practices.

From a personal technical standpoint, CVE-2025-55182 (React2Shell) exhibits several traits that echo Log4Shell: pre-authentication RCE, extremely low exploitation complexity, widespread framework-level adoption, and nearly instantaneous weaponization by both APT actors and commodity botnets. However, unlike Log4j, React Server Components are not ubiquitously embedded across the entire software ecosystem, which limits its systemic blast radius. Despite this, the speed, scale, and diversity of exploitation already place React2Shell among the most impactful web vulnerabilities in recent years. Whether it ultimately becomes “the next Log4Shell” depends on how quickly organizations patch and redeploy, but early indicators suggest it is already shaping up to be one of the defining vulnerabilities of 2025.

Moving Forward

CVE-2025-55182 (React2Shell) has rapidly evolved into one of the most impactful vulnerabilities of the year, with its pre-authentication RCE vector and broad exposure across modern web frameworks driving immediate weaponization by APT groups, botnets, and opportunistic attackers. Mitigation now depends on fast patching, rebuilding vulnerable applications, hardening exposed RSC endpoints, and maintaining continuous visibility into exploitation attempts. This is exactly where Loginsoft Vulnerability Intelligence (LOVI) delivers critical value providing real-time exploit tracking, attacker telemetry, and integrated MITRE mapping to help organizations detect, prioritize, and respond to vulnerabilities like React2Shell before they become entrenched compromise vectors.

FAQ’s:

1. What is CVE-2025-55182 (React2Shell)?

A) CVE-2025-55182 (React2Shell is a pre-authentication remote code execution vulnerability in React Server Components caused by insecure deserialization of Flight protocol payloads. It allows attackers to execute arbitrary server-side code without authentication.

2. Why did React2Shell gain so much global attention?

A) Exploitation began within hours of disclosure, with nation-state actors, botnets, and malware operators rapidly weaponizing the flaw. Its impact spans cloud workloads, web frameworks, and large developer ecosystems.

3. What immediate steps should organizations take to defend against this vulnerability?

A) Upgrade all RSC packages, rebuild and redeploy applications, restrict RSC endpoint exposure, and deploy WAF signatures.

4. Why was CVE-2025-66478 initially associated with this vulnerability

A) CVE-2025-66478 was an early identifier mistakenly assigned to the same React Server Components deserialization flaw later formalized as CVE-2025-55182. Once the correct CVE was confirmed, the earlier ID was withdrawn to avoid duplication, and all details were consolidated under CVE-2025-55182. As a result, both IDs refer to the same underlying vulnerability, but only CVE-2025-55182 remains the authoritative entry

Get Notified