React2Shell (CVE-2025-55182): Pre‑Auth RCE In React & Next.js- A Log4Shell‑Style Wake‑Up Call

On 3rd December 2025, a critical remote code execution vulnerability was disclosed in the React Server Components (RSC) ecosystem, widely known as React2Shell and tracked as CVE‑2025‑55182 (React) and CVE‑2025‑66478 (Next.js, later merged into the main CVE).

The flaw allows unauthenticated remote code execution (pre‑auth RCE) on servers using React Server Components and frameworks like Next.js App Router, via unsafe deserialization of specially crafted HTTP payloads.

Key points for security leaders:

• Severity: CVSS 10.0 (critical) – maximum score, with full impact on confidentiality, integrity and availability.
  
• Affected: React 19.x Server Components and multiple versions of Next.js 15.x / 16.x using App Router, plus other frameworks that embed RSC.
  
• Exploitation: Public PoCs and scanners exist; major vendors and cloud providers are reporting active exploitation in the wild by both state‑nexus and opportunistic threat actors.
  
• Regulatory urgency: CISA has added CVE‑2025‑55182 to the Known Exploited Vulnerabilities (KEV) catalog, setting a remediation deadline of 26 December 2025 for US federal agencies.
  

In this blog, we break down what React2Shell is, why it matters for CISOs, which environments are at risk, and how FireCompass can help you rapidly identify and validate vulnerable instances across your external attack surface using our React2Shell playbook.

Run a free React.js exposure assessment as a part of our Free Trial: https://www.firecompass.com/trial

What Is React2Shell (CVE‑2025‑55182 / CVE‑2025‑66478)?

React2Shell is a deserialization vulnerability in the way React Server Components handle serialized “Flight” protocol payloads between client and server. Instead of just rendering UI in the browser, React Server Components allow parts of the application to run on the server and exchange structured data with the client.

According to the React and NVD advisories:

• The vulnerable code unsafely deserializes payloads from HTTP requests to Server Function endpoints.
  
• An attacker can send a single crafted HTTP request to a vulnerable endpoint and cause arbitrary code execution on the server.
  
• The issue affects RSC packages used in React 19.x, including:
  
  • react-server-dom-parcel
    
  • react-server-dom-turbopack
    
  • react-server-dom-webpack
    

Crucially, applications can be vulnerable even if they do not explicitly use React Server Functions, as long as React Server Components are supported by the framework.

The Next.js ecosystem inherits the same issue through its App Router implementation, tracked as CVE‑2025‑66478, which NVD has since marked as a duplicate of CVE‑2025‑55182.

Why CISOs Are Comparing React2Shell To Log4Shell

React2Shell is not identical to Log4Shell, but it shares some worrying characteristics that matter at a leadership level:

1. Critical severity, pre‑auth RCE
   The vulnerability allows unauthenticated network attackers to execute arbitrary code on the server, with no credentials or user interaction.
   
2. Impacting widely used frameworks by default
   
   • React remains one of the most widely adopted JavaScript frameworks; recent surveys show over 80% of surveyed developers use React in some form.
     
   • Wiz research indicates roughly 39% of cloud environments they analysed contain React or Next.js versions vulnerable to React2Shell‑class issues, and a large fraction of those have publicly exposed applications.
     
3. Default configurations are affected
   A standard Next.js app created with create-next-app and built with App Router can be exploitable without any custom insecure code written by your developers.
   
4. Active exploitation and CISA KEV inclusion
   
   • Amazon has confirmed China‑nexus threat groups began attempting to exploit React2Shell within hours of disclosure, using automated scanning and PoCs.
     
   • CISA added CVE‑2025‑55182 to its Known Exploited Vulnerabilities (KEV) catalog, signalling real‑world exploitation and mandating rapid patching for government environments.
     
5. High likelihood of ransomware and mass‑exploitation
   Bitdefender and other vendors explicitly warn that ransomware groups are expected to weaponize React2Shell for initial access, with potential impact similar to Log4j in environments that adopted server‑side React.
   

For organizations with heavy investment in React 19 and Next.js App Router, React2Shell is a Log4Shell‑style event inside that slice of the stack

Who Is At Risk?

You should assume elevated risk if any of the following are true in your environment:

1. React Server Components (React 19.x)

Per NVD and vendor advisories, the following React Server Components versions are vulnerable:

