Next.js and React App Router Vulnerability: A CVE-2025-55182 Guide

We are facing one of the most critical vulnerabilities to shake the modern JavaScript ecosystem.

On December 3, 2025, the React team announced a critical security vulnerability that directly concerns Next.js projects using the App Router and React Server Components (RSC): CVE-2025-55182. In certain React 19 and RSC package combinations, this vulnerability poses a risk at the level of unauthenticated Remote Code Execution (RCE).

The Next.js App Router is an architecture that has been adopted very quickly in recent years and offers serious advantages in both performance and DX, especially when used together with React Server Components. But this incident is a painful reminder that every new architecture brings new attack surfaces with it.

In this post, we'll go over, in a concise and practical way:

What the vulnerability fundamentally is,
Which React + Next.js combinations it affects,
How I diagnosed it in my own project,
And how you can secure your project step by step.

What Is the React2Shell Vulnerability? (CVE-2025-55182)

In the community, this vulnerability is mostly referred to as "React2Shell". The reason is quite clear: a deserialization bug on the React Server Components side can allow an attacker to execute arbitrary code on the server with a specially crafted HTTP request.

In other words, by sending a properly formatted payload to a specific RSC endpoint, the attacker can run commands on the server almost as if "opening a shell".

The main components that trigger the vulnerability are:

The React 19 ecosystem
The following RSC packages:

react-server-dom-webpack

react-server-dom-parcel

react-server-dom-turbopack

Next.js projects that use the App Router and have RSC enabled

The source of the problem is the unsafe RSC deserialization logic in versions of these packages around 19.0.0, 19.1.0, 19.1.1, 19.2.0. Because this logic isn't properly isolated, a specific payload can ultimately achieve RCE.

After becoming aware of it, the React team released patched versions of the RSC packages such as 19.0.1, 19.1.2, 19.2.1.

Which Projects Are at Risk?

Let's avoid unnecessary complexity when looking at the picture and go straight through practical scenarios.

Projects using React 18.x

In general, they are not directly affected by this CVE.
The problematic RSC versions come with the React 19 series.
So with React 18 + classic SSR/CSR or limited RSC usage, this specific vulnerability typically can't be triggered.

Projects using React 19.0.0 – 19.2.0

This is exactly the range where the RSC packages are vulnerable.
If your project has App Router + RSC enabled and your React version is in this range, you're at high risk.

Projects using Next.js 15 / 16 without the patch

Modern Next.js App Router projects run with RSC by default.
The Next team published an official security advisory for this vulnerability and marked specific versions as "patched".
15.x and 16.x versions before these releases are considered at risk.

Patched Next.js versions

The following Next.js versions are compatible with the React-side patches and are marked as safe in the advisory:

15.0.5
15.1.9
15.2.6
15.3.6
15.4.8
15.5.7
16.0.7

Summary risk combination

You can think of the risky picture like this:

A Next.js project using the App Router
Problematic versions of React 19 (19.0.0–19.2.0)
A Next.js version outside the patched Next 15/16 versions above
And a production environment where RSC endpoints are publicly exposed

If these conditions hold, the possibility of an attacker achieving unauthenticated RCE is a real risk that must be taken seriously.

How Did I Diagnose It in My Own Project?

The very site you're reading this post on is a portfolio and blog project running on the Next.js App Router. As soon as the vulnerability was announced, the first thing I did was make clear whether I was actually affected.

I ran this command in the terminal:

bash

npm ls next react react-dom

In summary, the output was:

next: 15.5.7
react: 18.3.1
react-dom: 18.3.1

From this, I reached the following conclusions:

On the Next.js side I'm using 15.5.7. This is one of the versions listed as "patched" in Next's official advisory.
On the React side I'm using 18.3.1; that is, I haven't moved to the React 19 series.
In addition, I checked that packages like react-server-dom-webpack in the dependency tree did not come with the risky React 19 versions.

With this combination, I could say that my project was safe with respect to CVE-2025-55182 specifically. Of course, this doesn't mean the project is "completely bulletproof"; it only shows that this specific RCE vulnerability doesn't affect me.

A Practical Checklist for Checking Your Project

If you want to run a similar analysis for your own project, the following steps are usually enough.

1. Check your React version

In the terminal:

bash

npm ls react react-dom

If you see one of the following:

19.0.0
19.1.0
19.1.1
19.2.0

you're in the range where the RSC packages are vulnerable. In that case, you need to update both React and the related RSC packages.

2. Check your Next.js version

bash

npm ls next

If your project uses Next 15 or 16 and your version is not in this list:

15.0.5
15.1.9
15.2.6
15.3.6
15.4.8
15.5.7
16.0.7

there's a high chance you haven't received the patch. The official advisory specifically marks these versions as safe.

3. Scan your RSC packages

You can also check your RSC packages with the following commands:

bash

npm ls react-server
npm ls react-server-dom-webpack
npm ls react-server-dom-turbopack

If you have problematic versions of these packages, you must upgrade to the patched versions.

The Fix: How Do You Secure Your Project?

1) Upgrade Next.js to a patched version

If you're on the 15.x line, for example:

bash

npm install next@15.5.7

If you're on the 16.x line:

bash

npm install next@16.0.7

Then the usual verification steps:

bash

npm run lint
npm run build

Make sure the build passes cleanly before deploying.

2) If you use React 19, update it

On the React side, you also need to use patched 19.x versions. The safe RSC versions mentioned in the advisory are around 19.0.1, 19.1.2, 19.2.1.

So you can move to the latest patched 19.x with a command like this:

bash

npm install react@19.2.1 react-dom@19.2.1

3) Pin your version ranges

Another critical point is the version ranges in package.json.

For example, using:

json

"next": "15.5.7"

instead of:

json

"next": "^15.5.7"

prevents you from moving to an unexpected minor version during a future npm update or clean install. You can apply the same approach to React.

Afterwards, to regenerate the lock file, you can follow a flow like this depending on the package manager you use:

bash

rm -rf node_modules package-lock.json pnpm-lock.yaml yarn.lock
npm install

What Does This Incident Teach Us?

For me, this vulnerability put three important lessons back on the table:

1. Framework updates are critical not just for features but for security too. Especially in fast-moving ecosystems like React and Next, postponing patch releases can have serious consequences.

2. Version ranges bring both convenience and risk. Versions starting with ^ and ~ can sometimes cause you to move to a vulnerable minor version without even noticing.

3. New architectures like the App Router and RSC require extra care. New architectures are powerful; but because they are also fresher, they need more security scrutiny.

A Strong Warning for Next.js Developers

CVE-2025-55182 shows very clearly how complex modern web applications have become and how this complexity can create new risks on the security side. When configured correctly, the App Router and React Server Components provide a strong architectural advantage; but that power also brings a serious security responsibility.

If you use the App Router with Next.js:

Check your React and Next versions,
Move to the patched versions listed in the official advisory,
Review the version ranges in package.json,
And if possible, run your project through security scans at regular intervals.

I applied all of these steps in my own project, and for now I know I'm not affected by this specific vulnerability. But that doesn't mean I can drop security from my agenda; on the contrary, from now on I'll ask this question more often when looking at new features:

> "How much new attack surface does this feature open up for me?"

Asking the same question regularly for your own projects will probably be the cheapest security investment you can make.

Next.js and React App Router Vulnerability: A CVE-2025-55182 Guide