GitHub Announces NPM 12 Default-Behavior Change for Install Scripts

GitHub is changing what npm install does by default — turning automatic script execution into an action maintainers and CI pipelines must explicitly opt into.

SAN FRANCISCO, CALIFORNIA — GitHub has announced that npm 12, the next major version of the JavaScript registry's command-line client, will change its script-execution defaults to reduce supply-chain risk — disabling the automatic running of dependency install scripts by default. According to GitHub's changelog and reporting from SecurityWeek, The Hacker News, and The Register, npm 12 turns a behavior that runs automatically today into one developers must explicitly opt into. GitHub estimates the release will arrive in July 2026.

The shift addresses what defenders have long identified as the single most abused feature in the npm ecosystem: the convention that installing a package can silently run code on the machine doing the installing. GitHub says the change responds to a recent series of registry incidents, and it arrives alongside related staged-publishing and approval-gated release controls the company has been rolling out across the npm supply chain.

What NPM 12 Will Change

The core change in npm 12 is narrow but consequential. According to GitHub's changelog, the client's allowScripts behavior will default to off, meaning npm install will no longer execute preinstall, install, or postinstall scripts from dependencies unless a project explicitly allows them. The change extends to native node-gyp builds — a package that ships a binding.gyp file but no explicit install script still gets blocked, because npm normally runs an implicit node-gyp rebuild for it — and to prepare scripts pulled from git, file, and link dependencies.

Rather than a blanket ban, GitHub describes the new behavior as an opt-in allowlist. Developers can run npm approve-scripts --allow-scripts-pending to see which packages in their tree want to run scripts, approve the ones they trust with npm approve-scripts, and block the rest with npm deny-scripts. The resulting allowlist is written into the project's package.json and is meant to be committed to source control, so the decision travels with the project rather than living on a single developer's machine.

The change does not arrive in isolation. GitHub's changelog bundles two related default flips into the same npm 12 release: --allow-git will default to none, so npm install will no longer resolve Git dependencies unless explicitly permitted, and --allow-remote will default to none, blocking dependency resolution from remote URLs such as HTTPS tarballs by default. Together, the three changes convert several behaviors that run automatically today into actions a maintainer or pipeline must consciously enable.

Crucially, the defaults are not waiting on the July release to become testable. GitHub says all three are already available behind warnings in npm 11.16.0 and later, so an install routine that depends on auto-run scripts will surface warnings now — before the behavior actually changes — giving maintainers a window to audit and prepare.

Why Install-Script Defaults Have Been the Long-Standing Supply-Chain Reform Target

The install-script convention exists for a legitimate reason. Many packages need to compile native code, fetch platform-specific binaries, or run setup steps at install time, and lifecycle scripts are how the ecosystem has handled that since npm's early days. The trade-off is that the same mechanism lets any package — direct or transitive — run arbitrary code on a developer's machine or a build server the moment it is installed, with no user action beyond the install command itself.

That property has made install scripts the recurring entry point in npm supply-chain compromises. When an attacker publishes a malicious package or takes over a legitimate one, an automatically executed postinstall script is the most reliable way to turn a download into code execution, which is why security researchers have argued for years that the default should be flipped. The counterargument has always been compatibility: a large share of the ecosystem relies on install scripts working without intervention, and changing the default risks breaking installs across countless projects at once.

The reform debate has therefore centered less on whether install-script abuse is a problem — that is broadly accepted — than on how to constrain it without breaking legitimate workflows. The same tension runs through related coverage of how supply-chain worms exploit the install path, from self-replicating npm worms that scout cloud secrets to cross-ecosystem poisoning that reaches npm, PyPI, and crates alike. npm 12's allowlist model is GitHub's attempt to resolve that tension: keep install scripts available, but make running them a deliberate, auditable choice.

The Series of Registry-Incident Disclosures That Prompted the Change

GitHub ties the npm 12 defaults directly to a recent run of supply-chain incidents in the npm registry. According to SecurityWeek and The Register, the change is a response to that series rather than a standalone roadmap item, and the timing reflects how concentrated the incidents have been over the preceding months.

