In July 2026, GitHub is going to change how npm install works for the first time in npm's history - and it's going to break some builds on purpose. Starting with npm v12, the package manager will stop automatically running install scripts, pulling Git dependencies, or fetching dependencies from remote URLs unless you explicitly approve each one. Behavior that's been on-by-default for over a decade is becoming opt-in.

That sounds like plumbing. It isn't. npm install has always been allowed to execute arbitrary code on your machine - and npm sits on nearly every developer laptop and CI/CD pipeline in the JavaScript world. Over the past year, attackers turned that into a highway: the self-propagating Shai-Hulud worm, the eslint-config-prettier compromise, the Toptal Picasso packages, and a steady stream of data-stealers all relied on code running the moment a package was installed - often from a dependency the developer never chose. npm v12 closes that highway.

If your organization ships JavaScript or runs npm in its pipelines, the question isn't whether this affects you - it's whether you're ready before the defaults flip.

What GitHub announced

On June 9, 2026, GitHub published a breaking-change notice for npm v12, estimated for July 2026. Today, lifecycle scripts (preinstall, install, postinstall), Git-sourced dependencies, and tarballs from arbitrary URLs all run or resolve automatically - including from packages buried deep in your transitive tree. Three new defaults change that:

Blocking install scripts alone wasn't enough. To install a Git dependency, npm shells out to your system's git program - and a malicious dependency could ship its own .npmrc file pointing npm at a different "git" executable, running attacker code even with install scripts turned off. Gating Git dependencies behind --allow-git shuts that second door. (Local file and directory dependencies are unaffected.)

Transition path: It's a two-phase rollout. Phase 1 is live now - upgrade to npm 11.16.0+ and you'll get warnings for everything that will break under v12, without anything being blocked. Phase 2 is v12 itself, when the defaults take effect.

Why now: a year of npm getting hammered

npm has been the soft underbelly of the software supply chain, and 2025-2026 made the case impossible to ignore:

• Shai-Hulud - a self-propagating worm that stole developer and CI secrets, then used them to publish itself into more packages. Its later waves specifically abused Git dependency behavior.
• eslint-config-prettier - a hugely popular config package compromised to push malware to anything that pulled it in.
• Toptal's Picasso packages - legitimate packages turned malicious after an account compromise.
• A steady drip of data-stealing packages designed to fire the moment they're installed.

The common thread: the payload runs at install time, often from a dependency the developer never chose. That's exactly what npm v12 neutralizes.

These install defaults are only half the story. In the months before, GitHub also locked down the npm accounts that publish packages, to make publisher takeover harder: it disabled and then fully revoked the old never-expiring "classic" tokens (Nov-Dec 2025), made 2FA mandatory for publishing (shifting from app/SMS codes to phishing-resistant security keys), made npm login hand out short-lived sessions instead of long-lived credentials, and added Trusted Publishing so CI can publish with no stored token at all. The result covers both halves of the kill chain: how an attacker gets in, and what their package can do once it lands.

What this fixes - and what it doesn't

Turning off automatic install-script execution is the single most impactful default npm could ship - most "install and detonate" malware dies the moment that behavior is opt-in. But it's not a complete fix:

• Legitimate packages still need install scripts. Teams will approve allowlists - and an allowlist is only as good as the review behind each entry. Rubber-stamping reintroduces the risk.
• Malicious runtime code is untouched. A payload that fires when you import and call a package sails right through.
• Account takeover is still the root cause. A phished maintainer or compromised pipeline can still ship a poisoned-but-"trusted" release.

GitHub raised the floor for everyone. The ceiling - knowing which dependencies are in your pipeline, who can publish them, and whether a new version is behaving suspiciously - is still your responsibility.

What your team should do now

1. Upgrade to npm 11.16.0+ and audit your scripts. Run npm approve-scripts --allow-scripts-pending to list every dependency that wants to run an install script, then allowlist the ones you trust (npm approve-scripts) and block the rest (npm deny-scripts).
2. Inventory your Git and remote-URL dependencies before the defaults flip. In v12 they're gated by --allow-git (since npm 11.10.0) and --allow-remote (since npm 11.15.0), both defaulting to none.
3. Kill long-lived tokens. Migrate publishing to OIDC Trusted Publishing and enforce WebAuthn 2FA for every maintainer.
4. Watch runtime, not just install - that's the gap these defaults leave open.

Key takeaways

• npm v12 makes install-time code execution opt-in - the biggest change to npm's threat model in years.
• It would have blunted recent campaigns like Shai-Hulud and eslint-config-prettier - but account takeover and malicious runtime code remain wide open.
• Better defaults shift the burden of judgment to you: your supply-chain security now rides on how you handle approvals, identities, and post-install monitoring.

At Legit Security, we give AppSec and platform teams a live picture of their software supply chain - every dependency, every publisher identity, and the pipelines that ship them - so a poisoned package or a hijacked maintainer surfaces before it reaches production. The npm defaults are a great floor. We help you build the ceiling.

Sources

• GitHub Changelog - Upcoming breaking changes for npm v12 (June 9, 2026)
• GitHub Changelog - npm classic tokens revoked, session-based auth (Dec 9, 2025)
• GitHub - Our plan for a more secure npm supply chain
• BleepingComputer - GitHub announces npm security changes
• ReversingLabs - Will new npm security stop the next Shai-Hulud?