CVE-2025-55182 / Critical Pre-Auth Remote Code Execution via RSC Flight Protocol Deserialization

CVE-2025-66478
CVE-2025-66478 has been officially rejected in the NVD According to NVD, this CVE entry was determined to be a duplicate of CVE-2025-55182.
https://nvd.nist.gov/vuln/detail/CVE-2025-66478

What happened? 

A critical vulnerability was discovered in React Server Components (RSC) Flight protocol parser, affecting frameworks that bundle the RSC server-side implementation.

The problem is not only in separate “react-server-dom-*” packages, because many packages (like next.js) will bundle the entire vulnerable library into their own library, making it appear as part of that library. There are also many Libraries that embed RSC into them, which are also vulnerable, like Next.js.

We can install next.js versions and determine which version of react server components they embed:

This flaw allows a remote, unauthenticated attacker to achieve RCE by sending a crafted HTTP request to any application using RCS.

Why is it so dangerous?

Any Next.js application using the App Router (app/ directory), which relies on RSC, is vulnerable. The vulnerability is extremely dangerous because:

• Requires no user interaction.
• Does not require authentication, login, session or CSRF token.
• Leverages application framework bug, unrelated to the customer’s application running on top of it.
• Vulnerable on default configuration.

The issue happens because of unsafe handling of user-controlled RSC payloads, where React's internal $-prefixed reference system can be exploited to traverse JavaScript prototype chains and ultimately reach the Function constructor, which enables arbitrary code execution during the parsing phase. These are existing reference handlers, $F being the most important one.

Technical analysis

The $F option can be used to call any function registered in .next/server/server-reference-manifest.json; we can’t call arbitrary functions, only those explicitly exported in the manifest. 

‍

For example we can invoke processData function by using id=40a2ce27cc37b72735d19374f2e598efcc11ec3a52.

The vulnerability happens before reaching application code. The vulnerability happens during parsing of the RST payloads, before the execution ever reaches action logic implemented by the users of the vulnerable library. The CVE vulnerability is not about calling arbitrary functions - it is about manipulating the deserialization state to achieve code execution during the parsing phase, regardless of the function lookup of the intended functionality.

There are two parseModelString functions in React:

• ReactFlightReplyServer.js: Server decodes client→server (Server Actions): We’re interested in this one.
• ReactFlightClient.js: Client decodes server→client (RSC payload): we’re not interested in this one.

The parseModelString is the core deserialization function, which does the following:

  1. Receives raw string values from the RSC Flight payload

  2. Checks if they start with $

  3. Switches on the second character to determine the reference type

  4. Resolves each reference type to actual JavaScript values/objects

The vulnerability is in how certain references are resolved within this function - the unsafe deserialization that can lead to code execution.

When react server components are bundled into the application, the flight protocol can be used to exchange messages between client and server. When a request comes into the next.js application, the payload is handed to the RSC handler, which deserializes it. This deserialization process is vulnerable and expands object properties without enforcing proper validation. Therefore a malicious payload can pollute objects by using __proto__ or constructor, which essentially modifies server-side JavaScript structures.

After polluting the structures, the code executed during request handling accesses the polluted objects in order to achieve RCE on the server.

Vulnerable functions

When identifying vulnerable functions, we must pay special attention which functions to tag, because some functions are inlined into other functions even though they appear in the source code itself.

If we look at the patch, we can see the changes were done inside parseModelString:

However, let’s install the vulnerable next.js library:

Then we’ll be able to find embedded vulnerable code in “node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js” file, but it has been minified and is not particularly readable. We can unminify it with:

npx js-beautify -f node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js -o node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js

Now if we look into the file, we’ll see that we don’t have the parseModelString function, which has been inlined into reviveModel. Also the loadServerReference has been inlined into the same function. 

The actual issue occurs in getOutlinedModel, where we assign parentObject, which is then returned by the function. 

We can use payload like this, which will not cause any malicious exploitation, it’s just for showcasing the issue.

Once the application accepts it, the getOutlinedModel will be called and parentObject will initially be set to Array like presented below.

During iteration of the for loop inside getOutlineModel, the parentObject is set to different values:

• First iteration

• Second iteration

‍

• Third iteration

If we look at the getOutlinedModel function used at runtime and try to locate the same function in source code, we’ll see that they look very different, because the runtime version was minified. However we can still see the important excerpts that look similar, which is presented below.

We’ve seen that the problem starts in parseModelString, which is the entry point that parses $F references without any validations.

‍

How can Raven ADR detect, and prevent it?

The recent RSC Flight protocol exploit highlights a growing problem: many modern vulnerabilities hide inside otherwise legitimate application protocols. In this case, the exploit is embedded directly inside the React Server Components (RSC) Flight protocol, which makes traditional Web Application Firewalls (WAFs) struggle to detect or block malicious requests.

WAF signature detection relies heavily on spotting suspicious payloads, but the RSC Flight exploit uses payloads that are structurally valid, fully compliant with the protocol, and often indistinguishable from normal traffic:

• The HTTP request bodies look perfectly legitimate.
• They use allowed RSC references like $F, $K, $@, etc.
• Even variants such as "$F1" or unicode-encoded versions like "\u0024F1" look normal if you’re not protocol-aware.

You can try to patch WAFs with new signatures, trying to detect “vm#”, “child_process#”, “util#”, “fs#”, but it becomes a cat-and-mouse game. History tells us this cycle continues for years for any sufficiently complex protocol.

• Attackers find new encodings or variations.
• WAFs block more aggressively.
• False positives grow.
• New bypasses appear again.

Raven ADR takes a different approach: instead of trying to fingerprint malicious payloads, we focus on the actual vulnerable functions inside the application runtime, regardless of where or how the payload originates.

This means we detect vulnerable functions being executed even during normal, legitimate workflows. We don’t need to see an active attack; the moment the vulnerable function runs, we know the application is at risk. We bypass the entire WAF signature problem because we’re not chasing payloads - we’re observing real behavior.

This is also fundamentally more reliable than static analysis, which has major limitations, like missing inlined functions. Many frameworks bundle and embed entire libraries during build steps (like next.js we saw above). Additionally optimizers and bundlers rewrite code in ways that are difficult for static tooling to analyze correctly, which makes it hard to understand the code that actually runs.

1. Raven ADR operates from the runtime perspective. This allows Raven ADR to see what functions are executed at real points in time, including optimized, minified, or bundled functions. For example, when the vulnerable getOutlinedModel function runs, Raven ADR captures stack traces showing exactly where in the call graph this function appears. The picture below shows a stacktrace at a time getOutlinedModel is called:

Raven ADR runtime approach works whether:

• An attacker is actively exploiting the vulnerability, or
• The application itself reaches the vulnerable function during normal operation.

Either way, Raven knows the vulnerable path is reachable in the running application, which is the only fact that truly matters for assessing real-world risk.

Once Raven ADR identifies that a vulnerable function has been executed at least once, it marks the function inside the Raven UI and correlates it with known vulnerabilities. This enables teams to:

• Immediately see which components are affected.
• Confirm whether the vulnerable code path is actually used.
• Prioritize fixes based on real runtime evidence.
• Avoid wasting time patching dead or unreachable code.

Taking it to the next level, Raven ADR is the only runtime protection that allows creating policies to both detect and block CVE exploitation such as React2Shell CVE-2025-55182.