npm v12 is the next major release of the npm package manager, shipping in July 2026 with install scripts, Git dependencies, and remote sources all disabled by default instead of enabled by default.

Will npm v12 break my existing builds?

It can, if any dependency in your tree relies on a preinstall, install, or postinstall script to function. Upgrade to npm 11.16.0 now to see advisory warnings before v12 makes the change mandatory.

Does npm v12 stop all supply chain attacks?

No. It closes the install-script and remote-source vectors used in the Axios, node-ipc, and Miasma incidents, but it doesn't stop attacks built on stolen maintainer credentials, since those ship as trusted, signed releases.

How do I prepare for npm v12 today?

Upgrade to npm 11.16.0 or later, run npm approve-scripts to audit which dependencies use install scripts, and build an allowlist in package.json before v12 lands.

npm v12 Ships: Install Scripts Blocked by Default

npm is closing a hole that's been exploited by state-backed hackers twice this year. npm v12 ships before the end of July 2026, and it flips three of the package manager's oldest permissive defaults from implicit trust to explicit opt-in. If your CI pipeline leans on install scripts without knowing it, you've got weeks to find out before the upgrade breaks your build — quietly, with exit code 0.

What's Actually Changing

Three defaults get flipped in v12:

Blocked install scripts: preinstall, install, and postinstall hooks no longer fire automatically when you run npm install. That includes native builds like node-gyp rebuild.

Blocked Git dependencies: pulling packages straight from custom Git URLs is off by default, closing a common way attackers dodge script restrictions.

Blocked remote sources: same idea, applied to non-registry sources in general.

Under the old model, every package in your dependency tree — including ones you never chose directly — got the right to run arbitrary shell commands the moment npm install finished resolving. Sonatype's 2026 supply chain report says only about 2% of packages actually need install scripts to work. The other 98% carried the capability anyway. v12 shuts that down.

Why It Took a Year of Attacks to Get Here

This isn't a proactive redesign. It's a response. North Korean group Sapphire Sleet hijacked Axios's maintainer account in March, pushing a malicious dependency that dropped a cross-platform RAT to roughly 100 million weekly downloads for a three-hour window. Two months later, malicious node-ipc versions hit the registry with a credential-stealing payload. Then came Miasma, the worm that hit Red Hat's npm packages through a compromised GitHub account, and the Mastra supply chain attack and IronWorm campaign targeting AI API keys that followed the same wormable playbook. Each one used a postinstall hook as the entry point. Every one of them is exactly what v12 is designed to stop.

What Breaks (and How to Check Now)

npm 11.16.0, already out, ships advisory-mode warnings for exactly this transition. Upgrade to it now and you'll see which of your dependencies rely on scripts that v12 will block. Run npm approve-scripts to audit your tree and build a local allowlist in package.json before you're forced into it mid-deploy.

If you're running npm install in CI without acting on those warnings, expect silent build failures the day v12 becomes default — not error messages, just broken output with a green checkmark.

Is This Enough?

No, and security researchers are saying so on the record. OX Security points out that account takeover is still wide open: once an attacker controls a legitimate maintainer's credentials, the malicious code ships as a trusted, signed release, and install-script blocking does nothing. There's also a carve-out for native compilation — packages with a binding.gyp and no explicit install script still get to run node-gyp. v12 shrinks the attack surface. It doesn't close it.

Sources: TechTimes, Infosecurity Magazine, Cybernews, Wiz, Unit 42.