How to React(.js) to React2Shell & Catch the Next(.js) Big RCE

Critical vulnerabilities in React Server Components (CVE-2025-55182) and Next.js (CVE-2025-66478) enable unauthenticated remote code execution in default configurations. The flaw resides in the "Flight" protocol used for server-side rendering, making it a sought after target for adversaries looking to bypass standard controls. While the public discourse is currently cluttered with unreliable exploits, we need to ground our defense in verifiable network evidence. Recent research from Searchlight Cyber provides a foundation for creating high-fidelity Suricata detections to spot these attacks on the wire immediately. However, as this traffic will commonly be encrypted, we must also identify the behaviors that indicate successful exploitation and subsequent post-compromise activity.

Understanding the "Flight" protocol flaw

To understand the scope of this threat, we must look at the machinery that powers React Server Components (RSC). As described by Palo Alto Networks Unit 42, the "Flight" protocol serves as the transport layer that serializes the server-side component tree into a streamable format for the client. According to the official React advisory, the packages in question (react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack) act as the essential translation layer between the React framework and your specific bundler.

The vulnerability is a deterministic logic flaw within the deserialization process of this protocol. Specifically, Searchlight Cyber researchers identified that the issue resides in how the react-server dependency handles object property access using colon delimiters. This flaw in the React library itself is tracked as CVE-2025-55182, according to the React team. When the server receives a request, the underlying code attempts to resolve references by splitting the string path by colons and iterating through them to retrieve the value, as shown in the code analysis by Searchlight Cyber.

In vulnerable versions, Searchlight Cyber notes that the function responsible for this logic fails to validate that the object being accessed actually exists before attempting to read a property from it. While the core flaw lies in React, Palo Alto Networks confirms that Next.js is directly impacted as CVE-2025-66478 (now considered a duplicate of CVE-2025-55182) because its App Router utilizes these vulnerable packages by default.

The Mechanism: Searchlight Cyber's analysis shows the code blindly executes value = value[path[i]] inside a loop.
The Failure: If an attacker sends a crafted payload such as ["$1:a:a"], the server interprets this as {}.a.a. As Searchlight Cyber explains, the first access ({}.a) returns undefined, and the subsequent attempt to access property .a on undefined triggers a crash.
The Consequence: Searchlight Cyber observed that patched versions introduce a check (typeof value === 'object') to ensure the property exists before access. Without this check, the unvalidated access allows an attacker to manipulate the prototype chain or access internal modules, insecure deserialization into full Remote Code Execution (RCE).

High-fidelity detection on the wire

Based on the research provided by Searchlight Cyber and Palo Alto Networks Unit 42, as well as public information put out by the official projects, we can deploy immediate detection for these exploit attempts by focusing on the specific structure of the HTTP request. The attack relies on sending a POST request that triggers a Next.js Server Action, identifiable by the Next-Action header, carrying a multipart/form-data payload. Unit 42 analysis confirms that this exploit is highly reliable against default configurations and requires no code changes to be effective, which makes precise network identification critical.

For Corelight customers, we have released specific Suricata signatures to identify both the exploitation attempts and the server responses that confirm vulnerability. The primary detection, CORELIGHT EXPLOIT Next.js RSC RCE Exploit Attempt (CVE-2025-55182), identifies the exact ["$1:a:a"] object reference sequence reported in initial proofs-of-concept. To address potential variations in the object index (such as $2:b:b), we also provide CORELIGHT EXPLOIT Next.js RSC RCE Evasion Attempt (PCRE Match) (CVE-2025-55182), which uses regular expressions to catch evasion attempts in the payload structure.

