A critical vulnerability has been identified in the React Server Components (RSC) “Flight” protocol, affecting the React 19 ecosystem and frameworks that implement it, most notably Next.js. Assigned CVE-2025-55182 (React) and CVE-2025-66478 (Next.js), this flaw allows for unauthenticated remote code execution (RCE) on the server due to insecure deserialization. The vulnerability exists in the default configuration of affected applications, meaning standard deployments are at risk

The vulnerability fundamentally resides in the react-server package and its handling of the RSC “Flight” protocol. It is characterized as a logical deserialization vulnerability where the server processes RSC payloads in an unsafe manner. When a server receives a specially crafted, malformed payload, it fails to validate the structure correctly. This allows attacker-controlled data to influence server-side execution logic, resulting in the execution of privileged JavaScript code.

In the developers review, exploitation of this vulnerability had high fidelity, with a near 100% success rate and can be leveraged to a full remote code execution. The attack vector is unauthenticated and remote, requiring only a specially crafted HTTP request to the target server. It affects the default configuration of popular frameworks.

Vulnerable products:

• React: 19.0, 19.1, 19.2
• Next.js: 14.3.0-canary, 15.x, and 16.x (App Router)

Patched release

• React: 19.0.1, 19.1.2, and 19.2.1
• Next.js: 14.3.0-canary.88, 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7

Please review the example application that has been configured here. You can run it with npm run dev. There are react server components configured at /test/ that you can evaluate.

An example request can be seen below: fetch(“http://localhost:3002/test”, { “headers”: { “accept”: “text/x-component”, “accept-language”: “en-US,en;q=0.9”, “cache-control”: “no-cache”, “content-type”: “text/plain;charset=UTF-8”, “next-action”: “405df4032e3eac902896c6c4b441ecad99122c38d2”, “next-router-state-tree”: “%5B%22%22%2C%7B%22children%22%3A%5B%5B%22slug%22%2C%22test%22%2C%22d%22%5D%2C%7B%22children%22%3A%5B%22__PAGE__%22%2C%7B%7D%2Cnull%2Cnull%5D%7D%2Cnull%2Cnull%5D%7D%2Cnull%2Cnull%2Ctrue%5D”, “pragma”: “no-cache”, “sec-ch-ua”: “"Chromium";v="142", "Google Chrome";v="142", "Not_A Brand";v="99"”, “sec-ch-ua-mobile”: “?0”, “sec-ch-ua-platform”: “"macOS"”, “sec-fetch-dest”: “empty”, “sec-fetch-mode”: “cors”, “sec-fetch-site”: “same-origin”, “cookie”: “crisp-client%2Fsession%2F5f523c31-098f-4014-8007-8d5610c86795=session_aa391e95-155d-42eb-bc70-a7fa35526490; ph_phc_E5n5uHnDo2eREJL1uqX1cIlbkoRby4yFWt3V94HqRRg_posthog=%7B%22distinct_id%22%3A%22e2adf4c4-5608-469a-bbcf-745befb37ae7%22%2C%22%24sesid%22%3A%5B1754818771957%2C%2201989359-761e-7b70-ac9b-4216586bb4be%22%2C1754818770462%5D%2C%22%24epp%22%3Atrue%2C%22%24initial_person_info%22%3A%7B%22r%22%3A%22%24direct%22%2C%22u%22%3A%22http%3A%2F%2Flocalhost%3A15500%2Fredteam%2Fsetup%22%7D%7D; next_hmr_refresh_hash=25bfc07f18065e3efe632e6066fb6e11633457081244afec”, “Referer”: “http://localhost:3002/test” }, “body”: “["examplepostdata"]”, “method”: “POST” });

This is what you should target based on what we know. Please build out an exploit.js that ONLY is looking for the RCE. You will need to evaluate the diff between the patched and unpatched versions. Once you have identified the problem please then work on this and solve build a working PoC. You will need to run the server and validate that the PoC works as expected. an example call might return the results of id