• Affected React RSC packages:
  
  • react-server-dom-parcel 19.0.0, 19.1.0, 19.1.1, 19.2.0
    
  • react-server-dom-turbopack 19.0.0, 19.1.0, 19.1.1, 19.2.0
    
  • react-server-dom-webpack 19.0.0, 19.1.0, 19.1.1, 19.2.0
    
• Fixed versions:
  
  • 19.0.1
    
  • 19.1.2
    
  • 19.2.1
    

2. Next.js App Router

Tenable and NVD list the following Next.js versions as vulnerable when App Router and RSC are enabled:

• 15.0.4 and below
  
• 15.1.8 and below
  
• 15.2.5 and below
  
• 15.3.5 and below
  
• 15.4.7 and below
  
• 15.5.6 and below
  
• 16.0.6 and below
  
• Certain 14.3.0 canary builds (e.g. 14.3.0‑canary.77 and later)
  

Patched Next.js versions include: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, and 16.0.7.

3. Frameworks That Bundle RSC

Because the root issue sits in the RSC “Flight” protocol, other frameworks that embed React Server Components are also exposed, such as:

• React Router RSC previews
  
• Expo / React Native Web environments using RSC
  
• Redwood SDK
  
• Waku and other RSC‑aware frameworks
  

4. What Is Not Affected?

The vulnerability does not impact:

• Classic, client‑only React apps that do not use React Server Components
  
• Next.js applications using only the legacy Pages Router, without RSC enabled
  
• Older stable versions of Next.js that don’t support the vulnerable RSC pipeline.
  

How Does React2Shell Work? (High‑Level View)

At a conceptual level, React2Shell exploits a trust boundary in the serialization layer between the browser and the server:

1. The client and server exchange structured data using the Flight protocol, which encodes component trees and server function calls.
   
2. Vulnerable RSC code deserializes that data and uses it to look up objects and properties in server‑side structures.
   
3. An attacker sends a carefully crafted payload that abuses this lookup logic to traverse into unintended objects.
   
4. In doing so, the attacker can eventually trigger server‑side behavior that leads to arbitrary code execution under the privileges of the React/Node.js process – before any authentication or normal business logic is reached.
   

You do not need misconfigured “debug” features or explicitly dangerous server functions for exploitation. That’s why many simplistic PoCs that rely on developers exposing functions like child_process.exec are misleading and can cause false negatives when testing.

What We’re Seeing In The Wild

Multiple independent sources now confirm active scanning and exploitation of React2Shell:

• State‑linked activity: AWS reports China‑nexus threat groups such as Earth Lamia and Jackpot Panda attempting to exploit CVE‑2025‑55182 within hours of disclosure, using a mix of automated tools and manual tuning of PoCs.
  
• Rising noise in logs: Vendors and researchers note widespread, often broken PoCs being thrown at RSC endpoints at scale – creating significant noise that can mask more targeted attempts.
  
• Cloud‑scale risk: Wiz telemetry shows nearly 4 in 10 cloud environments they surveyed contain vulnerable React/Next.js versions, and many of those host public‑facing applications.
  
• Ransomware interest: Bitdefender warns that ransomware operators are expected to operationalize React2Shell quickly as an initial access vector, given its unauthenticated nature and prevalence.
  

For CISOs, this combination – broad exposure, simple network delivery, active weaponization, and regulatory pressure via KEV – makes React2Shell a priority‑0 vulnerability.

Run a free React.js exposure assessment as a part of our Free Trial: https://www.firecompass.com/trial

How React2Shell Enables Lateral Movement, Privilege Escalation & Persistence

React2Shell is not the end of the story; it is the beginning of an attack path.

Once an attacker has unauthenticated RCE on a React/Next.js server, they rarely stop at the web tier. They use that foothold to:

• Escalate privileges on the host or in the cloud
  
• Move laterally or application‑hop to adjacent systems
  
• Reach identity systems like Active Directory
  
• Discover and abuse trust into internal networks, databases and CI/CD
  
• Establish persistence that survives patches and rebuilds
  

This is exactly where FireCompass focuses: mapping not just where React2Shell exists, but what an attacker can reach from there.

Below are key ways lateral movement and escalation can unfold from a React2Shell compromise. These can serve as a CISO-friendly narrative and as visuals for security reports, executive briefings, and internal documentation.

