TL;DR
React2Shell (CVE-2025-55182) creates a critical RCE risk across React Server Components (RSC) and frameworks that embed them, including Next.js. Because the vulnerability lives inside the RSC serialization and deserialization layer, attackers can send a crafted HTTP request and trigger unauthenticated remote code execution, even when teams run default framework configurations. Next.js applications face the highest exposure because they accept and process React Flight payloads over HTTP by default.
The flaw affects multiple versions of React server packages, and attackers do not need custom application logic to exploit it. Security researchers show near-100% reliability, and early scans reveal that many cloud environments run vulnerable Next.js instances. Teams must patch immediately and validate their full ecosystem to shrink the React2Shell (CVE-2025-55182) RCE risk.
A critical vulnerability reported through Meta’s bug bounty program on November 29th has triggered urgent responses across the JavaScript ecosystem.
Designated CVE-2025-55182, disclosed on December 3rd now referred to as React2Shell is a maximum-severity vulnerability that impacts React Server Components along with frameworks that incorporate them. Initially, a separate Next.js vulnerability identifier (CVE-2025-66478) was assigned, but the NVD later consolidated it into the primary React CVE as a duplicate entry.
The underlying issue is the same, unsafe handling of serialized RSC payloads that can be triggered through a HTTP request. This opens the door for a malicious actor to send a manipulated HTTP request that results in arbitrary JavaScript running on the server after being deserialized by React.
CVE-2025-55182 Overview
React Server Components are deeply integrated into modern frameworks, and in many cases are enabled by default. Because of this, applications may be exposed to React2Shell (CVE-2025-55182) even if they never explicitly define a Server Function endpoint. The RSC implementation is still present, and that alone is enough to activate vulnerable code paths and create a significant RCE risk.
The flaw stems from the way the React Flight protocol processes certain structured payloads. Older versions attempted to walk object paths supplied in the payload without verifying that the structure was valid or expected. An attacker could manipulate this process and ultimately reach code execution on the server. No authentication, no special configuration, and no app-specific logic required. Since the issue exists in out-of-the-box configurations, standard deployments are exposed without needing any unusual conditions.
Exploitation occurs when attackers send malicious HTTP POST requests that abuse the “vm.runInThisContext” mechanism through Server Actions. While React doesn’t directly expose the vulnerable endpoint, Next.js does, creating a genuine remote attack vector.
Next.js accepts Flight payloads from any request, processes them without proper validation, and passes them to React’s deserializer. The system treats these external inputs as trusted, enabling attackers to achieve remote code execution through publicly accessible endpoints with full Node.js process privileges on the target server.
The severity increases significantly because default configurations remain vulnerable to React2Shell (CVE-2025-55182) and the resulting RCE risk. A standard Next.js application you create with create-next-app exposes itself without requiring any custom code or configuration changes. Security researchers confirm nearly 100% exploitation reliability and report that 39% of cloud environments run vulnerable instances, while 44% of all environments run publicly exposed Next.js applications affected by React2Shell.
Understanding Exposure to React2Shell
The vulnerable versions span multiple releases:
| Component | Affected Versions |
|---|---|
| react-server-dom-webpack | 19.0, 19.1.0, 19.1.1, 19.2.0 |
| react-server-dom-parcel | 19.0, 19.1.0, 19.1.1, 19.2.0 |
| react-server-dom-turbopack | 19.0, 19.1.0, 19.1.1, 19.2.0 |
Because many frameworks embed RSC support at the core, applications often inherit the vulnerable code without realizing it. Any framework or bundler that ships these packages can expose the application to React2Shell (CVE-2025-55182) and its RCE risk. That includes:
- Next.js (App router)
- React Router RSC preview
- Vite RSC plugin
- Parcel RSC plugin
- Redwood SDK
- Waku
- Expo
Next.js is particularly impacted because it uses RSC-related endpoints over HTTP by default. Versions beginning with the 14.3.0 canary builds, along with most 15.x and early 16.x releases, contain the vulnerable implementation. Anyone running canary 14.3.0-canary.77 or later should revert to the stable 14.x branch until a patched canary version is published.
Patched Next.js versions include:
| Component | Patched Versions |
|---|---|
| Next.js | 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7 |
Public PoCs and Reliable Detection
Following the vulnerability disclosure, numerous supposed proof-of-concepts started circulating. Many of them were either inaccurate or based on flawed assumptions. The original vulnerability author, Lachlan Davidson, publicly confirmed on react2shell that the GitHub PoCs circulating do not match the exploit shared privately with React/Next.js maintainers and provided his own PoC.
A major problem with early public attempts is their failure to recognize that exploitation succeeds against standard Next.js deployments without requiring specific application logic or server-side functions to be present.
Security researchers from multiple organizations have emphasized that detecting the vulnerability requires more than simply identifying whether RSC is present. Assetnote’s team published a reliable detection method and a scanner capable of confirming the issue without using any exploit logic. Metasploit will soon have an available exploit for this vulnerability as well.
The detection approach leverages how React Server handles object property references using colon delimiters within the ReactFlightClientConfigBundlerWebpack.js/requireModule() function. When vulnerable versions process a specially structured multipart payload that attempts to traverse non-existent nested object paths, they trigger predictable error responses. A diagnostic request sends a reference pattern like `$1:a:a` paired with an empty object. Vulnerable implementations attempt to resolve this as nested property access on an undefined value, resulting in an exception. The server returns a 500 status with a distinctive error digest pattern in the response body.
export function requireModule<T>(metadata: ClientReference<T>): T {
let moduleExports = __webpack_require__(metadata[ID]);
if (isAsyncImport(metadata)) {
if (typeof moduleExports.then !== 'function') {
// This wasn't a promise after all.
} else if (moduleExports.status === 'fulfilled') {
// This Promise should've been instrumented by preloadModule.
moduleExports = moduleExports.value;
} else {
throw moduleExports.reason;
}
}
if (metadata[NAME] === '*') {
// This is a placeholder value that represents that the caller imported this
// as a CommonJS module as is.
return moduleExports;
}
if (metadata[NAME] === '') {
// This is a placeholder value that represents that the caller accessed the
// default property of this if it was an ESM interop module.
return moduleExports.__esModule ? moduleExports.default : moduleExports;
}
return moduleExports[metadata[NAME]];
}
Immediate Actions for Organizations Facing React2Shell (CVE-2025-55182) and the RCE Risk
Conduct a comprehensive scan of your codebase and deployed applications to locate vulnerable package versions. Pay special attention to direct React server package dependencies, Framework-level RSC implementations (Next.js, Waku, Redwood, etc.), applications built with `create-next-app` or similar scaffolding tools and containerized applications that may contain outdated base images.
Software Composition Analysis (SCA) tools like Xygeni’s SCA can automatically discover affected dependencies throughout your software inventory.
Patch immediately:
Update to patched versions such as React (19.0.1, 19.1.2, 19.2.1), Next.js (15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7) and any framework packages that include RSC. These updates introduce strict validation for RSC payload handling and prevent the unsafe property dereferencing that enables exploitation.
Automated remediation tools, such as Xygeni’s auto-remediation feature, can accelerate the process across large codebases.
Implement Temporary WAF Protections:
While patches propagate through your deployment pipeline, activate Web Application Firewall rules for immediate protection. Major cloud providers have released emergency rulesets, Cloudflare: Automatic protection for all tiers when React traffic is proxied as well as AWS, Akamai, Fastly, Google Cloud have similar defensive rules available Enable these controls immediately to create a protective layer during the transition period.
Monitor for suspicious HTTP traffic:
Configure logging and alerting for indicators of exploitation attempts:Malformed or unexpected RSC Flight protocol payloads, unusual patterns of 500 errors on RSC endpoints, POST requests with suspicious `Next-Action` or `Next-Router-State-Tree` headers, Repeated requests to `/_next/` paths with multipart payloads
Verify Your Software Bill of Materials:
Many frameworks bundle RSC dependencies transparently, making them invisible in surface-level dependency reviews. Examine your complete SBOM to ensure: No transitive dependencies on vulnerable React server packages remain, framework updates haven’t inadvertently introduced older RSC implementations.
Closing Thoughts
React2Shell ranks among the most serious JavaScript ecosystem vulnerabilities in recent years, not because the exploit is complex but because RSC runs so deeply through today’s tooling. Now that patches are available across the ecosystem, teams must push upgrades into production as quickly as possible.
If your application uses React’s server features, whether directly or indirectly, you must treat this vulnerability as a top-priority fix.