The reporting situates npm 12 against the backdrop of self-replicating worms and credential-scouting campaigns that have repeatedly abused automatic install-time execution to spread. The pattern across those incidents is consistent: a compromised or malicious package runs a script at install, harvests secrets or propagates, and uses the same automatic-execution convention as both its delivery mechanism and its means of moving to the next target. That is precisely the behavior npm 12 is designed to interrupt.

It is worth being precise about what the disclosures establish and what they do not. GitHub's own framing, echoed by SecurityWeek and The Register, is that the cumulative weight of these registry incidents is the reason the default is finally changing. The specific attribution, scope, and full incident list behind that framing are matters of the individual disclosures rather than of GitHub's npm 12 announcement, which speaks to the defaults and the rationale rather than to any single attacker or campaign.

Migration Impact for Legitimate Workflows

For maintainers and teams whose installs depend on scripts, the practical impact is a one-time audit rather than a permanent breakage. GitHub's prepare guidance is to upgrade to npm 11.16.0 or later, run a normal install, and review the warnings; npm approve-scripts --allow-scripts-pending then lists the packages that want to run scripts so a team can approve the trusted ones and let the rest stop. After that, only approved scripts keep running once the project upgrades to npm 12.

The change is most visible in continuous-integration and build pipelines, where install scripts often do real work — compiling native modules, generating bindings, or fetching platform binaries. Pipelines that have relied on those scripts running automatically will need an approved allowlist committed to package.json, or an explicit flag, to keep functioning under the new defaults. Projects that pull dependencies over Git or remote tarballs will face the parallel adjustment from the --allow-git and --allow-remote default flips.

Because the warnings are live in npm 11.16.0 and later, the migration can be done ahead of the July release rather than under deadline pressure after it. GitHub points maintainers to its npm approve-scripts and npm deny-scripts documentation and to a community discussion thread for the rollout. The company has not, in the changelog itself, published a single consolidated migration guide beyond that documentation; teams with complex install routines will likely need to validate their own pipelines against the warnings rather than rely on a universal recipe.

What This Does and Doesn't Solve

Flipping the install-script default closes the most direct and most abused path from a malicious package to code execution. An attacker can no longer count on a postinstall script firing automatically the moment a compromised dependency lands in a project, which removes the easiest and most reliable trigger in a large share of npm supply-chain incidents. For the common case — a developer or CI job installing dependencies that quietly try to run code — the new default meaningfully raises the bar.

It does not, however, eliminate supply-chain risk. A package's actual runtime code still executes when an application imports and runs it, so a malicious payload that lives in the imported module rather than in an install hook is unaffected by the change. The allowlist also depends on human judgment: a team that approves a package which is later compromised, or that reflexively allows everything to make a stubborn install work, reintroduces much of the exposure the default was meant to remove. And the Git and remote-resolution flips, while closing additional automatic code paths, similarly shift risk onto the choices teams make about what to allow.

The honest framing is that npm 12 narrows the attack surface at the install boundary without claiming to secure the dependency itself. It changes a default that favored convenience over safety, and it gives maintainers an auditable mechanism to reason about which packages may run code at install time — a structural improvement, but one whose effectiveness depends on how carefully the resulting allowlists are maintained.

Open Questions

Several details around the rollout remain unsettled at the time of GitHub's announcement. The exact npm 12 release date is given only as an estimate of July 2026, and a firm date had not been published. How the new defaults interact with private and enterprise registries — whether organizations running internal registries see the same behavior, or can centrally manage allowlists for their developers — is not spelled out in the changelog and is worth watching as the release nears.

It also remains to be seen whether the broader JavaScript tooling ecosystem follows npm's lead. Alternative clients such as yarn and pnpm have their own approaches to install scripts, and whether they adopt comparable opt-in defaults in response to npm 12 is not yet established. Until they do, a team's exposure to automatic install-time execution will depend in part on which client it uses, not only on the npm default. For now, the load-bearing facts are clear: GitHub is flipping the install-script default in npm 12, the change is scoped to install-time execution and configurable through an allowlist, and the behavior is already testable behind warnings ahead of the July release.

Sources