What you need to know

• Who is affected: Any application running the relatively recent React 19 Server Components or Next.js server actions that rely on them. This includes freshly generated projects built using create-next-app with no code modifications.
• Severity: Both CVEs are rated 10.0 critical, reflecting unauthenticated, one-request, reliable RCE. Published PoCs confirm that arbitrary command execution is possible.
• Exploitation: Confirmed as possible by the vendor via unsafe deserialization in the React Flight protocol. First exploits were seen in the wild on December 4th and widespread exploitation is expected.
• Cloud provider mitigations: Cloudflare has deployed network-level request filtering to block known exploit payload patterns for customers using its WAF. Similar mitigations may appear from other providers, but they are not substitutes for patching.
• Invicti response: Security checks have been created for Invicti DAST products to identify and report vulnerable endpoints.
• Immediate next steps: Patch affected React and Next.js versions (see detailed remediation guidance below), rebuild deployments, verify exposure across all applications, and review logs for suspicious server action requests.

See the official React advisory and Next.js advisory for the latest patched versions. 

React2Shell in a nutshell: The anatomy of a one-request RCE

React 19 introduced React Server Components (RSC) and server actions to support richer server-driven UI architectures. These features rely on the custom binary Flight protocol, which serializes component data between client and server. In affected versions, the server-side decoder trusts several types of Flight records that an attacker can spoof, which allows malicious payloads to be delivered and executed by the server.

Next.js directly inherits this risk because its server actions are built on top of the same RSC runtime. In fact, the NVD flags the Next.js CVE as a duplicate since it covers the exact same code. Even apps that don’t implement any React Server Function endpoints may be vulnerable merely due to supporting RSC. This also applies to affected Next.js versions since they enable RSC features by default as part of the standard project template.

The result is a highly exposed, low-friction attack surface, where any public route that triggers server action handling becomes a potential code execution point. According to Wiz Research, up to 39% of cloud environments may contain a vulnerable application instance.

“Considering how common Next.js is, this could be the biggest application vulnerability of 2025,” says Bogdan Calin, Principal Security Researcher at Invicti. “For attackers, it has the advantage that you can adjust the payloads in practically infinite ways to bypass WAFs, which is huge. Some companies delay or completely skip security patches and rely only on their WAF or cloud provider to stop attacks. Once mass exploitation starts, WAF protections will quickly get bypassed and any unpatched instances will be hit.”

Technical analysis of CVE-2025-55182 in React Server Components

The root cause of the vulnerability is unsafe deserialization in the RSC Flight protocol. React’s server-side decoder for this protocol processes various markers that indicate function references, closures, or arguments that should originate from trusted internal calls. In vulnerable releases, the decoder accepts attacker-controlled values for these markers without validation.

Key properties of the exploit path:

• The attack only needs a single pre-authentication HTTP request containing malicious Flight records.
• The decoder feeds untrusted data to server functions without guarding against untrusted instruction types.
• Execution occurs inside the runtime, giving the attacker full access to server-side JavaScript capabilities.
• The attack flow does not depend on application code but exploits the protocol layer itself.

Next.js re-exposes this pathway through its server actions API. Production builds for a standard Next.js application already include RSC endpoints that can be reached without any special routing or configuration. Under the hood, Next.js performs deserialization similar to React’s reference implementation, inheriting identical weaknesses.

Once arbitrary JavaScript execution is achieved, attackers would be able to read secrets, deploy backdoors, or pivot laterally into internal services, as with any RCE. While no exploits have been seen in the wild as of this writing (and no reliable PoC has been published), the impact of successful exploitation could be massive due to the minimal prerequisites and reliable execution path.

Current remediation status

The vulnerability was responsibly reported to the React team by security researcher Lachlan Davidson on November 29th, 2025. On December 3rd, the fix was published to npm and publicly disclosed as CVE-2025-55182. As exploits started appearing in the wild, Lachlan eventually published his original PoC.

React has published patched versions of all relevant RSC packages, including the Flight runtime modules. Next.js has released updated versions that replace vulnerable components and align with the patched RSC behavior.

Cloudflare has deployed temporary mitigations across its WAF to detect and block known malicious payload structures associated with attempted RSC exploitation. These mitigations may prevent opportunistic scanning but cannot guarantee protection against evolving payloads. Other cloud security providers are expected to follow with similar generic pattern-based blocking.

As stressed in the React advisory, organizations should treat these mitigations strictly as stopgap measures. The only reliable fix is to patch and redeploy affected applications.

Invicti security checks for CVE-2025-55182 and CVE-2025-66478

As of December 5th, Invicti DAST products include security checks for React Server Components remote code execution. These checks help teams identify unpatched deployments and confirm actual reachability of vulnerable RSC endpoints in running applications.

Remediation steps for CVE-2025-55182 and CVE-2025-66478

Different remediation paths apply depending on which framework or packages you use. Considering the widespread use of React, it’s a good idea to check if React 19 is indirectly used anywhere in your organization even if you’re not directly affected.

Remediation for React 19 Server Components users

1. You are affected if you use version 19.0, 19.1.0, 19.1.1, or 19.2.0 for any of the following packages:
   
   • react-server-dom-webpack
   • react-server-dom-parcel
   • react-server-dom-turbopack
2. Upgrade to the latest patched versions of those packages specified by React. As of Dec 4th, patched versions are 19.0.1, 19.1.2, and 19.2.1.
3. Rebuild and redeploy all environments.
4. Confirm that no custom bundler or framework pins older RSC dependencies.

Remediation for Next.js users

1. You are affected if you use an unpatched 15.x or 16.x release.
2. Upgrade to the latest patched Next.js release specified in the official advisory. As of Dec 4th, patched versions are 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, and 16.0.7.
3. Rebuild production artifacts to remove vulnerable server action code paths.
4. Verify that your project does not use a locked React version preventing RSC updates.
5. Check Vercel, container, and self-hosted images to confirm they pull the updated packages.

Another day, another critical one-request RCE

React2Shell sits in the same class of catastrophic, low-effort exploit paths as past one-shot RCEs. The industry has been here before:

• The Log4Shell vulnerability showed how a simple deserialization path could threaten global infrastructure almost overnight.
• A more recent Next.js middleware bypass demonstrated how small logic gaps in popular frameworks can create immediate, internet-wide exposure.

React2Shell has similar potential reach. Large ecosystems, default-enabled features, and minimal attacker prerequisites combine into an unusually dangerous situation, especially with the widespread use of Next.js in newly generated applications. The silver lining is that the affected tech stack is a relatively new setup and most organizations will still be running older versions that aren’t affected.

Exploits are already circulating and WAFs can’t stop all of them, so calmly check if you’re affected and patch now.

‍