From React2Shell On An AWS EC2 Instance To Cloud Takeover

Stages Of The Attack

Stage 1 – Initial foothold via React2Shell

• A vulnerable Next.js App Router or React RSC app is deployed on an EC2 instance.
  
• The attacker sends a crafted Flight/RSC payload and obtains remote code execution inside the Node.js process on that instance.
  

Stage 2 –  Local recon & privilege escalation

• Enumerate environment variables, config files and local secrets.
  
• Identify the instance’s IAM role and any hardcoded API keys or tokens.
  
• Assess what the Node.js process user can access on the OS (logs, SSH keys, deployment scripts).
  

Stage 3 – Pivot into the AWS control plane

• Query the EC2 Instance Metadata Service (IMDS) to retrieve temporary AWS credentials.
  
• Use those credentials to call AWS APIs: list S3 buckets, RDS instances, EKS clusters, and other EC2 instances in the same VPC or account.
  
• Read or snapshot data stores and enumerate additional attack paths.
  

Stage 4 – Lateral movement & persistence

• Move laterally to other EC2 instances in the same subnet/security group.
  
• Deploy miners, backdoors or management agents on multiple hosts.
  
• Create new IAM users/roles or long‑lived access keys for persistence, even if the original EC2 instance is rebuilt.
  

 

Where FireCompass Fits

For this pattern, FireCompass:

• Discovers internet‑facing React/Next.js assets running in cloud environments.
  
• Uses the React2Shell playbook to validate whether RCE is actually possible.
  
• Chains that foothold into cloud‑aware attack paths with CART – showing which AWS accounts, EC2 instances, and data stores are realistically reachable from a compromised RSC app.
  

Instead of a generic “you have vulnerable EC2s,” you get a mapped path from React2Shell to specific cloud assets and data.

From Web Tier To Active Directory & Internal Windows Estate

Stages Of The Attack

Stage 1 – Initial foothold via React2Shell

• A React/Next.js app runs on a Windows server (IIS + Node.js or standalone).
  
• The application uses a domain service account to reach internal resources.
  
• React2Shell gives the attacker RCE under the context of that service account.
  

Stage 2 – Local & domain reconnaissance

• Enumerate the local groups and rights of the service account.
  
• Identify AD domain, forest and group memberships.
  
• Discover reachable internal hosts: file servers, app servers, management servers.
  

Stage 3 – Active Directory‑centric movement

• Abuse over‑privileged service accounts to access file shares or admin tools.
  
• Exploit AD misconfigurations (e.g., weak delegation, excessive group rights, password reuse) to move from:
  
  • The web server
    
  • → to internal app/file servers
    
  • → to management or jump servers
    
  • → potentially to domain controllers.
    
• Harvest cached credentials or configuration secrets used by line‑of‑business apps.
  

Stage 4 – Persistence & business impact

• Create or modify AD users and groups to maintain long‑term access.
  
• Deploy scheduled tasks, services or GPO changes on critical servers.
  
• Access or exfiltrate sensitive data from file shares and databases that were never exposed to the internet.
  
  

Where FireCompass Fits

For Windows/AD environments, FireCompass:

• Identifies externally exposed React/Next.js apps hosted on Windows servers.
  
• Validates React2Shell exposure and then, via CART, models AD‑aware lateral movement from that initial web node.
  
• Helps security teams see how “one React app in the DMZ” can realistically become an AD problem, prioritizing hardening of specific service accounts and paths.
  

Pivoting From DMZ To Internal Network

Stages Of The Attack

Stage 1 –  Initial foothold in the DMZ

• A vulnerable React/Next.js app is deployed in a DMZ network, intended as a buffer between the internet and internal network.
  
• React2Shell gives the attacker RCE on a DMZ host.
  

Stage 2 – Mapping DMZ connectivity

• Scan from the DMZ host to find which internal IP ranges and ports are reachable.
  
• Use DNS, configuration files and routing tables to discover internal hostnames.
  
• Identify allowed flows (e.g., from DMZ to specific app servers or databases).
  

Stage 3 – Application hopping into internal services

• Connect directly to internal application servers or APIs reachable from the DMZ.
  
• Abuse weaker controls on “internal‑only” services that implicitly trust DMZ traffic.
  
• Connect to internal databases over allowed ports and query or modify data.
  

