Vercel now checks your dependencies against a blocklist of npm package versions before and during every new build, and fails the deployment if one is on the list. Vercel’s changelog says the checks apply to all plans with no configuration.
npm is the public catalog most JavaScript projects pull reusable code from. Some packages run install scripts, small programs that execute automatically when the package is installed. A malicious package can use that moment to run its own code inside your build, which is the risk these checks target.
Flagged versions fail the build, vulnerable or malicious
The blocklist covers package versions flagged for malware or for security vulnerabilities, so a vulnerable version can stop a build, not only a malicious one. Vercel says new rules typically take effect within minutes.
The check runs at two points:
- Before installation: Vercel checks supported lockfiles, the files that record the exact version of every dependency. This includes dependencies restored from the build cache, the saved copy Vercel reuses to speed up repeat builds.
- During installation: Vercel blocks downloads of affected public npm packages.
Fixing a failed build
The error names the blocked package and version. Vercel also attempts to invalidate the affected build cache, so the next build should not reuse the flagged copy.
To recover, move to a safe version of that dependency, update the lockfile, and redeploy. If a coding agent manages your dependencies, give it the package and version from the error message and ask it to update the lockfile. Because rules apply to new builds, a project you have not touched since its last successful deploy can fail on its next build if a version it uses has since been added to the blocklist.
End of article