npm 12 Ships With Install Scripts Disabled by Default to Cut Supply-Chain Risk

npm flips its most-abused default: install scripts no longer run automatically, turning a silent code-execution path into a deliberate, auditable choice for developers and pipelines.

SAN FRANCISCO, CALIFORNIA — npm, the package registry and command-line client at the center of the JavaScript ecosystem, released npm 12 on or around July 9, 2026 with a change defenders have argued for over years: dependency install scripts no longer run by default. According to reporting from The Hacker News, the new major version disables the preinstall, install, and postinstall lifecycle hooks by default to reduce supply-chain risk, converting a behavior that has run automatically for most of npm's history into one a project must explicitly opt into. The move lands after months of npm contributor-account compromises that repeatedly abused exactly this automatic-execution path.

The significance is less any single technical detail than the shift in default itself. For years, installing a package could silently run code on the machine doing the installing, because npm executed each dependency's install-time scripts as part of a normal install. That convention lets packages compile native code or fetch platform binaries at install time, but it also gave any package in a dependency tree — direct or transitive — a reliable way to run arbitrary code the moment it landed. npm 12 makes running those scripts a deliberate, auditable decision rather than the silent default, which is why the release reads as an ecosystem-policy signal for the whole JavaScript supply chain.

What npm 12 Changes

The core change in npm 12 is narrow in mechanism but broad in consequence. By default, running an install no longer executes a dependency's install scripts — the preinstall, install, and postinstall lifecycle hooks that npm has historically run automatically as part of resolving and building a dependency tree. In practical terms, a package that expected to run code at install time will not do so on npm 12 unless the installing project has explicitly allowed it. The scripts still exist and can still run; what changes is that running them is now an opt-in action rather than the silent default.

This is not npm's first move in this direction, and it should be read as the delivery of a plan already telegraphed rather than a surprise. The CyberSignal previously covered GitHub's announcement of the npm 12 default-behavior change for install scripts, which framed the flip as an upcoming breaking change and made the new behavior testable behind warnings in earlier npm releases. The July release is that announced change arriving in a shipped major version, with install-time execution off by default rather than merely flagged with a warning.

The rationale npm and the reporting attach to the change is consistent and specific: install-time lifecycle scripts are the single largest code-execution surface in the npm ecosystem, because a normal install runs scripts from every dependency in the tree, including deep transitive ones a developer never chose directly. A single compromised or malicious package anywhere in that tree can, under the old default, run code on a developer machine or a CI runner the instant it is installed. Disabling that automatic execution removes the most direct and most reliable trigger that supply-chain attackers have relied on. It does not make the dependency itself trustworthy, but it closes the door that opened on install rather than on use.

Why This Is an Ecosystem-Policy Signal, Not Just a Release Note

The install-script default has been the central battleground of npm supply-chain reform precisely because it sits at the intersection of convenience and exposure. Security researchers have argued for years that the default should be flipped; the counterargument has always been compatibility, since a large share of the ecosystem relies on install scripts working without intervention. npm 12 resolves that tension in favor of safety-by-default, and it arrives against a backdrop of contributor-account compromises that made the abstract risk concrete — including incidents such as the compromise that pushed malicious versions of 145 Mastra-related npm packages through a contributor account. When an attacker who has taken over a legitimate maintainer's account can publish a poisoned version, an automatically executed postinstall script is the fastest path from that publish to code running on thousands of machines.

That pattern has recurred across the ecosystem in forms beyond straightforward account takeover. It appears in AI-adjacent delivery schemes such as hallusquatting, where an AI coding assistant's hallucinated package names became a botnet-delivery vector, and in continuous-integration compromises such as the Cordyceps campaign that reached roughly 300 GitHub repositories through their CI/CD pipelines. The common thread is automatic execution: a poisoned artifact that runs on install, harvests secrets or propagates, and uses the same silent-execution convention as both its delivery mechanism and its means of moving to the next target. npm 12's default is aimed squarely at interrupting that mechanic across the board, which is what elevates it from a routine release note to a policy signal for the whole registry.

