For years, running npm install meant trusting that whatever code got pulled in would behave itself. That trust was often misplaced. Starting in July 2026, npm v12 changes the rules. Install scripts won’t run automatically anymore. Neither will dependencies be pulled from Git repos or remote URLs. All of it becomes opt-in.
This is a direct response to a wave of supply chain attacks that have hammered the JavaScript ecosystem over the past year. In September 2025, attackers hijacked 18 popular npm packages — including debug and chalk — libraries found in virtually every Node.js project. With combined downloads exceeding 2.6 billion per week, it was one of the largest npm attacks in history. In 2025 alone, attackers published nearly 455,000 malicious npm packages. The attacks haven’t slowed down — the March 2026 Axios compromise weaponized one of npm’s most-downloaded packages through credential theft.
The ecosystem needed a structural fix, not just better scanning tools. npm v12 is that fix.
What’s Actually Changing
npm v12 introduces three security-related changes to npm install. First, allowScripts defaults to off — npm install will no longer execute preinstall, install, or postinstall scripts from dependencies unless they are explicitly allowed in your project. This includes native node-gyp builds. Second, –allow-git defaults to none — npm install will no longer resolve Git dependencies, direct or transitive, unless explicitly allowed. Third, –allow-remote defaults to none — npm install will no longer resolve dependencies from remote URLs, such as HTTPS tarballs, unless explicitly allowed.
These aren’t minor configuration tweaks. They close attack vectors that defenders have complained about for years. The Git dependency change is particularly significant. It closes a code-execution path where a Git dependency’s .npmrc could override the Git executable, even when developers thought they were protected by –ignore-scripts. That flag gave many teams a false sense of security.
Why This Matters Beyond the Security Team
Most developers think of supply chain security as someone else’s problem. That’s changing fast. As recently as late May 2026, Microsoft Threat Intelligence uncovered an active supply chain attack involving malicious npm packages registered under organizational scopes that mirrored real internal corporate namespaces. These weren’t obviously suspicious packages. They looked like internal tools.
The average npm project isn’t pulling in a handful of dependencies. The average npm project pulls in 79 transitive dependencies. Any one of those can carry malicious install scripts. Under the current default behavior, those scripts run the moment someone runs npm install. In v12, they won’t — unless a developer explicitly says they should.
Mitch Ashley, VP & Practice Lead, Software Lifecycle Engineering & AI-Native Software Engineering at The Futurum Group, says the change reflects a fundamental rethink of how trust works in the ecosystem. “Package installation is shifting from implicit trust to explicit allowlisting at the ecosystem’s default layer. Disabling automatic script execution, Git resolution, and remote fetches by default concedes that detecting malicious packages after publication cannot keep pace with how fast they appear. Engineering and platform teams now own a dependency allowlist committed to source control, and CI must fail builds on unreviewed install scripts. Verifying what executes at install time becomes a standing engineering obligation rather than a security team afterthought.”
How to Prepare Before July
The good news is that you don’t have to wait for v12 to drop and break your builds. All three changes are available as warnings in npm 11.16.0 or newer, so teams can prepare before the upgrade.
Here’s the recommended workflow:
First, upgrade to npm 11.16.0 or later — this enables advisory mode, where warnings surface but nothing breaks yet. Then run npm approve-scripts –allow-scripts-pending to see which packages have scripts that aren’t yet covered by your policy. Approve the ones you trust, pinned to the version you’ve reviewed, and commit the updated package.json to source control.
Consider running npm approve-scripts –allow-scripts-pending in read-only mode first — it lists every package whose scripts aren’t yet covered without changing anything. That gives you a full picture before you start approving.
One thing to avoid: don’t approve everything with a blanket flag just to make warnings go away. That defeats the purpose. The point is to know which packages are running code on your machine and make a deliberate decision about each one.
For teams relying on internal HTTPS tarballs or monorepos that pin packages to Git branches, the right fix is to migrate to a proper registry — GitHub Packages, Nexus, or Artifactory — rather than adding –allow-remote to every CI script.
Package Maintainers Have Work to Do Too
If you maintain packages that use install scripts, your downstream users won’t get those scripts by default in v12. Two things help: document it by adding a note to your README linking to npm approve-scripts, and reduce the need for scripts by shipping prebuilt binaries using tools like prebuild, prebuildify, or node-pre-gyp, or by moving setup into an explicit command users run after install.
This isn’t just courtesy. If your package silently stops working for users after they upgrade to v12 and they don’t understand why, that’s a support problem and a trust problem.
The Bigger Picture
npm v12 reflects a broader shift happening across the software supply chain. The era of implicit trust — where running npm install was treated like a safe, routine operation — is ending. Explicit allowlists, version pinning, and continuous review are becoming table stakes.
The Shai-Hulud worm, Glassworm, and the string of supply chain attacks throughout 2025 and 2026 have proven that implicit trust in package installation is over. npm v12 doesn’t solve every problem in that space, but it removes the easy path that attackers have relied on for years.
July isn’t far away. The time to run npm approve-scripts –allow-scripts-pending is now.
from DevOps.com https://ift.tt/yNKIrCu
Comments
Post a Comment