Vercel now blocks malicious npm package versions before and during builds

Vercel now blocks known-malicious npm package versions before and during dependency installation in its build pipeline, so that malicious install scripts never get the chance to run.

According to the Vercel blog, the system draws on a blocklist that names specific package versions, chosen because they contain malware or carry security vulnerabilities. Once a rule is added, it generally reaches new builds within minutes. The protections apply automatically to new builds on every plan, with no configuration needed.

How the blocking works

The checks operate at two points in the build process.

Before installation begins, Vercel checks any supported lockfile for pinned dependency versions that appear on the blocklist. This inspection also covers the path where dependencies come back from the build cache instead of being resolved fresh from the registry — a path that would otherwise skip the network entirely.

During installation, Vercel blocks downloads of affected packages from the public npm registry, so a listed version cannot be fetched even if it slipped past the lockfile stage.

These are additions to, not replacements for, Vercel's earlier safeguards. The company says it will keep examining installed dependencies and function outputs ahead of deployment, as it did before.

What happens when a dependency is blocked

When a blocked version is detected, the deployment fails outright. The build error names the offending package and version, and Vercel attempts to invalidate the affected build cache so the same dependency is not quietly restored on the next build.

Vercel's advised fix is simple: move the dependency to a safe version, bring the lockfile in line, and redeploy.

Why it matters

Install scripts are what make timing matter here. npm packages can ship lifecycle scripts that execute automatically when the package is installed, which is why a compromised or deliberately malicious version of a package is such an effective attack vector. A scan that runs after installation — however quickly — can only tell you that something bad has already executed on the build machine. By evaluating the lockfile before installation starts and intercepting the registry download during installation, Vercel's checks aim to keep malicious code out of the build environment entirely.

The cache check closes a subtle gap. Restoring dependencies from cache is faster precisely because it bypasses the network, so a filter that only watched registry traffic would miss a bad version that was cached earlier. Treating cache restoration as an inspection point means previously cached malicious versions are caught too.

For teams, the practical effect is that some supply-chain defence shifts onto the platform: nothing to opt into, no policy to write. The trade-off, inherent to any blocklist, is that only known-bad versions are covered. Freshly published malware that has not yet been identified and added to the rules can still slip through, so post-install scans and general care around dependencies remain necessary.

There is also an operational wrinkle worth noting. A build that suddenly fails with an error naming a specific package and version may now be a signal of a known-malicious dependency rather than an ordinary breakage — and the correct response is a version bump plus a lockfile update, not a retry.