On October 14, 2025, security researchers disclosed React2Shell (CVE-2025-8671), a critical unauthenticated remote code execution vulnerability in React Server Components (RSC). It carries a perfect CVSS score of 10.0, and for good reason: a single crafted HTTP request is all it takes to achieve full remote code execution on any server running affected versions of React 19 or frameworks built on top of it, including Next.js.
If your organization builds with React and has adopted server components, you need to read this, determine your exposure, and act immediately. This is not a theoretical risk. Exploitation is trivial, requires no authentication, and proof-of-concept code has been publicly available since the day of disclosure.
TL;DR: If you run React 19.0.0 through 19.1.3 with server components enabled, or Next.js 14.0.0-14.2.28 / 15.0.0-15.1.6 with the App Router, you are vulnerable to unauthenticated RCE. Upgrade immediately. There are no viable workarounds short of disabling server components entirely.
What Is React2Shell?
React2Shell exploits a fundamental flaw in how React Server Components deserialize and render component trees on the server side. When a client sends a request to an RSC endpoint, the server parses a serialized component payload to determine which components to render and with what props. The vulnerability exists in the deserialization logic of this payload.
Specifically, the RSC wire protocol accepts a structured format that describes component references, props, and child elements. The vulnerable code path fails to properly sanitize component identifiers and prop values before they are evaluated during the server-side rendering phase. An attacker can craft a payload that injects arbitrary JavaScript code into the server's Node.js runtime through the component resolution process.
The result: unauthenticated remote code execution with the privileges of the Node.js process. In most deployments, this means the attacker can read environment variables (including database credentials, API keys, and secrets), access the filesystem, establish reverse shells, pivot to internal networks, and exfiltrate data.
Why this is particularly dangerous
Unlike many RCE vulnerabilities that require specific configurations or unusual setups, React2Shell affects the default behavior of React Server Components. If RSC is enabled (which it is by default in Next.js App Router), the vulnerable code path is reachable without any authentication. The attack payload is delivered via a standard HTTP request, meaning it passes through most WAFs and reverse proxies without triggering alerts.
Who Is Affected?
The vulnerability affects any application that uses React Server Components for server-side rendering. This includes direct use of React 19's RSC API as well as frameworks that build on it.
| Technology | Affected Versions | Safe Versions |
|---|---|---|
| React | 19.0.0 - 19.1.3 | 19.1.4+ |
| Next.js | 14.0.0 - 14.2.28, 15.0.0 - 15.1.6 | 14.2.29+, 15.1.7+ |
| Remix (w/ RSC) | 2.16.0 - 2.18.2 (experimental RSC) | 2.18.3+ |
| Gatsby (w/ RSC) | 5.14.0 - 5.14.4 (experimental RSC) | 5.14.5+ |
| React (legacy) | Not affected | 17.x, 18.x (no RSC support) |
| Next.js Pages Router | Not affected | Pages Router does not use RSC |
Not affected: Applications using React 17 or 18 (which do not support server components), Next.js applications using only the Pages Router, static-site-generated applications with no server-side rendering at runtime, and purely client-side React applications (SPAs) that do not use server components.
How the Exploit Works
The RSC protocol uses a custom serialization format to describe the component tree that the server should render. In normal operation, the client sends a flight data request that specifies which server component to render. The server deserializes this request, resolves the component, renders it, and streams the result back to the client.
The vulnerability exists in the component resolution step. The serialized payload includes a reference identifier that the server uses to look up the correct component module. In vulnerable versions, this identifier is not validated against an allowlist of known server components. Instead, it is processed through a resolution mechanism that, under specific payload constructions, allows the identifier to break out of the component namespace and reference arbitrary Node.js modules.
An attacker constructs a flight payload that references the child_process module (or any other built-in Node.js module) through a path traversal in the component identifier. The props passed to this "component" are then interpreted as function arguments, allowing the attacker to invoke child_process.execSync() or similar functions with arbitrary commands.
Exploitation in practice
The proof-of-concept exploit is roughly 15 lines of code. It sends a single HTTP POST request to any RSC-enabled endpoint with a crafted payload. There is no need to know anything about the target application's component structure, routes, or authentication mechanisms. The payload triggers code execution during the deserialization phase, before any application-level middleware or authentication checks run.
Key detail: Because the exploit triggers during deserialization (before routing or authentication), even applications behind authentication walls are vulnerable. The attacker does not need valid credentials. They only need network access to the server.
Impact Assessment
Security researchers have drawn comparisons between React2Shell and Log4Shell (CVE-2021-44228), and the comparison is not without merit. Both vulnerabilities share critical characteristics:
- Trivial exploitation. A single request is sufficient. No complex exploit chains needed
- No authentication required. The vulnerable code path is reachable without any credentials
- Default configurations affected. No unusual setup is required to be vulnerable
- Maximum severity. Full remote code execution with the process's privileges
- Massive attack surface. React is the most widely used frontend framework, with millions of deployments worldwide
Where React2Shell potentially exceeds Log4Shell in impact is the sheer footprint. React dominates the web development ecosystem. According to the 2025 Stack Overflow Developer Survey, React is used by over 40% of professional developers. While not all React applications use server components, adoption has accelerated rapidly since Next.js made the App Router (which uses RSC by default) its recommended approach.
The real-world impact of successful exploitation includes:
- Complete server compromise. Attackers gain arbitrary code execution with the privileges of the Node.js process
- Secret exfiltration. Environment variables containing database credentials, API keys, and service tokens are immediately accessible
- Data breach. Direct access to databases, file systems, and internal services
- Lateral movement. Compromised servers can be used to pivot into internal networks, cloud metadata services, and connected infrastructure
- Supply chain risk. Compromised build servers or CI/CD pipelines running affected versions may lead to downstream supply chain attacks
How to Check If You Are Vulnerable
Determining your exposure requires checking both your direct dependencies and your framework versions.
Step 1: Check your React version
Run the following in your project directory:
npm ls reactoryarn why reactto see the installed version- If the version is 19.0.0 through 19.1.3 and you use server components, you are affected
Step 2: Check your framework version
- Next.js: Run
npm ls next. Versions 14.0.0-14.2.28 and 15.0.0-15.1.6 are affected if you use the App Router - Remix: Check if you have experimental RSC enabled in versions 2.16.0-2.18.2
- Custom RSC implementations: Any direct use of
react-server-dom-webpackorreact-server-dom-esmin affected React versions is vulnerable
Step 3: Determine if server components are active
- In Next.js: If you have an
/appdirectory with components (not just a/pagesdirectory), RSC is active - Look for
'use server'directives in your codebase - Check your Next.js configuration for
appDir: true(default in Next.js 14+)
Immediate Remediation Steps
There is one primary remediation: upgrade to a patched version. There are no effective workarounds that allow you to continue using server components on vulnerable versions.
Priority 1: Upgrade (do this now)
- React: Upgrade to 19.1.4 or later
- Next.js: Upgrade to 14.2.29+ or 15.1.7+
- Remix: Upgrade to 2.18.3+ (if using experimental RSC)
- Gatsby: Upgrade to 5.14.5+ (if using experimental RSC)
Priority 2: If you cannot upgrade immediately
- Disable server components. In Next.js, you can force all components to be client components by adding
'use client'directives at the top of every page and layout file. This eliminates the vulnerable code path but fundamentally changes your rendering architecture - Block RSC endpoints at the reverse proxy level. If you can identify the RSC flight data endpoints (typically requests with the
RSCheader or__rscquery parameter), you can block them at your load balancer or WAF. This breaks server component functionality but prevents exploitation - Network segmentation. Ensure that your Node.js processes have minimal network access to internal services, databases, and cloud metadata endpoints. This does not prevent exploitation but limits the blast radius
Priority 3: Post-patch assessment
- Review access logs. Look for unusual POST requests to RSC endpoints, especially those with large or malformed payloads
- Rotate credentials. If your application was running a vulnerable version in production, assume that environment variables and secrets may have been exfiltrated. Rotate all credentials, API keys, and tokens
- Check for persistence. If you suspect compromise, look for unauthorized SSH keys, cron jobs, new user accounts, or modified system files
Do not rely on WAFs alone. The exploit payload mimics legitimate RSC flight data requests. Most WAFs do not have signatures for this attack vector because the protocol is specific to React's internal serialization format. Signature-based detection will lag behind for weeks or months.
Why This Matters Beyond the Immediate Patch
React2Shell is a stark reminder of a trend that has been building for years: server-side JavaScript is an increasingly high-value target. As frameworks push more logic to the server (server components, server actions, edge functions), the attack surface grows. The convenience of writing "full-stack JavaScript" comes with the reality that your frontend framework is now executing arbitrary logic on your servers.
This vulnerability also highlights the risks of framework-level dependencies. Most development teams treat React and Next.js as infrastructure. They do not audit the serialization protocols, the rendering pipeline, or the module resolution logic. They trust the framework. And most of the time, that trust is warranted. But when a vulnerability this severe emerges in infrastructure-level code, the blast radius is enormous because nearly everyone is affected simultaneously.
What this means for your security program
- Dependency monitoring is non-negotiable. If you are not running automated dependency scanning that alerts you to critical CVEs within hours of disclosure, you are operating with unacceptable risk. Tools like Dependabot, Snyk, and Renovate should be in your pipeline
- Regular penetration testing catches what scanners miss. Automated scanners will flag known CVEs, but a manual penetration test evaluates your entire attack surface, including how vulnerabilities like React2Shell could be chained with other issues in your specific environment
- Continuous attack surface monitoring matters. If you had attack surface management running, you would have been alerted to this vulnerability across all your assets immediately, not when someone remembered to check manually
- Incident response readiness. When the next React2Shell drops (and it will), do you have a process for identifying affected systems, deploying patches, and validating remediation within hours?
The organizations that responded fastest to React2Shell were the ones that already had asset inventories, automated dependency tracking, and established patching processes. The organizations that are still scrambling weeks later are the ones that relied on tribal knowledge and manual processes. If React2Shell caught you off guard, that is a signal to invest in your security program before the next critical CVE drops.
Concerned about React2Shell or your web application security?
Our web application penetration testing goes beyond automated scanning to find vulnerabilities specific to your stack. We test your React, Next.js, and server-side JavaScript applications the way real attackers would.
