At what stage does Vercel block the deploy?

Before the build ever runs. Before npm install or next build starts, Vercel reads the next version in the uploaded package.json, judges it vulnerable, and stops the deploy right there. Nothing about it shows up as an error in the build log.

What version did you move from 15.1.6 to?

The next entry in package.json changed from the pinned 15.1.6 to the caret-prefixed ^15.5.23. That also regenerated package-lock.json, adding 255 lines and removing 223.

Why was 15.1.6 judged vulnerable?

The source commit doesn't record Vercel's specific criteria or a CVE number — all that's left in the commit message is the fact that 'Vercel blocks 15.1.6 as a vulnerable version.' The actual judgment logic lives on Vercel's side.

Next.js 15.1.6 Got Blocked by Vercel as a Vulnerable Version

This article may contain affiliate links. Its content is not affected by advertising.

Conclusion

With next pinned to 15.1.6 in package.json, pushing to Vercel got the deploy blocked before a single line of the build had run. The cause was Vercel judging 15.1.6 a vulnerable version, and nothing worked until next was bumped to ^15.5.23 and package-lock.json was regenerated.

Symptom

In a Next.js project we run in-house, package.json had next written as a caret-free, pinned value:

"dependencies": {
  "lucide-react": "^0.469.0",
  "next": "15.1.6",
  "react": "^19.0.0",
  "react-dom": "^19.0.0"
},

This repository was still only two commits old at this point — early enough that no habit of keeping dependencies updated had formed yet — and a deploy to Vercel was attempted with this exact configuration still in place. The result was that the deploy stopped without a single line of next build log ever appearing. It wasn’t a build error — the distinguishing feature was that it was rejected before the build stage was ever entered.

Cause

The reason is stated plainly in the commit message itself:

Bump Next.js to 15.5.23. Vercel blocks 15.1.6 as a vulnerable version.

Vercel reads the next version written in the uploaded project’s package.json, and if it matches a known vulnerable version, blocks the deploy before the build is ever run. What matters here is that the judgment isn’t based on what version package-lock.json actually resolves to — it’s the specification written in package.json itself that gets evaluated. In this repository, next was written as the caret-free pin 15.1.6, which locked in exactly the situation that a range like ^15.1.6 might have let the install itself escape by resolving to a different patch version.

The fix

A single line in package.json was rewritten:

-    "next": "15.1.6",
+    "next": "^15.5.23",

This also triggered npm to regenerate package-lock.json, adding 255 lines and removing 223. Bumping even one version can shift the resolution of the entire dependency tree, so the lockfile diff ends up touching a fairly wide surface.

package-lock.json | 478 +++++++++++++++++++++++++++++-------------------------
package.json      |   2 +-
2 files changed, 256 insertions(+), 224 deletions(-)

Fixing package.json alone isn’t the end of it — regenerating and committing the lockfile is part of the same fix.

Preventing a repeat

The source commits don’t record any step to check Vercel’s own criteria, nor any change to how dependency versions get managed going forward. The fix itself was just bumping the flagged version by one step and regenerating the lockfile.

What’s structurally visible here is that a caret-free, pinned version specification can’t move on its own when a new vulnerability is discovered. A range like ^15.5.23 leaves room for a newer version to resolve at install time within the patch range, but the fully pinned 15.1.6 closed off that room entirely. This repository was still young enough that no dependency-update routine had been built into its workflow, and this pin sat untouched until the deploy attempt finally surfaced it.