The vulnerability arises because in [email protected], the key function requireModule (pseudocode) for parsing Server Action on the server side:

2.2 Core Problem

The core issue is in the part moduleExports[metadata[2]]. There is no validation of metadata[2], allowing the attacker to not only access the module's own exported properties but also properties on the prototype chain (such as constructor, __proto__, etc.). When the attacker crafts metadata[0] (e.g., pointing it to vm), they can then craft metadata[2] to export dangerous methods from the specified module, such as vm.runInThisContext, thereby achieving exploitation.

III. Exploit Analysis

In my analysis, I referred to the test environment and exploit provided by ejpir, taking the vm_runInThisContext Code Execution gadget as an example. The process is as follows (note: under real-world conditions, the exploitation process may differ!):

Step 1: Receive Request

First, after sending a request with the payload, breakpoint at the location where the request is received:

Step 2: Parse Form Data

Then the program executes to const formData = parseMultipart(buffer, boundaryMatch[1]);. Step into parseMultipart:

parseMultipart extracts the request body data and returns it to formData:

Step 3: Call decodeAction (Vulnerability Entry)

Step into const actionFn = await decodeAction(formData, serverManifest); Vulnerability trigger point:

Step into loadServerReference:

Step 4: Core Vulnerability Code – requireModule

**Now we reach the core vulnerable code location requireModule. Step into it:

It returns the parts before and after # in the id value as module and method, and the bound parameter value as the method argument:

Step 5: Execute Payload

Step into actionFn to execute the final payload:

At this point, the exploit is complete!

IV. Summary & Defense

This vulnerability is fundamentally caused by insufficient input validation, much like Log4j and fastjson. In my test above, I used vm_runInThisContext. In reality, there are multiple gadgets that can be exploited, such as:

• vm#runInThisContext
• vm#runInNewContext
• child_process#execSync
• child_process#execFileSync
• child_process#spawnSync
• fs#readFileSync
• fs#writeFileSync
• #constructor
• #__proto__
• #prototype

Attackers can use this vulnerability to achieve:

• Remote Code Execution (RCE): Execute arbitrary system commands via vm#runInThisContext or child_process#execSync
• File System Operations: Read/write arbitrary files via fs#readFileSync, fs#writeFileSync
• Persistence Attacks: Write SSH public keys, modify .bashrc, overwrite application files, etc.
• Information Disclosure: Read sensitive configuration files (.env, private keys, database credentials, etc.)

Based on this, the following defense measures can be taken:

1. Temporary Defense

For temporary defense, the following angles can be considered. Configure rules on a WAF to intercept these dangerous fields, thereby blocking malicious attacks in a timely manner. Additionally, matching and interception can be performed on nginx, as shown below:

2. Update as Soon as Possible

The official security update has been released. Upgrade to a secure version immediately!:

Fixed Versions:

• react-server-dom-webpack: >= 19.2.0
• react-server-dom-turbopack: >= 19.2.0
• next.js: >= 15.0.5

During my analysis of the above vulnerability, I referenced the exploit by whiteov3rflow, further wrote a vulnerability detection tool for the test environment, and placed it in a GitHub repository.

Students who need to self-check can visit to obtain it (note: due to the original author's test environment, it may currently only be applicable to the original test environment; further improvements are pending. Those who need it can also modify it themselves...). Please use it with legal authorization and refrain from unauthorized destructive actions!

3. Be Cautious in Words and Actions!

As of now, 2025.12.5, what I have seen online is that the "wind" around this vulnerability fluctuates like a roller coaster. At times it is a "nuclear bomb," then a "water hole," then back to a "nuclear bomb"... Related exploitation methods are emerging endlessly. Based on current information, it is possible that the "nuclear bomb" label will stick, though its scope of influence is relatively smaller than Log4j. Regardless, all involved parties should update as soon as possible to eliminate future risks!!!

Also, a security admonition for developers: Never trust user input. Log4j, fastjson, and the current React RCE all fell victim to this. Therefore, in actual business development, dangerous positions must be strictly validated using sandboxes or whitelists to prevent tragedies!!!

What you get from books is shallow; to truly understand, caution must be exercised.

References

• CVE-2025-55182 Official Announcement
• React Security Advisory
• GitHub PoC by ejpir
• React Server Components Documentation