Web development is always evolving, and sometimes those changes happen a bit under the hood. One such change involved the shift to React Server Components (RSC). If you’re a NextJS or React developer, especially using the App Router, understanding the new security alert is really important for keeping your apps safe and secure.

Table of Contents

What is "React2Shell"?

Think of your server receiving data like a mailroom receiving packages.

Usually, a mailroom checks if a package is safe before opening it. But in vulnerable versions of React and NextJS, the "Flight" protocol (used to communicate between the server and client) acts like a mailroom that blindly opens every package and follows any instructions inside immediately.

This vulnerability (CVE-2025-55182) allows an attacker to send a specifically crafted "package" (HTTP request) that forces your server to execute malicious code – like stealing passwords or installing viruses –without even logging in.

Why is this Happening Now?

It's all about how modern frameworks handle data serialization. There are a few reasons why this was just discovered.

First, React has complex serialization. To make Server Components seamless, React sends complex data structures back and forth.

Second, it has the "Flight" protocol. The vulnerability was found in how this specific protocol de-serializes (unpacks) data. It was too trusting of the input it received from the client side.

Should You Worry About this Change?

You need to pay attention if your app qualifies for any of the below:

  • You are using NextJS App Router: This is the default in newer NextJS versions (v13+).

  • You are using React 19: Specifically versions with Server Components enabled.

  • You use Server Actions: If your app takes user input and processes it on the server using React's server actions.

Is this Mandatory?

Yes. This is a critical security update. If your app qualifies in any of the above scenarios, you need to act immediately. Because, this vulnerability is being exploited right now.

How Bad Can It Get? The Extent of Exploitation

You might be thinking, "My site is just a simple content wrapper, surely I'm not a target?" Unfortunately, with Remote Code Execution (RCE), the attacker doesn't just "break" your site – they own the server it runs on.

Here is exactly what a hacker can do once they exploit this vulnerability:

Total Environment Theft

The most immediate risk is your .env file. Attackers can execute code to read your environment variables, instantly gaining access to your AWS Secret Keys, Database passwords, Stripe API keys, and OpenAI tokens.

The "Shell" Access

As the name "React2Shell" implies, attackers can open a reverse shell. This gives them a command-line interface on your server, allowing them to browse your file system as if they were sitting in front of your computer.

Lateral Movement

Once inside your NodeJS server, they are behind your firewall. They can now attack your internal services (like Redis, internal databases, or private micro-services) that are usually blocked from the outside world.

Supply Chain Poisoning

If your build server is vulnerable, an attacker could potentially inject malicious code into your deployment pipeline, affecting every user who visits your site in the future.

Botnet Recruitment

Hackers often automate these attacks to install crypto-miners, using your server's CPU (which you pay for!) to mine digital currency for them, often crashing your application in the process.

What Would be the Code Change for This?

You don’t need to rewrite your application code, but you must update your dependencies in your release line.

The vulnerability is fully resolved in the following patched NextJS releases:

  • 15.0.5

  • 15.1.9

  • 15.2.6

  • 15.3.6

  • 15.4.8

  • 15.5.7

  • 16.0.7

Patched canary releases for NextJS 15 and 16:

  • 15.6.0-canary.58 (for 15.x canary releases)

  • 16.1.0-canary.12 (for 16.x canary releases)

These versions include the hardened React Server Components implementation.

Here are the patched versions for React JS:

  • 19.0.1

  • 19.1.2

  • 19.2.1

Frameworks and bundlers using the aforementioned packages should install the latest versions provided by their respective maintainers.

Alternatively, you can run npx fix-react2shell-next in your NextJS project to launch an interactive tool which can check versions and perform deterministic version bumps per the recommended versions above. See the GitHub repository for full details.

There is no workaround other than upgrading to a patched version.

It’s highly recommended to rotate all your application secrets, once you have patched your version and re-deployed your application.

Advanced: Verify with the Original Exploit (PoC)

If you want to be 100% sure your patch is working, or if you want to understand how the attack actually works, you can use the original Proof of Concept (PoC) created by the security researcher (Lachlan Davidson) who found the bug.

Repository: React2Shell-CVE-2025-55182-original-poc

