How to Check Whether Your Next.js Version Is Vulnerable—and Fix It

A Next.js version is not simply “vulnerable” or “safe.” It is affected or fixed for a particular advisory, under that advisory’s conditions. A release that fixes one issue can still appear in the affected range of a later one. Start with the advisory for the issue you are investigating, not a general verdict attached to a version number.

Find the version this project uses

The range in package.json tells you what versions the project permits. It does not, by itself, tell you which version was installed. From the project directory, use the command for its package manager:

npm ls next
pnpm why next
yarn why next

Check the resulting version against the project’s lockfile (package-lock.json, pnpm-lock.yaml, or yarn.lock). If they disagree or the install is incomplete, resolve that before making a security decision. Also identify the lockfile and dependency installation used to build production. Your laptop’s installed version is not proof of what an existing deployment is serving.

If you are still orienting yourself in an unfamiliar repository, explore the project before changing it so you know which package and deployment you are checking. In a monorepo, run the inspection for the application in question, rather than assuming a version found elsewhere in the repository applies to it.

Compare against the specific advisory

Read its affected range, patched releases, and any corrections. Compare the resolved version with those entries, including its minor and patch numbers. Then read the applicability conditions. Router, runtime, application features, operating system, and hosting setup matter when the advisory says they matter—they are not universal exemptions.

For example, the React Server Components advisory identifies affected App Router applications using React Server Components, while stating that Pages Router applications and the Edge Runtime are unaffected by that issue. A different August 2026 security release describes an issue involving applications using both routers without Cache Components when the server uses a Windows filesystem; it says Linux and macOS are not affected by that issue. And the middleware-bypass postmortem distinguishes impacted self-hosted deployments from hosting environments it found unaffected. None of those conditions can be borrowed to dismiss a different advisory.

Worked example: the May 2026 release

The May 2026 security release lists Next.js 15.x versions through 15.5.17 as affected and 15.5.18 as the upgrade for that line. Applied to that release alone:

Resolved Next.js version	Result for the May 2026 release
15.0.3	In its affected 15.x range
15.5.9	In its affected 15.x range
15.5.17	In its affected 15.x range
15.5.18	Listed fix for its 15.x range

This is not a current all-vulnerability verdict. In particular, “fixed for May” does not mean “safe indefinitely”: the August 2026 release lists 15.5.24 as its Maintenance LTS update. Check newer primary advisories before deciding what to deploy today. The May release also covers multiple advisories with feature-dependent impacts, so use the individual issue’s conditions to assess your application’s exposure.

Update the dependency and the lockfile

Choose a patched version in the appropriate release line—or another line the advisory explicitly recommends. Do not select a patch solely because its number is higher than the one in an older article. The following are alternative examples, not commands to run in sequence: each selects the 15.5.24 release named in the August 2026 notice and updates the dependency using the project’s package manager.

npm install [email protected]

pnpm add [email protected]

yarn add [email protected]

Use the version recommended by the current advisory you are addressing instead. Commit the resulting manifest and lockfile changes together. Reinstall as your deployment pipeline will, inspect the resolved version again, then build and run the project’s relevant tests and checks. Review dependency changes and application behavior before deploying.

Revisit the advisory even if you already patched once. The December 2025 security update says an initial fix for CVE-2025-55184 was incomplete and directs developers who took the first recommended upgrade to upgrade again.

Verify the deployed fix, not just the commit

After deployment, confirm which lockfile and resolved Next.js version the production build used, and that the new release is serving traffic. Recheck the advisory’s conditions against that deployment: the routing mode or hosting environment you assessed locally may not describe every deployed application.

Complete any follow-up the advisory calls for. The React Server Components advisory, for example, recommends rotating application secrets after patching and redeploying. Where an advisory requires an upgrade, do not treat a workaround as an equivalent fix: that advisory says there is no workaround, and the May 2026 release says its issues cannot reliably be blocked at the WAF layer. Once the deployment is verified, check for newer advisories before closing the issue.