npm 12 Blocks Install Scripts by Default to Stop Supply-Chain Attacks

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Secure delivery pipelines and platform hardening for US and EU teams

The short answer

What did GitHub actually change?

On 8 July 2026, Microsoft-owned GitHub used the npm changelog to announce npm 12, the next major release of the package manager that sits under most of the JavaScript and Node.js ecosystem. The headline is that three defaults that have been permissive since npm's early days are being turned off.

First, lifecycle install scripts are blocked. The preinstall, install and postinstall hooks — and native C/C++ build steps — will no longer run automatically during npm install. Second, Git-URL dependencies are blocked, closing a route attackers used to sidestep script restrictions through custom Git resolution. Third, remote HTTP and tarball dependencies are forbidden unless a project explicitly permits them. Each behaviour can still be re-enabled, but only deliberately and per project.

To manage the transition, npm ships a new npm approve-scripts command. It audits which of your dependencies want to run install scripts, lets you review them, and writes the approved set into package.json as an allowlist you commit to source control. GitHub is also tightening authentication around this release: granular access tokens configured to bypass two-factor auth lose their ability to perform sensitive package operations in early August 2026, and from January 2027 token-based publishing is limited to staging, with public release requiring human 2FA approval. Developers can start testing the new behaviour today by moving to npm 11.16.0 or newer.

Why block install scripts now?

Because install scripts are where the damage happened. A lifecycle script runs arbitrary code the instant a package is installed — before a single line of that package is ever imported or called by your application. That makes it the perfect payload trigger: compromise a popular package, add a malicious postinstall, and every npm install in every CI job downstream executes your code automatically.

2026 made the risk concrete. In July, multiple versions of the jscrambler npm package and its plugins were hijacked in a coordinated supply-chain attack. On 14 July 2026, Microsoft Threat Intelligence reported that attackers had compromised the release pipelines of core AsyncAPI repositories and published trojanised packages to npm. Those followed state-sponsored campaigns earlier in the year that slipped malicious code into widely used libraries. In nearly every case, the automatic execution of install scripts was the mechanism that turned a poisoned package into running code on developer machines and build servers. Turning that default off removes the single most reliable path attackers had.

Will npm 12 break your builds?

Honestly, some of them — and that is the point. Any dependency that compiles native modules or performs real setup work in a postinstall hook will stop working until you approve it. If your team upgrades blind, the first symptom is a red CI pipeline the day the default changes.

The mitigation is straightforward but must be done deliberately. Run npm approve-scripts on a branch, in CI, and read what it surfaces: it is a rare, itemised list of every dependency that wants to execute code at install time. Approve only what genuinely needs it, commit the allowlist, and you have both a working build and a documented, reviewable inventory of your riskiest packages. The failure mode security researchers warn about is the lazy one — developers blind-approving every blocked script just to make the build green, which hands attackers cover under the noise of legitimate approvals. The value of npm 12 is realised only if approval is treated as a genuine review step, ideally reinforced by security audits of your dependency supply chain.

What it means for US & EU software teams

The first lesson is that secure-by-default has finally reached the install step. For years the advice — use --ignore-scripts, vet dependencies, pin lockfiles — lived in security checklists that most teams skipped. npm 12 makes the safe choice the automatic one. If you run any Node.js service, that is a material reduction in the blast radius of a poisoned dependency, achieved without a line of application code.

The second lesson is that this is a migration, not a free upgrade. Treat npm 12 like any breaking platform change: test it on a branch, update your CI base images and internal onboarding docs, and audit the Git-URL and remote-tarball dependencies you may not even remember adding. In regulated sectors such as FinTech, a reviewed install-script allowlist committed to source control is also useful evidence — it demonstrates deliberate control over third-party code execution, which maps directly to SOC 2, DORA and NIS2 expectations around software supply-chain integrity.

The third lesson is that one layer is not a strategy. npm 12 closes the install-time execution path, but researchers are already pointing at the next move: import-time payloads that run when a module is required rather than installed, and the human weakness of rubber-stamped allowlists. Keep the rest of the stack — lockfile discipline, provenance and signing checks, dependency review, and runtime monitoring — in place. Defence in depth is what turns a single strong default into durable security.

What to do this quarter

Treat npm 12 as a scheduled migration with a security upside, not a surprise.

1. Move to npm 11.16.0 or newer now. It lets you exercise the new defaults before they become mandatory, so you find breakage on your schedule, not the ecosystem's.
2. Run npm approve-scripts and read every entry. Build the allowlist deliberately, approving only dependencies that genuinely need install scripts, and commit it to source control.
3. Audit Git and remote dependencies. Find any Git-URL or HTTP-tarball dependencies in your tree and replace or explicitly allow them before builds break.
4. Update CI images and docs. Bump the npm version in your pipelines and container images, and document the new approval flow so new engineers do not blind-approve their way around it.
5. Tighten publishing tokens. Review granular access tokens ahead of the August 2026 change; remove 2FA-bypass tokens and prepare for human-approved publishing in 2027.
6. Keep the other layers on. Pair the new defaults with lockfile pinning, provenance checks and dependency review so a single control failure is never fatal.

None of this eliminates supply-chain risk on its own, and one release will not end npm's run of incidents. But the direction is unambiguous: the ecosystem is shifting the cost of a poisoned package from “runs automatically on everyone” to “runs only where a human said yes.” Upgrade deliberately, review what you approve, and keep the rest of your defences in place.

Frequently asked questions

Sources

The Hacker News — npm 12 Disables Install Scripts by Default to Reduce Supply Chain Risk
Infosecurity Magazine — GitHub to Update npm to Thwart Software Supply Chain Attacks
Cybernews — npm v12 security overhaul: experts weigh in