Next.js and React CVE checker

What the checker looks at

It reads four packages: next, react, react-dom, and the react-server-dom-* packages (webpack, turbopack, parcel) that run React Server Components. It compares each version with the affected ranges published on our CVE pages, one release line at a time, and gives you the first version that fixes each flaw on your line.

Why package.json is not enough. "next": "^15.1.0" means 15.1.0 or any later 15.x release. The lockfile records which one was installed. With a range, the checker evaluates the lowest version it allows and tells you so: that is the worst case, and your lockfile may already pin a release with the fix.

Why react-server-dom matters. React2Shell (CVE-2025-55182) is in react-server-dom-webpack, react-server-dom-parcel and react-server-dom-turbopack, not in react itself. React's advisory lists 19.0, 19.1.0, 19.1.1 and 19.2.0 as affected and 19.0.1, 19.1.2 and 19.2.1 as fixed. Next.js ships its own copy of these packages inside next, so for a Next.js app the Next.js version is what counts. With React Router, Waku or a Vite or Parcel Server Components plugin, the copy in your lockfile counts. An app that renders React only in the browser does not run this code.

How to read the result

• The verdict comes first, in one sentence, colored by the worst severity it found.
• Affected lists each CVE your version contains, worst first: what it lets a stranger do, the first version that fixes it on your release line, and the install command for npm, pnpm, yarn or bun. When that first fix still carries another CVE on the list, the command skips ahead to the first release none of them affect.
• One upgrade clears all of them appears when several CVEs apply. It is the lowest version that none of them affect, so you upgrade once.
• May apply holds the CVEs a version alone cannot settle, such as a react-server-dom package your framework may or may not install, or a canary build numbered before the affected range starts. The card says what to check.
• Not affected and Not checked stay folded: the CVEs your release already has the fix for, and the ones that need a version you did not give.

Several CVEs only matter in some setups. The middleware bypass (CVE-2025-29927) matters when middleware does your auth checks, and its advisory says deployments hosted on Vercel are protected automatically. React2Shell hits the App Router, not the Pages Router. Each card links to the part of its CVE page that says who is affected.

How to fix what it finds

1. 1

   Confirm what is installed

   Run npm ls next react react-dom in the project, or pnpm why next and yarn why next. That is the version your build uses, whatever package.json says.

2. 2

   Install the fixed version

   Copy the command from the result. It writes the new version to package.json and to the lockfile in one go.

3. 3

   Commit the lockfile and redeploy

   The fix exists only once the new build serves your traffic. A server still running the old build is still affected.

4. 4

   Rotate secrets after a code execution flaw

   For React2Shell, Next.js asks anyone whose app was online and unpatched on December 4, 2025 to rotate the secrets it uses, starting with the most critical ones.

# What your project really installs
npm ls next react react-dom

# Replace VERSION with the one the checker gives you
npm install next@VERSION

# React outside Next.js: keep these on one version
npm install react@VERSION react-dom@VERSION react-server-dom-webpack@VERSION

If you cannot upgrade today, some CVEs have a stopgap. For the middleware bypass, the advisory says to stop outside requests that carry the x-middleware-subrequest header before they reach Next.js. Behind nginx, one line in the block that proxies to your app does it:

location / {
    proxy_set_header x-middleware-subrequest "";
    proxy_pass http://127.0.0.1:3000;
}

React2Shell has no workaround: the Next.js advisory says upgrading is required. Hosting providers added filtering rules after disclosure, and React's own advisory warns you not to depend on them.

What a version check cannot tell you

A version check lists the known flaws your release contains. It is not proof that a stranger can use them on your app, for four reasons.

• It cannot see your setup. A middleware bypass changes nothing if every route checks the session itself, and everything if middleware is your only check.
• It cannot see your deploy. The lockfile in your repository and the build in production drift apart when a deploy fails or a server never gets rebuilt.
• It only knows the CVEs on our list. A new advisory reaches the checker when its CVE page is published, and canary releases are matched by version number only.
• A range is a worst case. With package.json alone, the answer is about the lowest version the range allows. Paste the lockfile for the truth.

Keybrum works from the other end: it tests each reachable CVE on your live app by its behaviour, never by version, and never runs code execution or denial of service payloads. For the leaks a version cannot show, such as keys in the JavaScript bundle or routes that skip the auth check, read the Next.js security guide.