Lachlan provided three variations of the exploit script. The most important one for testing is 01-submitted-poc.js, which is the exact, simplified version submitted to Meta for the bug bounty.

How the Exploit Works

According to the repository, the attack works by tricking the parser:

  1. The attacker sends a payload using $@x to access a specific data Chunk.

  2. They "plant" a .then function on a fake object.

  3. The JavaScript runtime thinks it is handling a Promise and tries to "unravel" it.

  4. This allows the attacker to re-enter the parser with a malicious fake chunk, giving them access to internal server gadgets (like _response) to execute code (RCE).

Steps to Recreate the Issue

⚠️ WARNING: Only run this against a local development server (localhost) that you own. Never run this against production servers or public websites.

Note: I forked Lachlan’s repo and made minor changes to make it easy for you to run the script.

Step 1: Clone the Repository

Run the following commands to clone the repository, navigate into the project, and install dependencies:

git clone https://github.com/arunachalam-b/React2Shell-CVE-2025-55182-original-poc.git
cd React2Shell-CVE-2025-55182-original-poc
npm i

Step 2: Run a Vulnerable Local Server

Start your NextJS application locally (ensure it’s running a vulnerable version, for example NextJS 15.0.0, for the test to succeed).

npm run dev
# usually runs on http://localhost:3000

Step 3: Execute the Test

You will need to modify the script or use a tool like curl to send the payload structure found in 01-submitted-poc.js to your server's endpoint (usually a Server Action endpoint). Or simply run the following command if your app is accessible at http://localhost:3000:

node 01-submitted-poc.js

If the exploit succeeds (on the vulnerable version), the console will log the execution of the code (RCE). If the exploit fails (after you patch), the server will either reject the request or error out safely.

This response on running the script indicates your server is vulnerable

You can also confirm if your infected web server prints 50 in the console. Because we inject the code to do a calculation (look at _prefix field in the below JSON) that results in 50.

The payload used to demonstrate this hack

The 50 in your NextJS console indicates the hackers code has been executed on your server

After you apply the fix, you should see an error while running the script. In this case, as I’m using NextJS v15.1, the fix is upgrading the next package to version 15.1.9. Here are the screenshots after upgrading the package and running the script.

Response on running script after applying the fix

The console does not print 50 while running same script which indicates the hackers code is not executed on your server after applying the fix

Step 4: Verification

Once you have confirmed the exploit works on the old version, update your packages (as shown in the section above) and run the script again. It should no longer trigger the code execution.

Emergency Response: What If You Were Already Compromised?

If you suspect your server was exposed to the internet with a vulnerable version, assume the worst. A hacker may have already stolen your keys or left a "backdoor" to return later. Patching the code alone is NOT enough in this case.

Follow this "Nuke and Pave" protocol immediately:

Step 1: Isolate and Shutdown

Take the compromised server offline immediately. Do not try to "fix" it while it is running.

Step 2: Rotate ALL Secrets (Crucial Step)

Assume every secret in your .env file is in the hands of a hacker. You must generate new ones:

  • Change the password for your database users.

  • Rotate AWS Access Keys, Google Cloud Service Account keys, and so on.

  • Roll your Stripe/PayPal/Razorpay API keys.

  • Rotate your NEXTAUTH_SECRET or any JWT signing keys.

Step 3: Do Not "Clean" — Rebuild

Do not attempt to find and delete malware files on the server. Hackers are good at hiding.

  • Destroy the existing container, droplet, or EC2 instance entirely.

  • Build a fresh instance from your source code (after applying the patch).

Step 4: Audit Your Logs

Look at your database and cloud provider logs. Did anyone download your entire user database? Did anyone spin up expensive GPU instances on your AWS account? Check for unusual activity that occurred before you patched.

Conclusion

In this article, you learned about the "React2Shell" vulnerability, how to verify it using the original developer's tools, and how to upgrade your app to secure your Server Components. I hope you have a clear idea about why this update is urgent. By being proactive now, you can avoid a catastrophic data breach.

You can follow my Twitter/X account to receive the top AI news everyday. If you wish to learn more about cybersecurity, subscribe to my email newsletter and follow me on social media.