GitHub overhauls npm install defaults to choke off supply-chain attacks

GitHub is about to change one of the most consequential commands in the JavaScript world. With npm v12 expected next month, the behaviors that npm install has triggered automatically for years, running install scripts and fetching code from outside the registry, will require explicit approval instead of being trusted by default.

The reasoning is straightforward. npm install is what developers run after cloning a repository, pulling updates, or kicking off a CI/CD build. It downloads a project's dependencies and executes any install-related scripts those packages define. That automation is convenient, and it's exactly why attackers keep targeting it. A single compromised package can run arbitrary code on a developer's machine or inside a build pipeline the moment installation happens, with no further interaction required.

What actually changes in v12

Three defaults are flipping, and each one closes off a distinct attack path.

First, lifecycle scripts go silent unless approved. Starting in version 12, npm install will not run preinstall, install, or postinstall scripts from dependencies unless they have been explicitly approved. The same applies to native module builds triggered through node-gyp, and to prepare scripts coming from Git, local file, and linked dependencies. These hooks are the workhorse of most install-time malware, so removing their automatic execution is the headline protection.

Second, Git dependencies stop resolving on their own. npm install will no longer fetch dependencies from Git repositories, whether direct or transitive, unless explicitly permitted. GitHub points out a subtle reason this matters beyond the obvious: a Git dependency's .npmrc file could alter which Git executable npm uses, creating a code execution path that survives even when install scripts are disabled. Shutting off automatic Git resolution closes that gap too.

Third, remote URL dependencies are blocked by default. Packages pulled from remote URLs, such as HTTPS tarballs, will no longer be resolved unless explicitly permitted, again covering both direct and transitive dependencies.

Taken together, the change removes three forms of implicit trust at once: automatic script execution, automatic Git resolution, and automatic remote URL resolution. Anything a project legitimately depends on still works, but only after a developer signs off on it.

The attacks this would have blunted

This is not a theoretical hardening exercise. The new defaults map directly onto techniques used in a string of recent incidents.

Malicious preinstall and postinstall campaigns have hit widely used packages, including tampering tied to eslint-config-prettier and Toptal's Picasso packages, along with dozens of data-stealing npm packages that relied on lifecycle scripts firing automatically during install. The Git dependency abuse documented in the Shai-Hulud attacks is exactly the kind of non-registry sourcing that v12 now gates behind explicit permission.

If these defaults had been in place, each of those campaigns would have needed a victim to actively approve the malicious behavior rather than getting code execution for free. That shifts the economics of supply-chain attacks in the defender's favor, because the most reliable part of the attack, guaranteed execution on npm install, stops being guaranteed.

What breaks, and how to get ahead of it

The trade-off is real. Projects that depend on any of these behaviors for legitimate reasons, native modules that compile during install, tooling pulled straight from a Git branch, or tarballs fetched over HTTPS, will need to explicitly opt in before upgrading. Plenty of working pipelines quietly rely on at least one of these.

GitHub's recommended path is to upgrade to npm 11.16.0 or newer first. That release displays warnings on every action that will break under version 12. Run your normal install routines, read the warnings, and you get a concrete inventory of the dependencies and workflows that will need approval before you move to v12. It's a practical way to discover your own exposure without breaking anything yet.

The sequencing matters here. Upgrade to 11.16.0, run a few representative installs across your projects and CI jobs, collect the warnings, sort out which flagged behaviors are legitimate, and approve those before jumping to version 12. After the upgrade, only the sources and scripts you've explicitly approved keep working automatically, so doing the audit first prevents a wave of red builds the day you bump the major version.

GitHub has opened a community discussion for developers to weigh in on the changes, which is worth watching if your build relies on any of the affected patterns and you want to flag edge cases before the defaults harden.

The broader pattern is hard to miss. The npm ecosystem has spent years treating package installation as inherently trustworthy, and attackers have spent those same years proving it isn't. Moving execution and non-registry sourcing to an opt-in model accepts a bit of friction in exchange for cutting off the automatic code execution that supply-chain attacks depend on. For teams that have watched the Shai-Hulud waves, the IronWorm campaign, and the steady drip of postinstall malware, that's a trade most will take. The work now is making sure your own legitimate workflows are on the approved list before next month's release lands. You can track the rollout and read the full rationale through the npm documentation.