Detection is most valuable when we can differentiate between a failed attempt and a successful compromise. The vulnerable react-server-dom packages emit a distinct error pattern when the deserialization crash occurs. By monitoring for a 500 status code containing the E{"digest" pattern in the response body, the CORELIGHT EXPLOIT Next.js RSC Vulnerable Response Observed (CVE-2025-55182) signature allows defenders to positively identify unpatched servers. Additionally, we have included CORELIGHT HUNTING Suspicious Next.js Router State (react2shell-scanner) to flag activity from specific scanning tools recently released by Searchlight Cyber.

These signatures provide strong coverage for cleartext traffic or environments where TLS decryption is available. However, in most production deployments, this traffic will be encrypted over HTTPS, rendering payload-based signatures blind to the JSON structure or specific headers. This limitation necessitates a shift in strategy. We must look for the anomalous behaviors and traffic patterns that serve as indicators of both the attempt and the subsequent post-exploitation activity.

Hunting without a PoC: the behavioral approach

Signatures are invaluable, but they rely on visibility into the payload that encryption often obscures. When TLS blinds us to the specific JSON structure of an attack, we must shift our strategy from matching bytes to analyzing behaviors. This aligns with the "No PoCs? No Problem" philosophy I’ve discussed regarding other recent exploits. Even without seeing the malicious $1:a:a object reference inside the packet, the network reveals the impact of the exploit on the server's traffic patterns.

To find these anomalies, we must first understand what "normal" looks like. As shown in the diagram below, a healthy Next.js application backend operates with high predictability.

In this state, the server accepts ingress traffic on standard web ports (80/443) and initiates downstream connections only to specific known resources, such as an application microservice on port 443 or a SQL database on port 3306. This deterministic behavior creates a stable baseline for detection. When an adversary successfully exploits CVE-2025-55182 to achieve RCE, this traffic profile shifts immediately.

Adversaries rely on specific ports to evade detection or because they fail to change default configurations. Blog posts and threat intelligence reports have consistently listed this sort of information and we can categorize these into two distinct groups you must monitor:

Evasion (Blending in) Most sophisticated actors use these ports to hide in plain sight.

443 (HTTPS): It is no surprise this is the top choice, as encrypted traffic is standard for React and Next.js systems. Unit 42 (2025) and Mandiant report that encryption remains the standard for obfuscating C2 traffic.
80 (HTTP): While unencrypted, HTTP traffic remains common enough that novel attacks can bypass signatures. Furthermore, the sheer volume of diverse destinations makes baselining difficult in most environments. Recorded Future (2024) notes this remains a high-volume vector for initial stage loaders and unencrypted C2.

Framework Defaults (High Fidelity Indicators) These ports often indicate an attacker forgot to change the default config of an Offensive Security Tool (OST).

50050 (Cobalt Strike): The default Team Server port for one of the most prolific attack tools.
8888 (Sliver): The default mTLS listening port for the rising Go-based Sliver framework.
4444 (Metasploit): The pervasive default "LPORT" for Meterpreter, still common in automated scanners and in the wild.

The compromised server deviates from its established baseline. As illustrated above, the attacker might establish a reverse shell outbound on a non-standard port like 4444 or open a listener for a web shell on a random high port like 50321. We also frequently observe common post-exploitation tactics, such as initiating network scans against internal subnets to map the environment. Even if the scan was so slow that it only checked one new port per year, it could be detected immediately the first time it communicates with any port out of the baseline.

This is where Corelight’s enhanced anomaly detection becomes a critical engine for discovery. By using peer group modeling, our system compares a device's behavior against other devices in the same functional group. If one Next.js node suddenly begins scanning internal ports or communicating with an unapproved external IP while its peers remain quiet, the system flags this deviation. As we saw with the Salt Typhoon investigations, these post-exploitation artifacts, such as unauthorized SSH connections, file transfers, or tunneling, often stand out clearly when viewed through the PEAK framework, even when the traffic exploit was encrypted.

The truth is on the network

We cannot patch what we cannot see. While upgrading the affected React and Next.js packages is the only permanent fix for these vulnerabilities, relying solely on application updates leaves a dangerous gap between disclosure and remediation. Network visibility provides the verification that your defenses are actually holding. By combining high-fidelity signatures for cleartext traffic with behavioral anomaly detection for encrypted streams, Corelight provides the ground truth necessary to distinguish between a scanner probing your perimeter and an active compromise moving laterally through your environment.

Looking for more threat hunting tips like this? Check out the Threat Hunting section of our website for other helpful guides and tutorials.