CVE responseBy Dynv teamPublished 2026-11-015 min read

Am I affected by the Next.js and React Server Components CVEs? How to check

Short answer: you are affected if your next package is in a vulnerable range below, and for most of these only if you use the App Router and a specific feature. Check next's own version, not react's: Next.js ships its own compiled copy of the React Server Components code, so npm ls react can look clean while the vulnerable code is inside next.

Two sets of critical advisories matter right now. This page lists them from the maintainers’ own advisories (read on 2026-11-01), says exactly what has to be true for you to be exposed, and shows how to check the app you actually deployed. Paste a lockfile into our lockfile checker if you want the answer for every package at once.

1. React2Shell (December 2025)

CVE-2025-55182, published 2025-12-03, is an unauthenticated remote code execution in React Server Components, scored CVSS 3.1 10.0 in GitHub’s advisory. It is in CISA’s Known Exploited Vulnerabilities catalog, added 2025-12-05 (KEV).

Per the React advisory, the vulnerable packages are react-server-dom-webpack, react-server-dom-parcel and react-server-dom-turbopack at versions 19.0.0, 19.1.0, 19.1.1 and 19.2.0 (fixed in 19.0.1, 19.1.2, 19.2.1). It also says: “If your app’s React code does not use a server, your app is not affected,” and the same for apps without a framework or bundler that supports React Server Components.

Next.js: the advisory says it affects “Next.js 15.x and 16.x using the App Router.” Fixed stable versions: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 and 16.0.7. It also affects canaries from 14.3.0-canary.77; 14.x stable is not listed.

2. The 14 October 2026 Next.js advisories

On 2026-10-14 Vercel published three advisories for next, fixed in 15.5.28 (15.x line) and 16.4.1 (16.x line). All three are from the Next.js security advisories; scores are CVSS 4.0 as published there.

So “no workaround” is true for the use cache RCE and the DoS, but the image-optimization RCE has a documented one. Read the ranges as the advisories print them: the image-optimization advisory lists its 16.x range as “> 16.0.0 <= 16.4.0”.

Why npm ls react misleads

Next.js bundles compiled copies of React and the Server Components packages inside its own distribution. We confirmed this on the published [email protected] tarball: it contains dist/compiled/react/ and dist/compiled/react-server-dom-webpack/. The code that the React2Shell advisory is about is therefore reachable through next even when your top-level react is a patched version, and the fix arrives as a new next release (see the fixed list above).

So check next:

npm ls next                       # what the lockfile resolved
node -p "require('next/package.json').version"   # what is installed in this directory

and compare against the fixed versions above. If you use the Server Components packages directly, check those too.

Check what is actually deployed, not just the repo

A merged upgrade is not a deployed upgrade. Stale containers, a second service on an old tag, or a monorepo package pinned to an old next are common. Three ways to check, from cheapest:

1. Lockfile, in your browser: the lockfile checker looks up every package in your package-lock.json on OSV.dev. Only names and versions leave your browser. For [email protected] OSV returns exactly these three advisories (we queried it on 2026-11-01).

2. Lockfile, in CI: the dynv scan command checks a directory against OSV without an account and exits 1 at or above a severity you choose (--fail-on high is the default; --json for tooling). Run on a project locked to [email protected] (output from the current dynv build, 2026-11-01):

   $ dynv scan
   SEVERITY  PACKAGE  VERSION  FIXED   ID                   PATH
   critical  next     16.4.0   16.4.1  GHSA-2464-fhr4-w9xw  direct
   critical  next     16.4.0   16.4.1  GHSA-673q-mjm6-r5xr  direct
   high      next     16.4.0   16.4.1  GHSA-p3m5-59mp-jv5r  direct
   
   3 vulnerabilities (2 critical, 1 high) in 1 packages; 3 fixable.

3. The running service: with --vulns (or DYNV_VULNS=1), dynv run reads the packages the service actually has installed in node_modules, matches them against OSV at boot, when files change and every six hours, and alerts when a new advisory affects what is running. The detail is sealed so Dynv’s servers see only counts. See vulnerability monitoring.

None of these tells you whether your code reaches the vulnerable path. The “you are exposed if” column above is how you answer that for these advisories.

If you are affected

1. Upgrade next to a fixed version (15.5.28 or 16.4.1 or later for the October advisories; the React2Shell versions above for December). Redeploy, then verify the deployed version with the second command above.
2. If the app was exposed and unpatched while RCE was possible, assume the process’s secrets were readable. Remote code execution runs as your server process, which can read its environment. Rotate what that service holds, starting with credentials that grant write access. We do not claim the October RCEs are being exploited: they are not in the KEV catalog as of its 2026-10-30 release, but CVE-2025-55182 is.
3. Rotate in one pass. If the same secret lives in several services, a previewed rotation shows every copy and changes them together, instead of finding them by hand.
4. Make the next one cheaper. Without a monitor, you find out when someone writes a blog post like this one.

What this does not cover

• Each advisory has its own conditions; read them in full before concluding you are safe. This table is a summary of what they say on 2026-11-01 and the maintainers may revise them.
• A scanner match means a version is in a vulnerable range, not that the code path is reachable in your app.
• Dynv’s monitor reports known advisories for the packages a service runs. It does not block an exploit. We are working on runtime protections, but this article does not rely on them.

Facts last verified 2026-11-01. Spotted an error? Tell us.