Read as policy, the release fits a sequence rather than standing alone. npm has been layering controls at successive points in the publish-and-install pipeline, and the install-script default is the latest and most visible of them. The direction of travel is consistent: reduce the number of things that happen automatically without a human decision, and make the remaining automatic behaviors auditable. For defenders, the useful framing is that npm is not claiming to have solved supply-chain risk — it is removing the easiest lever attackers have pulled, and shifting more of the residual risk onto choices teams make deliberately.

What It Means for Developers and Defenders This Week

For developer-defenders, the immediate task is a posture review rather than an emergency. Because install scripts no longer run by default, any install routine that depended on them — most often to compile native modules, generate bindings, or fetch platform-specific binaries — needs to be checked and, where legitimate, explicitly re-enabled for the packages that require it. This is a one-time audit for most projects, not a permanent breakage, and it dovetails with the broader push toward gated, deliberate release and install behavior that npm has been rolling out, including staged publishing and 2FA-gated release approval on the publishing side of the same pipeline.

The change is most consequential in continuous-integration and build pipelines, where install scripts frequently do real and necessary work. A pipeline that has silently relied on those scripts running automatically may now install cleanly but skip a build step, producing a subtler failure than an outright error. Whether the new default applies inside CI/CD in the same way it does on a developer's laptop is one of the questions not yet fully confirmed, so the prudent move is to validate build pipelines directly against npm 12 rather than assume parity with local behavior.

There is also a defender-side lesson that outlasts this release. The install boundary is only one of several places code can run in a dependency's lifecycle, and npm 12 narrows that boundary without securing the imported module itself. A malicious payload that lives in a package's runtime code — the part that runs when an application imports and uses it — is unaffected by the install-script default. The takeaway is not that the supply chain is now safe, but that one of its most abused automatic paths is closed by default, and the marginal security effort can move toward the parts that remain: dependency review, provenance, and the discipline of not reflexively allowing everything to make a stubborn install succeed.

How yarn, pnpm, and bun May Respond

A default change in npm does not automatically propagate to the rest of the JavaScript tooling ecosystem, and that is a live variable for any team's real-world exposure. Alternative clients — yarn, pnpm, and bun among them — each install packages from the same registry but implement their own handling of lifecycle scripts, and a project's actual exposure to automatic install-time execution depends in part on which client it uses, not only on what npm's default now is. A monorepo standardized on pnpm or a team that has moved to bun for speed will not inherit npm 12's behavior simply because npm shipped it.

Historically, these clients have taken varied stances on install scripts, and some already offer stricter or more configurable handling than npm's traditional default. Whether they now converge on npm's opt-in posture — matching the default so the ecosystem moves together — is not established at the time of the npm 12 release and is worth watching closely. If the alternative clients follow, the practical result is a registry-wide norm in which running install scripts is a deliberate act everywhere; if they diverge, defenders will need to reason about install-time execution per client rather than assuming a single ecosystem default. Either way, the continuation of this thread will play out in the other clients' release notes, and teams that run a mix should treat client choice as part of their supply-chain posture.

Scope and Impact

In scope, the change is precise. It concerns install-time lifecycle scripts — preinstall, install, and postinstall — and turns their automatic execution off by default in npm 12. The immediate population affected is every project and pipeline that installs npm dependencies with the new client and has, until now, relied on those scripts running without intervention. Native-module builds, binary fetches, and setup steps wired into install hooks are the behaviors most likely to notice the change first.

In impact, the release meaningfully raises the bar for the most common class of npm supply-chain incident: the compromised or malicious package that counts on a postinstall script firing the moment it is installed. Removing that automatic trigger blunts a delivery mechanism seen across a long run of registry incidents, from contributor-account compromises to CI/CD-borne campaigns. The impact is bounded, not total — it addresses the install boundary specifically and leaves runtime execution untouched — but the broader effect is normative. By shipping the flip in a major version rather than an option, npm sets a default new projects inherit automatically and existing projects must consciously override, moving the baseline for millions of installs in a direction defenders have long asked for.

