Example Commands

Important Notes

• ⚠️ Timeout errors are EXPECTED - they indicate the RCE executed successfully
• The server hangs after executing the command, which causes the HTTP timeout
• Commands execute as the nextjs user (UID 1001) inside the container
• Files are created inside the container's filesystem, not on the host

Docker Setup

This repository includes a complete Docker setup for testing the vulnerability:

• docker-compose.yml - Docker Compose configuration
• test-server/ - Vulnerable Next.js application
• test-server/Dockerfile - Production Dockerfile
• test-server/Dockerfile.dev - Development Dockerfile (optional)

The vulnerable server runs Next.js 16.0.6 with a simple Server Action that can be exploited.

Files

• poc.py - Python proof of concept script (original by msanft, with quote escaping fixes)
• exploit-docker.sh - Automated exploit script for Docker environment
• DOCKER_SETUP.md - Comprehensive Docker setup documentation

Clean Up

Original Vulnerability Analysis

The detailed vulnerability analysis, exploitation chain, and patch information from the original research is provided below.

Original Research by msanft

This vulnerability allows RCE in React Server Functions, e.g. as offered by Next.js through insecure prototype references.

I'm not an expert in React or Next.js, so take all the information here with a grain of salt. Furthermore, I'm still in the analysis process, so what I depict below as "the vulnerability" might only be a small part of the full chain.

Background

React offers Server Functions¹, which can be seen as sort of an RPC- over-HTTP. They can be used to fetch data from adjacent peers to ensure low latency, or perform authenticated requests that the client lacks credentials for.

React uses something called the React Flight Protocol² for serialization of values passed to Server Functions.

The client passes "chunks" to the server, e.g. via form data:

As shown, these can have references in between each other. The above payload deserializes to the following on the server:

The format itself is a little more intricate and allows for more complex serialization and deserialization, but this provides a basic understanding for the actual vulnerability.

Vulnerability

Until this commit³, when traversing chunks in reference resolving, such as getting the fruitName from chunk 2 in the above example, React didn't verify whether the requested key was actually set on the object. This allowed us to get the object prototype⁴.

This can be demonstrated with a payload like this:

Which deserializes to the function constructor⁵:

When the chunk with ID 0 is not an array but an object, we can set the then key to the function constructor. The object is then returned by the decodeReplyFromBusboy function and awaited by Next.js:

When this returns a thenable, the await in the caller will call it. This is what happens with this payload:

Leading to this error:

The error looks like this since V8 calls an awaited function with the internal resolve and reject functions, which, when toStringed, serialize to something like this:

Exploitation

Since we can trivially retrieve the Function constructor, the straightforward way is to find a call gadget that invokes the constructor with a user-controlled value (i.e., the code of the function as a string), and later calls the returned function.

There are multiple places that can call the function constructor, for example resolveServerReference, where id is a controlled object, and lastIndexOf can be overwritten to return a user-controlled string (e.g. via Array.prototype.join) and slice can be overwritten to the function constructor. However, this place doesn't work as the second invocation of .slice() supplies a number as the first argument, which -to my best knowledge- can never be handled by the function constructor.

Here, a brilliant idea from maple3142⁶ comes in. When getChunk grabs the chunk at ID 0 as the root reference to start resolving the reference chain, this very same chunk can resolve to a crafted "fake chunk".

We can reference the crafted chunk 0 in chunk 1 by using the $@ syntax, which returns the "raw" chunk, not it's resolved value:

Combining this with our then overwrite from above, we can craft something like this:

Here, chunk 0 overwrites its own .then() with the .then() of its own raw chunk representation. Put simply, we overwrite our own .then() with Chunk.prototype.then, which exists, since Chunks are thenables:

With the above payload, Chunk.prototype.then is eventually called with the crafted chunk with ID 0.

As shown above, when .status on our fake chunk is resolved_model:

We get into initializeModelChunk. Here, .value is parsed as JSON, and then references are resolved on the returned object, using the "outer" context of our chunks with IDs 0 and 1:

Within this, we now get a second pass of evaluation with a little more values we have access to due to the outer context already being resolved.

There is a call gadget in the handling of blob data with the $B prefix in the flight protocol:

Using the special _response field, we control the response property of the crafted chunk:

With this, we can craft an object with fake ._formData and ._prefix properties:

The .reason needs to be added to circumvent failing on the toString invocation in `initializeModelChunk:

By pointing ._formData to the function constructor, and ._prefix to our code, we get an invocation gadget for the function constructor in the blob deserialization:

Our crafted function is then returned by parseModelString as the .then() method of the crafted chunk, which is also awaited, since all of this takes place in a single promise resolving chain. Thus, returning a thenable, our crafted function gets called. This constitutes the required call gadget referenced above.

Putting this all together with an actual RCE payload, we get something like this:

Patch

Using the chunk references to retrieve prototype properties is fixed with this check:

Standing questions

• Why does the React advisory⁷ mention that this vulnerability could be triggered even without actively declaring server functions? Are there other things that turn to server functions under the hood?