Critical vulnerability in React Server Components (RSC) protocol

CVE-2025–55182 Repository Overview

I wanted to created this blog because I didn’t find any blog that actually explains to beginners who actually know react but couldn’t understand the issue. This is purely for educational purpose.

This issue arises because of a security flaw in how React Server Functions process data chunks between the client and the server in Next.js. Here’s the step-by-step overview and how data chunks are involved:

1. Background of Data Processing in React Server Functions

React Server Functions act like a communication bridge between the client and server, making it possible for the client to send data requests to the server. The responses to these requests use something called the React Flight Protocol, where data chunks are transferred to the server for deserialization.

• Data chunks: These are small pieces of data passed between the client and server. Chunks can reference each other, and this reference tells the server how to process complex data efficiently.

Why is the React Flight Protocol Important?

Server Components allow React applications to offload some operations to the server. The Flight Protocol makes this possible by defining how data is encoded, transferred, and decoded between the client and server.

Key features:

1. Chunk-Based Serialization: Data is passed in chunks, which can reference each other and include nested data structures.
2. Compact Format: It’s optimized for low latency, reducing the amount of data transferred over the network.
3. Client-Server Interoperation: The client sends data requests, and the server responds with serialized chunks that represent React components or data.

Strengths of the React Flight Protocol

• Efficiency: Compact serialization allows for fast server-to-client communication.
• Streaming: Since data is transmitted in chunks, the browser can start rendering as soon as the initial chunks arrive.
• Support for References: Thanks to chunk references (such as $1, $2), React Flight can pass complex tree-like structures without duplicating data.

Weaknesses Exploited in CVE-2025–55182

In the context of CVE-2025–55182, the Flight Protocol has a vulnerability:

• It does not sufficiently validate chunk references during deserialization.
• This allows attackers to craft malicious chunks to access sensitive JavaScript objects, including the prototype of objects, and execute arbitrary code.

For example, if chunk 0 is:

{"then":"$1:__proto__:constructor:constructor"}

This causes the server to invoke the constructor function, leading to arbitrary code execution.

2. How Deserialization Happens

Here’s an example payload sent to the server:

files = {
    "0": (None, '["$1"]'),
    "1": (None, '{"object":"fruit","name":"$2:fruitName"}'),
    "2": (None, '{"fruitName":"cherry"}'),
}

• File 0 references $1 (chunk 1).
• File 1 references $2:fruitName (fruit name from chunk 2).
• File 2 provides the actual value: {"fruitName":"cherry"}.

When the server processes these chunks, they combine into something like this:

{ object: "fruit", name: "cherry" }

3. What is the Exploit?

The core of the vulnerability is that React did not verify if a key (like fruitName) actually exists before trying to access it. This oversight allows attackers to access sensitive JavaScript objects like the object prototype, which contains dangerous methods.

Attackers use a specially-formed data chunk payload to bypass security and intrusively access the server.

Here’s a malicious payload:

files = {
    "0": (None, '["$1:__proto__:constructor:constructor"]'),
    "1": (None, '{"x": 1}'),
}

This translates on the server to the following object:

[Function: Function]

What’s happening:

• The __proto__ path accesses the object prototype.
• constructor (on the prototype) retrieves the constructor function.
• Attaching constructor again creates a function constructor!

At this stage, the attacker has access to a tool (Function) that allows execution of arbitrary JavaScript code.

4. Triggering Arbitrary Code Execution

The attacker can then ensure the malicious chunk’s data gets returned in a way that the server calls it as a “thenable” (a Promise-like object). Here’s the payload for that:

files = {
    "0": (None, '{"then":"$1:__proto__:constructor:constructor"}'),
    "1": (None, '{"x":1}'),
}

This creates a “thenable” object (a Promise-like object) on the server:

function () { [native code] }

5. Combining This for Remote Code Execution (RCE)

Attackers use the thenable method to execute their own crafted JavaScript code using a “call gadget.” Specifically:

1. They craft their chunk in a way that re-evaluates itself (called a “fake chunk”).
2. They replace the then handler with malicious code.
3. The server eventually “awaits” the returned malicious code, executing it.

Here’s the final crafted payload:

files = {
    "0": (None, '{"then": "$1:__proto__:then", "status": "resolved_model"}'),
    "1": (None, '"$@0"'),
}

In this:

• The then is overwritten.
• A “resolved_model” triggers another evaluation cycle (deserialization).

The attacker overrides the server’s functions and uses a call gadget to push their own remote code execution payload.

6. Fix in the Code

The vulnerability was patched by adding a check that ensures data received cannot access the prototype. Specifically:

if (hasOwnProperty.call(moduleExports, metadata.NAME)) {
    return moduleExports[metadata.NAME];
}
return undefined;

This ensures only explicit object properties are accessed, blocking prototype pollution.

What Makes It Work?

1. Loose Verification: React’s flight protocol did not verify if keys existed before retrieving values. This allowed abuse of __proto__ and constructor.
2. Promises (then method): The use of "thenables" made it easy to chain malicious code into what seemed like valid server processes.
3. Dynamic Evaluations: The server’s code dynamically resolves and processes objects. This was exploited to run arbitrary code.