From Zero to RCE: How a Single HTTP Request Compromises React and Next.js Applications

On December 3, 2025, the React team disclosed CVE-2025-55182, a critical remote code execution vulnerability in React Server Components. The flaw carries a CVSS score of 10.0, the maximum severity rating. What makes this vulnerability particularly dangerous is its simplicity: attackers only need to send a single crafted HTTP request to gain complete control over vulnerable servers. No authentication required. No complex exploit chains. Just one malicious request.

The vulnerability affects React versions 19.0.0 through 19.2.0 and extends across the entire React Server Components ecosystem, including Next.js, Vite, Parcel, React Router, RedwoodJS, and Waku. More concerning, standard applications created with create-next-app are vulnerable in their default configurations, meaning developers didn’t need to make any mistakes for their applications to be at risk.

How React server components created an attack surface

React Server Components (RSC) introduced a new architecture that allows React to render components on the server and stream the results to clients. To make this work, React developed the “Flight” protocol, which serializes component trees, props, and data into a format that browsers can receive and render.

Server Functions (also called Server Actions) complement this architecture. They let client-side code call server-side functions seamlessly. Behind the scenes, React exposes these as HTTP endpoints that accept serialized data from clients. This is where the vulnerability lives.

When a client wants to call a Server Function, it sends a POST request to the server with a serialized payload. The server receives this payload, deserializes it (converts it back from the transmission format into executable code and data), and processes the function call. The problem is that React’s deserialization code didn’t properly validate what it was receiving. An attacker can craft a malicious payload that, when deserialized, executes arbitrary code on the server with the same privileges as the Node.js process running the application.

The technical flaw: Insecure deserialization

The flaw exists in three related packages within React’s server-side rendering stack:

react-server-dom-webpack

react-server-dom-parcel

react-server-dom-turbopack

These packages handle the decoding and processing of Flight protocol payloads sent to Server Function endpoints. The vulnerable versions (React 19.0.0, 19.1.0, 19.1.1, and 19.2.0) contain deserialization logic that fails to validate the structure and content of incoming payloads.

Here’s what happens during a normal Server Function call:

• Server serializes the result and sends it back
• Client serializes function arguments into Flight protocol format
• Client sends POST request to Server Function endpoint
• Server receives and deserializes the payload
• Server executes the function with the provided arguments

The vulnerability exploits step 3. When the server deserializes the payload, it processes specially crafted data that triggers code execution instead of just extracting function arguments.

The critical point is that the vulnerability occurs during payload deserialization, before your Server Function code even executes. Even if your function has perfect input validation, the deserialization flaw is triggered first.

Why default configurations are vulnerable

One of the most troubling aspects of CVE-2025-55182 is that it affects default configurations. If you created a Next.js application with create-next-app and deployed it to production without modifications, your application is vulnerable.

You don’t need to have written custom Server Functions. You don’t need to have made configuration mistakes. The vulnerability exists in the core framework code that handles RSC payloads, and this code runs whenever your application processes requests, even if you haven’t explicitly created Server Functions.

This makes CVE-2025-55182 a critical security issue. The vulnerability isn’t in your code but in the dependencies your application relies on. This is particularly significant because React and Next.js are among the most widely deployed web frameworks.

Affected versions:

The vulnerability affects a broad swath of the modern JavaScript ecosystem:

Other affected frameworks

Any framework that bundles React’s server-dom packages is potentially vulnerable:

• Vite with RSC plugin
• Parcel with RSC plugin
• React Router (RSC preview versions)
• RedwoodJS
• Waku

Timeline: From discovery to disclosure

The response to CVE-2025-55182 demonstrates effective coordinated vulnerability disclosure:

November 29, 2025: Lachlan Davidson reported the vulnerability to Meta’s security team. Davidson deserves credit for responsible disclosure rather than publishing exploit code publicly.

November 30, 2025: Meta’s security team confirmed the vulnerability and validated its severity. The speed of confirmation suggests the issue was clear and reproducible.

December 1, 2025: The React team developed a fix and began coordinating with framework maintainers across the ecosystem. This coordination included Vercel (Next.js), Vite, Parcel, and other RSC-dependent projects.

December 3, 2025: Public disclosure occurred with simultaneous patch releases across the ecosystem. CVE-2025-55182 was assigned with a CVSS score of 10.0. The React team published a detailed security advisory, and framework maintainers released patched versions.

Conclusion

CVE-2025-55182 demonstrates that even the most popular and well-maintained frameworks can introduce critical vulnerabilities. The combination of maximum severity (CVSS 10.0), trivial exploitation, and vulnerable default configurations creates significant risk.

The React team and ecosystem maintainers responded quickly, releasing patches within four days of the initial report. This coordinated response limited the window of exposure, but organizations must act immediately to upgrade their applications.

References

• Next.js
• React