npm Install Scripts Disabled by Default in npm 12 — Here’s Why It Matt

GitHub is about to make one of the most consequential security changes to the npm ecosystem in years. Starting with npm 12 — due out next month — npm install scripts will no longer run automatically by default. Developers will need to explicitly approve them first. It’s a breaking change, GitHub acknowledges that openly, but the company argues the tradeoff is long overdue.

• npm install scripts will be disabled by default in npm 12, requiring explicit developer approval before any dependency code runs.
• GitHub calls npm install scripts the ‘single largest code-execution surface’ in the npm ecosystem, affecting millions of Node.js projects.
• Git dependencies and remote URL resolution will also be blocked by default, closing additional code-execution paths exploited in supply chain attacks.
• Developers can prepare now by upgrading to npm 11.16.0 and auditing which package scripts they actually trust and need.

Why npm Install Scripts Are Such a Big Problem

If you’ve ever run npm install on a Node.js project and wondered what’s actually happening under the hood, the answer is more than most people realise. npm doesn’t just download packages — it also executes code. Specifically, it runs lifecycle hooks called preinstall, install, and postinstall scripts that package authors can include in their modules. These npm install scripts run automatically, for every package, including every transitive dependency — the dependencies of your dependencies of your dependencies.

GitHub describes npm install scripts as the ‘single largest code-execution surface in the npm ecosystem.’ That’s not hyperbole. A typical Node.js project can pull in hundreds or even thousands of packages. Each one of those, if compromised or malicious from the start, gets a free pass to execute arbitrary code on your developer machine or CI runner the moment you run npm install. No prompt. No warning. No opt-in.

This is exactly the attack pattern that has powered some of the most damaging software supply chain incidents of the past several years. Attackers compromise a popular package — sometimes by hijacking a maintainer’s credentials, sometimes by publishing a typosquat, sometimes by sneaking malicious code into a legitimate update — and the lifecycle hooks do the rest. The developer never sees it coming.

What npm 12 Is Actually Changing

The changes landing in npm 12 are targeted and specific. GitHub has outlined three major behavioural shifts from the current defaults:

• npm install scripts blocked by default: The preinstall, install, and postinstall lifecycle hooks will no longer execute during npm install unless the project has explicitly allowed them. This applies to all dependencies, direct and transitive.
• Git dependencies blocked by default: npm will no longer resolve Git dependencies — direct or transitive — unless a developer passes the new –allow-git flag or configures it explicitly in the project.
• Remote URL dependencies blocked by default: Resolving dependencies from remote URLs, such as HTTPS tarballs, will also be off by default. The –allow-remote flag will be required to enable this.

The Git dependency change deserves particular attention. GitHub points out that even when developers used the existing –ignore-scripts flag — which was supposed to prevent lifecycle scripts from running — a Git dependency’s .npmrc configuration file could override the Git executable itself. That’s a surprisingly deep hole in what many developers thought was a reliable safeguard. npm 12 closes it by defaulting –allow-git to ‘none.’

There’s also a detail that will catch some developers off guard: native builds. If you’re working with a package that has a binding.gyp file — which triggers an implicit node-gyp rebuild — that too will be blocked. npm has historically run node-gyp automatically for such packages even when no explicit install script is present. Under the new defaults, that implicit execution is treated the same as any other npm install scripts entry: blocked until you approve it.

npm Install Scripts: The Opt-In Model Explained

The philosophy behind the change is straightforward. Right now, npm install scripts are trusted by default and blocked only if you remember to ask. npm 12 inverts that relationship: scripts are blocked by default and trusted only when you explicitly say so. As GitHub put it, ‘making script execution opt-in closes that path while keeping it one command away for the packages you trust.’

The practical workflow GitHub recommends for existing projects looks like this: upgrade to npm 11.16.0 or newer first, run your normal install, and pay attention to the warnings that now surface about which packages have scripts. From there, run npm approve-scripts –allow-scripts-pending to get a full picture of what’s in your dependency tree. Review the list, approve the packages you actually trust, and commit the updated package.json. When npm 12 arrives, only the approved npm install scripts will run. Everything else stops silently.

That last part — ‘stops silently’ — is worth thinking through carefully. If you have native modules, build tools, or post-install configuration scripts that you’ve never thought about because they just worked, npm 12 will surface them. That’s the point, actually. The change forces a conversation between developers and their dependency trees that probably should have been happening all along.

This Fits a Broader Security Push at npm

The script-blocking change isn’t happening in isolation. Earlier this year, npm introduced a setting called min-release-age, which instructs npm to reject any package version published less than a specified number of days ago. The rationale: attackers who hijack a package and publish a malicious version rely on the window between publication and detection. A minimum release age gives security teams and the community time to spot something suspicious before it lands in production builds.

Together, these changes reflect a clear shift in how GitHub — which acquired npm — is thinking about the registry’s security posture. For years, npm’s defaults were optimised for convenience. Install everything, run everything, get building fast. The supply chain attack wave of the early-to-mid 2020s has made that philosophy untenable. The SolarWinds breach, the XZ Utils backdoor, the cascade of malicious npm packages targeting cryptocurrency wallets — the threat is real and the damage is measurable.

What’s notable about GitHub’s approach here is that it’s choosing to break things. That takes a certain confidence. Plenty of enterprise tooling, CI pipelines, and monorepos are going to hit unexpected failures when npm 12 drops, and the support tickets will follow. GitHub is betting that the short-term friction is worth the long-term security gain — and given the trajectory of supply chain attacks, that bet seems well-placed.

What Developers Should Do Before npm 12 Lands

The migration path is clear enough, but it requires active effort rather than passive upgrading. Sitting on an older npm version and hoping nothing changes isn’t a strategy — npm 12 is coming, and the projects most likely to break badly are the ones where no one has audited the dependency tree in years. Taking time now to review which npm install scripts your project relies on will make the transition significantly smoother.

The sensible steps: upgrade to npm 11.16.0 now, run installs in a non-production environment, and work through the warnings. Pay special attention to native modules and any packages pulling from Git repos or remote URLs — those are the three categories most likely to cause friction. If you’re maintaining a package yourself that uses npm install scripts legitimately, think about whether you need to communicate that change to your users and update your documentation accordingly.

The npm ecosystem contains a vast number of packages and sees enormous download volumes every week. Changing the security defaults at that scale is genuinely difficult. But ‘difficult’ and ‘necessary’ aren’t mutually exclusive — and the developers who take the time to understand what’s actually running during their installs will be in a far better position than those who just click through the warnings and hope for the best.

Source: The Hacker News

Frequently Asked Questions