npm v12 Blocks Install Scripts to Curb Supply Chain Attacks

GitHub is shipping npm v12 this month, and the headline change is simple: dependency install scripts stop running automatically. That one default flips off the most reliable foothold attackers have had on the npm registry for the past year. According to TechTimes, npm v12 arrives in July 2026 and blocks the lifecycle scripts (preinstall, install, postinstall) that a package can execute the moment you run npm install. Those scripts have run attacker code on developer laptops and CI runners in incident after incident. Turning them off by default is the biggest change to npm's threat model in years, and not everyone agrees it goes far enough.

What npm v12 actually changes

An npm package can declare lifecycle scripts in its package.json. The preinstall, install and postinstall entries run automatically during npm install, with the same permissions as the user or service account running the command. There is no prompt and no review. If the code is malicious, it runs before you ever import the package or read a line of it.

npm v12 changes that default. Based on the reporting from TechTimes, scripts from installed dependencies no longer run on their own. The change targets third party code, the code you did not write, while your own project scripts still run. To restore a build step that a package genuinely needs, you allow that package explicitly.

This is not a new idea. pnpm has blocked dependency build scripts by default since version 10 in early 2025, using an onlyBuiltDependencies allowlist, and Bun added a similar model around the same time. npm is the last of the major clients to adopt it. Infosecurity Magazine reported that GitHub frames the release as part of a wider npm hardening effort that also covers shorter token lifetimes, mandatory two factor authentication, and trusted publishing through OIDC.

Why install scripts were such a good attack vector

A postinstall script runs at install time, which is the one moment every user of a package reaches, even if they never call a single function from it. That makes it the cheapest place to put a payload. An attacker only has to get the package installed once: through a typosquat, a compromised maintainer account, a hijacked release, or dependency confusion.

Once the script fires, the work is routine. It reads environment variables, pulls npm tokens out of .npmrc, grabs SSH keys and cloud credentials, or scans the disk with a secret scanner like TruffleHog and posts whatever it finds to an attacker controlled repository. SafeDep documented a clear example earlier this year: a set of packages that impersonated Claude Code tooling and, in their words, executed on npm install and re-executed on every editor session through a hijacked hook. Install-time execution is what made that persistence possible.

The self propagating worm known as Shai-Hulud, which hit npm in late 2025, is the case that pushed this default over the line. It used a postinstall script to harvest tokens and then republished itself through any maintainer credentials it found, turning one compromise into many. A default that blocks dependency scripts breaks that first link in the chain.

Timeline

Late 2025: worm style attacks including Shai-Hulud spread through postinstall scripts and stolen publishing tokens. GitHub, which owns npm, said it would tighten registry security in response.

Late 2025 into 2026: a steady stream of install-script malware kept landing on npm. Typosquats such as nodemon-node and tailwind-core, fake payment SDKs like the Paysafe and Skrill impostors, and AI tooling lookalikes such as clavue all leaned on the same install-time trigger.

June 2026: Unit 42 published an updated analysis of the npm attack surface and the mitigations available to defenders.

2026-07-08: TechTimes reported that npm v12 ships this month with dependency install scripts blocked by default. Cybernews had already run a piece arguing the overhaul does not go far enough.

Who is affected

Most developers benefit and do not have to do anything. Fewer drive-by compromises happen at npm install time, which is where a large share of npm malware lands.

The friction falls on packages that compile native code at install time. Modules that build addons through node-gyp, such as bcrypt and better-sqlite3, rely on an install script to produce a binary for your platform. With scripts blocked by default, those installs either fall back to a prebuilt binary or fail until the package is allowlisted. Teams that maintain custom postinstall build steps inside internal dependencies will feel the same pinch.

CI is where this shows up first. A pipeline that has quietly depended on a dependency compiling itself can break the day it upgrades to npm v12. That is worth testing before the upgrade, not after.

How to check if your builds depend on install scripts

Run an audit of which dependencies define install scripts. The community tool can-i-ignore-scripts reports exactly that:

npx can-i-ignore-scripts

Then prove it by installing with scripts turned off and running your build and tests:

npm ci --ignore-scripts
npm run build && npm test

If everything still passes, you can adopt the v12 behavior today with no downside. If something breaks, the audit tells you which packages to allow.

What to do now

You do not have to wait for npm v12 to get most of the protection. Turn off dependency scripts at the project level by adding one line to .npmrc:

ignore-scripts=true

Or apply it per command when you want a one-off safe install:

npm install --ignore-scripts

Be deliberate about exceptions. ignore-scripts is a blunt switch, so allow only the packages that truly need to build, and prefer versions that ship prebuilt binaries. Beyond scripts, pin your dependencies and commit a lockfile, enable two factor authentication on your npm account, and replace long-lived classic tokens with short-lived granular tokens or trusted publishing. In CI, run installs with scripts disabled and a clean cache so a poisoned package cannot warm a cache for later jobs.

Will this actually stop supply chain attacks

No, and Cybernews made that argument before v12 even shipped. Install scripts are one vector, not the only one. Malware can still run the moment you import a compromised module and call it, so a payload hidden inside an exported function keeps working whether or not install scripts are blocked. Attackers have already moved some payloads to runtime and into CI configuration files.

What the change does is raise the cost of the easiest and most automated attacks, the ones that fire on install with zero interaction and self replicate through tokens. That is a real improvement, and it aligns npm with pnpm and Bun. It is not the end of npm supply chain attacks, and treating it as one would be a mistake. Keep auditing dependencies, keep secrets out of build environments, and keep watching what your packages do at runtime, not just at install.

FAQ

How do I stop npm install scripts from running today?

Add ignore-scripts=true to your project .npmrc, or run npm install --ignore-scripts for a single command. Both work on current npm versions, before v12 arrives. Test your build afterward, because packages that compile native code may need an exception.

Will npm v12 break packages with native modules?

It can. Modules that compile addons through node-gyp, such as bcrypt and better-sqlite3, use an install script to build a platform binary. Under the v12 default they rely on a prebuilt binary or an explicit allowlist entry. Run npx can-i-ignore-scripts to see which of your dependencies are affected before you upgrade.

Does --ignore-scripts protect me from all supply chain attacks?

No. It only blocks code that runs during installation. A malicious package can still execute its payload at runtime when your application imports and calls it. Blocking install scripts closes the most common automated path, not every path.

When does npm v12 release?

TechTimes reported on 2026-07-08 that npm v12 ships this month, meaning July 2026, with dependency install scripts blocked by default. GitHub has tied the release to a broader npm security effort covering tokens, two factor authentication, and trusted publishing.