npm Security Overhaul: Key Changes Coming in npm v12

GitHub is making some of the most significant npm security changes in years. The company has confirmed that npm v12 — expected to land next month — will fundamentally change what happens when a developer types npm install, and the goal is straightforward: stop treating every dependency as inherently trustworthy.

• GitHub’s npm security changes in v12 will block automatic execution of install scripts from all dependencies by default.
• The npm security changes require explicit opt-in for Git and remote URL dependencies, closing key supply-chain attack vectors.
• Developers can preview breaking changes now by upgrading to npm 11.16.0, which surfaces warnings before v12 ships.
• Recent attacks on packages like eslint-config-prettier and Toptal’s Picasso would have been disrupted by these new defaults.

• GitHub’s npm security changes in v12 will block automatic execution of install scripts from all dependencies by default.
• The npm security changes require explicit opt-in for Git and remote URL dependencies, closing key supply-chain attack vectors.
• Developers can preview breaking changes now by upgrading to npm 11.16.0, which surfaces warnings before v12 ships.
• Recent attacks on packages like eslint-config-prettier and Toptal’s Picasso would have been disrupted by these new defaults.

Why npm install Has Always Been a Risk

For anyone who’s spent time in the JavaScript ecosystem, the problem isn’t new. When you run npm install, you’re not just downloading files — you’re potentially executing code. Packages can define preinstall, install, and postinstall scripts that run automatically on your machine, in your CI/CD pipeline, with whatever permissions your process happens to have. That’s a powerful feature. It’s also an enormous attack surface.

Attackers have understood this for years. The npm registry has been the target of repeated supply-chain campaigns precisely because the trust model is so permissive. A malicious package gets installed — sometimes through a typosquat, sometimes by compromising a legitimate maintainer’s account — and its install scripts execute without any user confirmation. By the time anyone notices, credentials have been exfiltrated or worse.

The broader software supply-chain threat isn’t hypothetical. Research has consistently documented significant year-over-year increases in supply-chain attacks. npm, as the world’s largest package registry with over two million published packages, has always been at the centre of that problem. The npm security changes announced by GitHub are a direct response to the pattern that’s repeated itself across dozens of documented incidents.

What the npm Security Changes Actually Do

The npm security changes arriving in v12 break down into three distinct areas, each targeting a different attack vector that currently operates automatically.

Install script blocking. Starting in v12, npm install will no longer run preinstall, install, or postinstall scripts from dependencies unless a developer has explicitly approved them. This extends to native module builds triggered through node-gyp — a common vector — and to prepare scripts from Git, local file, and linked dependencies. It’s a sweeping change. The default flips from “run everything” to “run nothing you haven’t signed off on.”

Git dependency restrictions. npm v12 will also stop fetching dependencies from Git repositories — direct or transitive — unless explicitly permitted. GitHub points out that this closes a specific code-execution path: a Git dependency’s .npmrc file could be crafted to alter which Git executable npm uses, even in environments where install scripts are already disabled. That’s a subtle bypass that researchers have documented in what’s been called “Shai-Hulud” attacks.

Remote URL dependency blocking. Dependencies specified as remote URLs — think HTTPS tarballs hosted outside the official registry — will no longer resolve automatically. Again, both direct and transitive dependencies are covered. This matters because transitive dependencies are often the ones nobody’s paying close attention to.

Real Attacks These Defaults Would Have Blocked

It’s easy to talk about security improvements in abstract terms. GitHub’s announcement is more useful because it points to concrete attack campaigns these npm security changes would have disrupted.

The eslint-config-prettier incident involved malicious packages exploiting postinstall scripts to steal data from developer environments. Toptal’s Picasso packages were compromised in a campaign that similarly abused install-time script execution. Beyond those named cases, GitHub references “dozens of data-stealing npm packages” that followed the same pattern. With v12’s new defaults, none of those scripts would have executed without an explicit developer decision to allow them.

The Shai-Hulud attack technique is worth understanding separately. It demonstrates that even organisations that had already disabled install scripts weren’t fully protected, because Git-based dependencies could still manipulate the local environment through .npmrc configuration. Closing that path is one of the more technically interesting aspects of what GitHub is shipping here.

npm Security Changes: How to Prepare Before v12 Drops

GitHub’s migration path is sensible. Developers who upgrade to npm 11.16.0 or newer will start seeing warnings whenever an install action hits something that would break under v12’s new rules. The idea is that you run your normal install routines, watch for those warnings, and identify any dependencies or internal workflows that will need explicit approval before you make the jump to v12.

That’s a thoughtful approach to a potentially disruptive transition. The npm ecosystem is massive, and plenty of legitimate packages use postinstall scripts for entirely reasonable purposes — generating binaries, compiling native modules, running setup tasks. GitHub isn’t claiming those use cases are wrong; it’s just saying they now require deliberate approval rather than silent automatic trust. Understanding these npm security changes in advance gives teams the best chance of a smooth upgrade.

For teams running large Node.js projects with deep dependency trees, the audit process could be non-trivial. Transitive dependencies — packages your packages depend on — are the ones that tend to surprise people. A project might have hundreds of them, and tracking down which ones use install scripts isn’t always straightforward today. The v11.16.0 warning system is designed to surface exactly that information during real install runs, which is more reliable than any static analysis approach.

GitHub has also opened a community discussion for developers to share feedback on the upcoming changes, suggesting the team is watching for edge cases they may not have anticipated. That’s worth engaging with if your projects rely on any of the behaviours being restricted.

A Shift in How npm Thinks About Trust

Zoom out and what GitHub is really doing here is changing the default trust posture of the entire npm toolchain. The old model assumed that anything in the registry was safe enough to execute automatically. The new model assumes that execution requires consent. That’s a fundamental philosophical shift, and it’s one that’s been a long time coming.

Other package ecosystems have grappled with the same tension. Python’s pip doesn’t run arbitrary install scripts in the same way. Rust’s Cargo has build scripts but the community culture around auditing them is different. npm’s permissive defaults were a product of its era — an ecosystem that prioritised developer velocity over security hygiene. The attack landscape of 2024 and 2025 has made that trade-off untenable.

What’s notable is that GitHub is making these npm security changes at the toolchain level rather than waiting for registry-side controls or third-party security tools to fill the gap. That means the protection applies to every developer running npm, not just those at organisations with mature security tooling. The npm security changes in v12 are, in that sense, a form of democratised defence — raising the floor for the entire ecosystem rather than just the segment that’s already paying attention to supply-chain risk.

Whether the ecosystem embraces the change smoothly will depend largely on how much friction the new approval workflows introduce in practice. If the experience is too disruptive, there’s always the risk that developers find ways to bulk-approve everything and defeat the purpose. Getting the UX right on explicit approval — making it easy to do correctly, hard to bypass lazily — will matter as much as the technical controls themselves. The community discussion GitHub has opened is probably where that conversation needs to happen, and soon.

Related: npm security changes

Source: Bleeping Computer

Frequently Asked Questions