npm 12 Blocks Install Scripts: Your CI Migration Playbook

npm 12 blocks install scripts by default — and Git dependencies, and remote-URL dependencies. The release landed on July 8, 2026, and it is the sharpest change npm has ever made to what happens when you type npm install: dependencies no longer get to run preinstall, install, or postinstall scripts unless your project explicitly allows them.

The stakes are not theoretical. The postinstall hook was the delivery mechanism for the most damaging npm supply-chain attacks of the past year — from the September 2025 wave of maintainer-account compromises and worm activity to the March 2026 Axios incident and the June 2026 Miasma worm that poisoned packages under Red Hat's official namespace. GitHub's own changelog described the old default as "the single largest code-execution surface" in the npm ecosystem.

This guide covers exactly what changed, which attack techniques the new defaults actually close (and which they don't), the silent-failure trap that can turn a green CI run into a production incident, and a step-by-step migration playbook built around the new npm approve-scripts and npm deny-scripts commands — including the monorepo and Docker gotchas most coverage skips.

The GitHub Changelog pre-announced the breaking changes on June 9, 2026, and v12.0.0 shipped them on July 8. The changelog's own wording is precise: "npm install will no longer execute preinstall, install, or postinstall scripts from dependencies unless they are explicitly allowed," Git dependencies "direct or transitive" will no longer resolve unless allowed via --allow-git, and remote-URL dependencies such as HTTPS tarballs will no longer resolve unless allowed via --allow-remote.

The scale of the trade is what makes the change defensible. Reported estimates circulating with the changelog coverage put the share of npm packages that genuinely need install scripts at roughly 2% — an estimate rather than a registry-wide audit — while under the old model, 100% of packages carried the implicit right to execute code on your machine at install time. Flipping the default converts a universal privilege into a reviewed exception.

The escalation started in September 2025, when a cluster of npm compromises hit in quick succession: a maintainer-account phishing hijack of widely used packages including debug and chalk — packages with combined weekly downloads exceeding 2.6 billion — followed within days by the self-replicating Shai-Hulud worm, which used stolen npm and GitHub tokens to propagate across hundreds of packages. CISA's advisory that week called it a "widespread supply chain compromise impacting npm."

March 31, 2026 brought the Axios incident: malicious versions 1.14.1 and 0.30.4 of a package pulling on the order of 70 to 100 million weekly downloads (the figure varies by source) were live on the registry for roughly a three-hour window. Per Microsoft's incident analysis, the attacker used a compromised maintainer account to publish a malicious dependency, plain-crypto-js, whose postinstall hook silently dropped a cross-platform remote-access trojan. Microsoft tracks the operation as Sapphire Sleet; Google Threat Intelligence attributes the same campaign to UNC1069 — both point to a North Korea state nexus. It followed the same playbook as the LiteLLM supply-chain attack on AI infrastructure earlier in the year: trusted package, install-time execution.

Then came June 2026 and the Miasma worm. A first wave compromised 32 packages under Red Hat's official @redhat-cloud-services namespace; a second wave two days later — documented by Wiz Research on June 4 — hit 57 more packages via the Phantom Gyp binding.gyp technique, all within roughly a two-hour window. The largest single victim was Vapi.ai's official voice-AI server SDK at 408,000+ monthly downloads. The payload harvested credentials across npm, GitHub, AWS, GCP, Azure, HashiCorp Vault, and Kubernetes — and used stolen GitHub Actions OIDC tokens to forge valid provenance attestations, meaning infected versions passed signature checks. Five days after Wiz's writeup, GitHub published the npm 12 breaking-changes announcement.

Most coverage treats npm 12 as a single monolithic fix. It isn't — it is three specific defaults plus one implicit-build closure, and the boundary matters. The matrix below cross-references each attack technique from the 2025-26 wave against the legacy --ignore-scripts escape hatch, the new v12 defaults, the real-world incident that used it, and the migration action it demands. Two vectors stay open, and pretending otherwise is how teams get complacent.

The "still open" rows are not a footnote. The September 2025 chalk/debug hijack shipped malicious runtime code, not an install script — v12's allowlist would not have stopped it. Security-industry reaction to the release names this gap explicitly.

Here is the part that will bite teams who treat the v12 upgrade as routine. Per TechTimes' analysis of the blocking mechanism, when v12 blocks a native module's build script, npm install still completes with exit code 0 and no error. Your CI pipeline goes green. The missing compiled binary only surfaces later — as a runtime "cannot find module" error, in staging if you're lucky, in production if you're not.

The commonly affected packages named in coverage are the ones most production JavaScript stacks quietly depend on: sharp, bcrypt, canvas, sqlite3, fsevents, bufferutil, esbuild, and @tailwindcss/oxide. Browser-automation tools are a second cluster: Puppeteer, Playwright, and Cypress all use postinstall hooks to download full browser binaries. The recommended fix is to call npx playwright install or npx cypress install as an explicit pipeline step rather than relying on the hook.

There's a preview lane, too: all three v12 behaviors are available as advisory, non-blocking warnings starting in npm 11.16.0. Installs still succeed and scripts still run, but the CLI flags every package that v12 would block. Running one 11.16+ install and reading the warnings is the cheapest possible dry run — do it before the major-version bump, not after.

npm ships two new commands for the transition, both managing the allowScripts field of package.json. The sequence that works:

• Audit first. On npm 11.16+, run a normal install and collect the advisory warnings. Then run npm approve-scripts --allow-scripts-pending — a read-only listing of every package whose scripts aren't yet covered by allowScripts, without writing anything.
• Approve deliberately. npm approve-scripts <pkg> writes a version-pinned entry by default (pkg@1.2.3). Pass --no-allow-scripts-pin for a name-only, any-version approval — a wider trust grant you should reserve for packages you'd trust at any version.
• Deny the rest. npm deny-scripts always writes a name-only false entry, never version-pinned. That's a deliberate design choice — as npm's documentation puts it: "Pinning a deny to a specific version would silently re-allow scripts for any other version of the same package, which defeats the purpose; the command picks the safer default for you."
• Verify. Run the native-module smoke test from Section 04, then run your full test suite. A green install proves nothing on its own.

Two scope limits to know: both commands require a project-level package.json and cannot be used with -g global installs or one-off npx runs.

The per-workspace scoping rule is the trap most likely to hit teams running Turborepo or npm workspaces: allowScripts is scoped per workspace, and an approval at the repo root does not propagate to nested packages. Every workspace with native dependencies needs its own npm approve-scripts pass. Combine that with the silent exit-0 failure mode and a Docker multi-stage build — where the install happens in a builder stage nobody watches — and you have a green pipeline shipping an image with missing binaries. Teams on Next.js 16.3 build pipelines should audit both the app workspace and any internal packages that compile native addons.

For CI hardening beyond the upgrade itself, the direction the analyst community is converging on: treat unreviewed install scripts as a build failure, and verify native modules load rather than trusting install exit codes. Wire the approval check and the smoke test into the same pipeline stage — our CI/CD pipeline design reference covers where gates like this belong in a trunk-based flow.

How much work is this in practice? The Node-RED project — a widely used open-source IoT platform — publicly audited its own ecosystem and found 72 packages using install scripts, and was still deciding its migration approach as of mid-June coverage. The breakdown is instructive: the overwhelming majority are postinstall.

One more repeat-offender to schedule for: because approvals are version-pinned by design, every npm update that bumps an approved package invalidates its approval. Build the re-approval step into your dependency-update workflow — whether that's Renovate, Dependabot, or a monthly manual pass — or your first post-update install will silently skip the scripts you thought you had allowed.

The underreported framing: npm 12 is not a bold first move — it is the last major JavaScript package manager to stop granting every dependency implicit install-time execution rights. pnpm shipped the equivalent policy in v10.0.0 on January 10, 2025, roughly 18 months earlier, as a direct response to a supply-chain attack on Rspack that distributed cryptomining malware via an automatic postinstall script, per pnpm maintainer Zoltan Kochan. Yarn Berry and Bun were already blocking by default.

For teams already on pnpm, the v11 mechanics are worth knowing because they mirror where npm just landed: pnpm approve-builds runs interactively without arguments or accepts package names directly, a ! prefix denies a package, and --all (pnpm 10.32.0 and later) auto-approves every pending build. pnpm 11 replaces the legacy onlyBuiltDependencies family with a unified allowBuilds map in pnpm-workspace.yaml.

Read as a trend rather than a release: the JavaScript ecosystem has now fully converged on deny-by-default install-time execution, about a decade after the same shift played out in browser permissions and mobile app sandboxing. What's notable is what forced each mover — pnpm reacted to one cryptominer incident; npm's steward waited until worms were forging provenance attestations under a Red Hat namespace. Defaults in infrastructure this entrenched move only when the cost of the status quo becomes undeniable, and the sequence here — Miasma wave two on June 4, breaking-changes announcement on June 9 — reads as exactly that tipping point.

The operational shift is bigger than one upgrade. Under the old model, dependency trust was a one-time decision made at npm install; under v12, it becomes a reviewed, version-pinned artifact committed to source control — and CI becomes the enforcement point. That's a standing process change, not a checkbox. GitHub, as npm's steward, is making the same bet here that it's making with its agent-native tooling push: defaults, not documentation, are what actually change developer behavior at ecosystem scale.

Looking forward, the projection we'd stake out: install-time attacks don't disappear, they migrate. With the postinstall door closing across all four major package managers, expect attacker effort to concentrate on the two vectors v12 leaves open — maintainer-account takeover delivering malicious runtime code, and typosquatting — plus social-engineering pressure on the approval step itself (packages that "need" scripts for plausible-sounding reasons). The teams that win this next phase are the ones that treat the allowlist as a reviewed security artifact, not a friction to be bulk-approved away.

If your team ships client work on Node-based stacks, budget a real migration window: audit on npm 11.16+, approve per workspace, wire the native-module smoke test into CI, and add re-approval to the dependency-update routine. That's the same hardening-by-default posture we bring to web development engagements, and for organizations rolling this out across many repos and teams at once, our AI transformation practice builds exactly this kind of pipeline-governance automation.