npm v12 Blocks Install Scripts by Default to Stop Supply-Chain Attacks

Key Takeaways

• npm v12 will not run preinstall, install, or postinstall scripts unless explicitly approved
• Git and remote URL dependencies are blocked by default in the new version
• Upgrade to npm 11.16.0 now to see warnings about workflows that will break

GitHub announced that npm v12, expected next month, will disable automatic code execution during package installation. The change targets a core attack vector: malicious scripts that run the moment a developer types `npm install`.

The update shifts npm from trust-by-default to explicit-approval-required. Preinstall, install, and postinstall scripts from dependencies will no longer execute automatically. Neither will node-gyp native module builds or prepare scripts from Git, local file, and linked dependencies.

"This isn't just about blocking scripts; it's about shifting the industry to an auditable, explicit trust model," said Bodo Tasche, Senior Security Researcher. "The era of 'install-and-hope' is officially over."

Why This Matters Now

The timing is no accident. Early June 2026 saw a wave of "Miasma" supply-chain attacks that exploited npm's default behavior. Automated systems disabled 73 Microsoft and Azure GitHub repositories in a 105-second sweep on June 5. The Miasma worm exfiltrated an estimated 300,000+ credentials, including AWS keys, Azure secrets, and GitHub personal access tokens, across 487 organizations.

The attack worked because `npm install` automatically executes lifecycle scripts. A compromised dependency could run arbitrary code on any machine that installed it, from a developer's laptop to a CI/CD pipeline. No user action required beyond running the standard install command.

What Changes in npm v12

GitHub outlined three major changes:

1. Install scripts are blocked by default. Preinstall, install, and postinstall scripts from dependencies will not run unless explicitly approved. This includes node-gyp builds and prepare scripts from Git, local file, and linked dependencies.
2. Git dependencies require explicit permission. npm will not fetch dependencies from Git repositories, whether direct or transitive, unless you permit them. This closes a path where a Git dependency's .npmrc file could alter which Git executable runs.
3. Remote URL dependencies are blocked. Dependencies from HTTPS tarballs or other remote URLs will not resolve unless explicitly permitted. This applies to both direct and transitive dependencies.

Each change targets a specific attack technique. Malicious preinstall and postinstall scripts have targeted packages like eslint-config-prettier and Toptal's Picasso packages. Git dependency abuse appeared in documented Shai-Hulud attacks. Remote URL resolution has enabled dozens of data-stealing npm packages.

The Industry Context

npm is not the first package manager to adopt this posture. Hacker News discussions noted that pnpm and Bun already run with secure-by-default settings. Reddit's r/cybersecurity community dubbed the Microsoft repository takedown "The 105-second incident" and called it a wake-up call for how easily automated tools can turn against their operators.

“I'm calling it now: the rapid integration of AI agents into development environments, combined with these legacy dependency behaviors, is creating one of the most volatile security landscapes in history.”

— George Hotz, Software Engineer & Security Researcher

The concern is real. AI coding assistants often run `npm install` as part of automated workflows. A compromised dependency in one project can spread through AI-assisted code generation faster than human review can catch it.

How to Prepare Your Projects

GitHub recommends a two-step approach:

1. Upgrade to npm 11.16.0 or newer now. This version displays warnings on all actions that will break under v12.
2. Run your normal install routines and review the warnings. Identify dependencies or workflows that will need explicit approval.

Projects that rely on install scripts for legitimate purposes, like native module compilation, will need to opt in before upgrading. After moving to v12, only explicitly approved scripts and dependency sources will function automatically.

GitHub has opened a community discussion for developers to share suggestions on the upcoming changes. If your workflow depends on behaviors that will be blocked, now is the time to document your use case.

What This Means for CI/CD Pipelines

CI/CD systems are high-value targets. They have access to deployment credentials, cloud APIs, and production infrastructure. A malicious install script running in CI can exfiltrate secrets before anyone notices.

The new defaults will require pipeline maintainers to audit their dependency trees. Any package that needs install scripts to function will require explicit configuration. This adds friction but creates an auditable trail of which packages have elevated permissions.

Teams should start this audit before v12 ships. Running npm 11.16.0 in staging environments will reveal which dependencies trigger warnings. Document each one and decide whether to approve the script or find an alternative package.

The Bigger Picture

This change reflects a broader shift in how the industry thinks about trust. The old model assumed dependencies were safe until proven otherwise. The new model assumes nothing runs without explicit approval.

For developers, this means more upfront work. You will need to review dependencies, approve scripts, and maintain an allowlist. For organizations, it means a smaller attack surface. A compromised package can no longer silently execute code just because someone ran `npm install`.

Frequently Asked Questions

When does npm v12 release?

GitHub expects npm v12 to ship next month, in July 2026.

Will npm v12 break my existing projects?

It might. Any dependency that relies on preinstall, install, or postinstall scripts will stop working unless you explicitly approve it. Upgrade to npm 11.16.0 now to see warnings about affected workflows.

How do I approve install scripts in npm v12?

You will need to explicitly opt in to allow scripts from specific packages. GitHub recommends reviewing the community discussion for details on the approval mechanism.

Does this affect node-gyp native module builds?

Yes. Native module builds triggered through node-gyp will require explicit approval, just like other install scripts.

Are other package managers already doing this?

Yes. Hacker News users noted that pnpm and Bun already run with secure-by-default settings that block automatic script execution.

Source: BleepingComputer