On December 11, 2025, the React team disclosed two additional vulnerabilities affecting the React Server Components (RSC) architecture:
- Denial of Service: CVE-2025-55184 and CVE-2025-67779 - Source Code Exposure: CVE-2025-55183
These issues were discovered while researchers were testing patches related to the previous week’s critical remote-code-execution vulnerability, commonly referred to as “React2Shell” (CVE-2025-55182).
This raises three important questions:
- Why did several vulnerabilities appear within such a short period? - Does this mean React Server Components are bad? - What should you do if you have a running React or Next.js application?
To answer them, we first need to understand where the vulnerable data flow occurs.
These issues involve how React Server Components infrastructure deserializes data sent from the client to the server. But wait: aren’t Server Components rendered only on the server? When does client-to-server parsing happen?
Server Components do render on the server and stream the UI as a React Server Component Payload, commonly called the React Flight format. This is a framework protocol, not ordinary HTML or JSON. However, Server Components are not the only part of the architecture. There is another flow involving Server Functions.
When a Client Component invokes a Server Function, for example through a form action, the framework serializes the function call and its arguments into a React Flight payload and sends that payload to the server.
This is where the security boundary matters. Deserialization becomes dangerous when untrusted input is accepted without sufficiently strict validation. If an attacker crafts a malicious payload and the server blindly deserializes it, the result can be serious security impact.
The following sequence shows where the vulnerabilities can occur:
1. Code running in the client initiates a request that invokes a Server Function.
2. The framework serializes the request into a React Flight payload. The format is structured and JSON-like, but it is not JSON. The payload includes metadata such as the Server Function identifier and serialized argument values.
3. On the server, a package from the react-server-dom-* family, such as react-server-dom-webpack, deserializes the payload and reconstructs JavaScript values.
4. Those reconstructed values are passed to the Server Function. The function must treat them as untrusted input and validate them before use; they are not automatically safe simply because they came through a framework serializer.
This is the point at which an unsafe deserialization edge case can become exploitable. The exact impact depends on the vulnerability, the affected package and version, the framework integration, and how the application handles the resulting values.
Why did several vulnerabilities appear in such a short time? This is a common pattern after a critical vulnerability is patched. Once React2Shell (CVE-2025-55182) was disclosed and mitigated, researchers and maintainers continued testing the surrounding code paths and edge cases. That additional testing uncovered further issues, including the Denial of Service and Source Code Exposure vulnerabilities described above.
Does this mean React Server Components are bad? Absolutely not. RSC is a powerful architecture and can provide important benefits, including a controlled server boundary. But any complex system that parses attacker-controlled input can contain implementation bugs. The correct lesson is not to reject the architecture; it is to keep dependencies updated, treat deserialized values as untrusted, and follow security advisories carefully.
What should you do if you have a running React or Next.js application? Update immediately. Check the official React and Next.js security advisories, identify the affected packages in your dependency tree, install the fixed versions, redeploy all affected environments, and review whether exposed applications require session rotation or additional incident response. Do not rely only on a direct dependency check: the vulnerable package may be brought in transitively by your framework.
The broader lesson is simple: Server Components may render on the server, but server-side features can still receive attacker-controlled requests. Rendering location does not remove the need for input validation, dependency updates, and careful security boundaries.