Open Questions

Several practical aspects of the rollout are not confirmed at the time of the release and are worth tracking. It is not established whether the new default is opt-in or opt-out for existing installs — that is, whether projects already relying on install scripts continue to run them until they change something, or whether the upgrade itself flips the behavior and requires explicit re-enabling. That distinction determines how disruptive the change is for established projects versus new ones, and teams should confirm it against the npm 12 release notes for their own setup rather than assume either behavior.

It is likewise not confirmed whether the disabled-by-default behavior applies inside CI/CD environments by default in the same way it does locally, nor whether any major CI providers coordinated their default configurations with the npm release. Because pipelines are where install scripts most often do essential work, the CI specifics matter disproportionately, and the safest posture is to validate build pipelines directly against npm 12. A related open question is how the default interacts with private and enterprise registries and whether organizations can centrally manage allow decisions for their developers.

Finally, whether the alternative clients follow remains unresolved. It is not established that yarn, pnpm, or bun will adopt a comparable opt-in default in response to npm 12, and until they do, ecosystem-wide behavior will not be uniform. At disclosure, the reporting rests largely on The Hacker News and npm's release notes; the core fact — that npm 12 disables install scripts by default to reduce supply-chain risk — is clear, while the operational edges around existing installs, CI/CD, and cross-client adoption are the parts most likely to be clarified as the release settles.

The CyberSignal Analysis

The reported facts above are npm's, as relayed by The Hacker News and the release notes; what follows is The CyberSignal's editorial reading of what defenders should take from them. None of the judgments below are new reported facts.

Signal 01 — Changing the Default Is the Point, Not the Mechanism

The mechanism here is modest: install-time scripts move from automatic to opt-in. The significance is in the word default. Opt-in security settings protect the small minority who go looking for them; changed defaults protect everyone who does nothing, which at npm's scale is nearly everyone. Our reading is that the release should be graded as a policy decision about the ecosystem's baseline rather than as a feature, because a default that runs across millions of installs shapes behavior far more than any configurable flag ever could.

That framing also sets the bar for judging whether the change worked. The test is not whether careful teams can now disable install scripts — they always could — but whether the ordinary, unattended install is safer by default than it was the week before. On that measure the answer is yes, and it is the measure that matters.

Signal 02 — This Closes the Install Boundary, Not the Supply Chain

The honest scope of the change is narrower than the headline may suggest, and saying so is a defender's obligation. npm 12 shuts the door that opened on install; it does nothing about the door that opens on use. A malicious payload that lives in a package's runtime code, executing when an application imports and runs it, is untouched by an install-script default. Our assessment is that the most valuable thing defenders can do with this release is internalize that boundary, so they neither over-trust the fix nor dismiss it.

The corollary is where the marginal effort should now go. With the easiest automatic trigger removed, the residual risk concentrates in the parts the default does not reach: the trustworthiness of the dependency itself, the provenance of its releases, and the discipline of the allow decisions teams make when a stubborn install demands scripts. A team that reflexively allows everything to make an install succeed has handed back most of what the default just gave them — which is why we would treat allowlist hygiene as the real work this change creates.

Signal 03 — The Cross-Client Response Is the Thread to Watch

npm changed its own default; the ecosystem it anchors did not automatically change with it. Because yarn, pnpm, and bun install from the same registry but decide independently how to treat lifecycle scripts, a project's true exposure to automatic install-time execution now depends on client choice as much as on npm's default. Our reading is that client selection has quietly become a supply-chain control, and teams that run a mix should account for it explicitly rather than assume npm's decision covers them everywhere.

The forward-looking watch item is convergence. If the alternative clients match npm's opt-in posture, the ecosystem gets a genuine registry-wide norm; if they hold to their own behavior, defenders are left reasoning per client. We would treat the other clients' next release notes as the real continuation of this story — where it becomes clear whether npm 12 marked an ecosystem turning point or only npm's own.

Sources