Stage 4 – Deeper access & persistence

• Drop web shells or backdoors on internal systems that only the DMZ can reach.
  
• Use compromised internal apps to further fan out to additional services and users.
  
• Establish persistence on internal hosts so the attacker survives DMZ cleanup. 

Where FireCompass Fits

For DMZ‑centric paths, FireCompass:

• Maps external‑facing assets that terminate in DMZ zones.
  
• Validates React2Shell exposure and then models which internal apps and databases can be reached from those DMZ hosts.
  
• Gives CISOs a concrete view of how a “DMZ‑only incident” can evolve into an internal network breach, driving segmentation and firewall rule reviews.
  

From React2Shell To CI/CD & Software Supply Chain

Stages Of The Attack

Stage 1 – Initial foothold on the app server

• The vulnerable React/Next.js service is built and deployed via CI/CD (GitHub Actions, GitLab CI, Jenkins, etc.).
  
• Build secrets or deploy tokens are present on the server (env vars, config files, mounted volumes).
  

Stage 2 – Secret discovery

• Search for CI/CD tokens, SSH keys, or API credentials on the compromised host.
  
• Identify connections to SCM platforms (GitHub/GitLab/Bitbucket) and build systems.
  

Stage 3 – Pivot into the build pipeline

• Use discovered tokens to access source code repositories.
  
• Modify pipelines to insert malicious steps or dependencies.
  
• Push backdoored builds into multiple environments (dev, staging, production)
  

Stage 4 – Organization‑wide impact

• Compromise multiple applications that rely on the same pipeline.
  
• Introduce persistent supply‑chain backdoors that are hard to spot in individual apps.
  
• Turn a single React2Shell bug into a software supply‑chain incident.

Where FireCompass Fits

For supply‑chain risk, FireCompass:

• Uses its React2Shell playbook to locate exploitable app servers.
  
• Extends testing with CART to simulate access to exposed CI/CD panels and repositories reachable from that foothold.
  
• Helps teams understand how a compromised front‑end can lead to poisoned pipelines and backdoored deployments across the organization.
  

Multi‑Tenant SaaS Blast Radius

Stages Of The Attack

Stage 1 – Initial foothold on shared SaaS front‑end

• A B2B SaaS platform uses Next.js App Router with RSC as the multi‑tenant front‑end.
  
• React2Shell is exploited on that shared front‑end node.
  

Stage 2 – Abusing trust into tenant control planes

• Use the compromised front‑end to access internal tenant APIs with elevated privileges.
  
• Abuse internal service tokens that allow cross‑tenant actions (admin APIs, support tools, “god” roles).
  

Stage 3 – Cross‑tenant lateral movement

• Read or modify data belonging to multiple tenants.
  
• Create or modify tenants, users or configurations to maintain access.
  
• Abuse integrations (webhooks, SSO, connectors) to pivot into customer environments.
  

Stage 4 – Regulatory and contractual fallout

• Large‑scale data exposure across multiple customers.
  
• Cascading breaches as compromised tenants are themselves used as stepping stones.
  
• Significant impact on compliance (e.g., GDPR, HIPAA, sector‑specific requirements).

Where FireCompass Fits

For SaaS providers, FireCompass:

• Identifies shared front‑ends and admin interfaces that are publicly exposed.
  
• Validates React2Shell exposure and models tenant‑aware attack paths via CART.
  
• Helps SaaS security leaders understand how a single React/Next.js bug can translate into multi‑tenant data and trust compromise, informing both technical and contractual risk mitigation.
  

  Run a free React.js exposure assessment as a part of our Free Trial: https://www.firecompass.com/trial

Immediate Mitigation Checklist For Security Leaders

1. Identify Where You Use React Server Components & Next.js App Router

Ask your engineering and platform teams explicitly:

“Which internet‑facing applications are running React 19 with Server Components or Next.js App Router?”

Then validate with:

• SBOM / dependency scans for vulnerable react-server-dom-* packages and affected Next.js versions.
  
• Cloud asset inventories (containers, serverless, edge functions) that may embed RSC frameworks.
  
• External attack surface mapping tools to find forgotten or shadow apps.
  

2. Patch React & Next.js To Safe Versions

Follow vendor guidance to upgrade:

• React Server Components:
  
  • From 19.0.0 → 19.0.1
    
  • From 19.1.x → 19.1.2
    
  • From 19.2.0 → 19.2.1
    
• Next.js App Router: move to one of the fixed releases (15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7) or newer vendor‑recommended versions.
  

Patching must be followed by rebuilding containers / images and redeploying to ensure running workloads pick up the fixed versions.

3. Strengthen Perimeter & Runtime Protections

While patching, you can lower risk with defense‑in‑depth:

• Enable React2Shell‑specific rules in your WAF or edge protection (AWS WAF, Cloudflare, etc.) and monitor for suspicious RSC‑related headers such as Next-Action or rsc-action-id.
  
• Limit network access from RSC/Next.js workloads to only necessary backend services; treat these as exposed “edge” workloads.
  
• Apply container and process hardening controls to restrict what the Node.js process can do on the host.
  

4. Hunt For Indicators Of Compromise

Recommended areas to investigate:

• Network / WAF logs
  
  • POST requests with Next-Action / RSC‑specific headers
    
  • Repeated 500 errors on RSC or App Router endpoints
    
• Host behavior
  
  • Unexpected child processes spawned by Node/Next.js
    
  • High CPU usage without corresponding traffic (cryptomining)
    
  • Attempts to read sensitive files like /etc/passwd or to drop files in /tmp
    
• Cloud signals
  
  • Unusual access to metadata services or secrets from web workloads
    
  • New or unusual API calls from identities tied to React/Next.js infrastructure
    

How To Detect If You Are Vulnerable To React2Shell Using FireCompass

FireCompass React2Shell Playbook

FireCompass has developed a dedicated React2Shell detection playbook to help organizations quickly identify vulnerable and exposed instances of CVE‑2025‑55182 / CVE‑2025‑66478 across their external attack surface.

Inspired by real attacker tradecraft and community research, this playbook combines:

• NextGen External Attack Surface Management (ASM):
  Continuous discovery of internet‑facing domains, subdomains, IPs and services where React / Next.js applications may be deployed.
  
• Technology fingerprinting:
  Non‑intrusive techniques to detect React 19, Next.js App Router, and other RSC‑enabled frameworks, even when not obviously labelled.
  
• Multi‑stage, high‑fidelity validation:
  The playbook uses a safe, multi‑step attack tree that mimics how real attackers validate React2Shell exposures – checking error patterns and responses associated with vulnerable RSC behavior, while avoiding payloads that could impact availability.
  

What FireCompass Customers Can Do Today

FireCompass customers can:

• Run a React2Shell (CVE‑2025‑55182) module from within the platform to:
  
  • Enumerate all externally visible assets that may host React/Next.js apps
    
  • Automatically test for React Server Components and known vulnerable versions
    
  • Validate potential exposures using our React2Shell playbook, which chains multiple checks to reduce false positives
    
• Use Continuous Automated Red Teaming (CART) to simulate how an attacker would pivot from a React2Shell‑compromised web app into other systems – for example, lateral movement to internal APIs, credential harvesting, or data exfiltration.
  
• Prioritize remediation by risk and exposure, not just CVE count – focusing first on internet‑facing RSC workloads with sensitive data or access to critical backends.
  

This approach ensures security teams don’t just know that the organization “uses React somewhere,” but can pinpoint exactly which hosts and applications are exploitable and verify that fixes are effective.

Conclusion

React2Shell is a strong reminder that modern web stacks are part of your critical infrastructure, not “just front‑end code.” A single deserialization flaw in a popular framework can create a direct path from the internet to remote code execution on your servers.

For CISOs and security leaders, the React2Shell response should focus on:

• Rapid visibility: Where are React Server Components and Next.js App Router actually exposed?
  
• Urgent patching: Upgrade React/Next.js to fixed versions and redeploy affected workloads.
  
• Attack‑centric validation: Confirm whether React2Shell is truly exploitable in your environment, not just theoretically present in a package list.
  
• Continuous testing: Integrate similar scenarios into ongoing external attack surface monitoring and automated red teaming.
  

FireCompass helps organizations stay ahead of such critical RCEs by continuously mapping the external attack surface and running CART‑driven playbooks, such as our new React2Shell playbook, to detect and validate real‑world exploitable paths before attackers do.

Run a free React.js exposure assessment as a part of our Free Trial: https://www.firecompass.com/trial