npm v12 ships this month, and it changes a default behaviour that has existed since the package manager’s creation: running a package’s preinstall, install, or postinstall scripts automatically the moment it is added to a project. From v12 onward, those scripts will not run unless a project explicitly allows them. The same applies to Git dependencies, which will require an explicit --allow-git flag, and to remote tarball URLs, which need --allow-remote. GitHub, which maintains npm, is calling it the most significant security redesign in the registry’s 16-year history.
The attack pattern this closes
Install scripts have been the mechanism behind a long list of supply chain incidents over the past year, including the Miasma campaign that compromised more than 57 npm packages, the AntV attack that republished 639 malicious package versions in about an hour, and the Mastra AI compromise where a single stolen developer account was used to push malware to over 140 packages in roughly 19 minutes. In each case, the attacker’s payload ran automatically the moment a developer or a CI pipeline ran npm install, no further action required. Blocking scripts by default removes the single most reliable delivery mechanism these campaigns have relied on.
The Git dependency change closes a related path: a malicious Git dependency’s own .npmrc file could previously override which Git executable was used, achieving code execution even when a project had --ignore-scripts set. Remote URL resolution gets the same treatment, since a tarball fetched directly from a URL bypasses registry-level scanning entirely.
Why this will break builds that look fine today
npm 11.16.0 already surfaces warnings for behaviour that v12 will block outright, but warnings are easy to miss in CI logs that nobody reads until something breaks. Native builds are a particular trap: a package with a binding.gyp file and no explicit install script still triggers an implicit node-gyp rebuild today, and that rebuild will be blocked under v12 just like an explicit script would be. Teams that have not reviewed their dependency tree for packages relying on install-time compilation, Git sources, or remote tarballs will discover the gap as a silent build failure with exit code 0, not a clear error message pointing at the cause.
What European engineering teams should do now
Audit your package.json and lockfiles for dependencies using install scripts, Git URLs, or remote tarball sources, and decide deliberately which ones genuinely need to keep running rather than allowing all of them by default once v12 lands. Test your CI/CD pipelines against npm 11.16.0 with the new warnings enabled before the upgrade forces the issue, and document which packages get an explicit allow flag and why, since that list is itself useful security documentation for anyone auditing your build process later.
If your CI/CD pipelines rely on packages that use install scripts and you need help auditing your dependency tree before npm v12 lands, or want a broader review of your software supply chain security, contact Excello Digital. We help European engineering teams keep their build pipelines running through changes like this one without last-minute surprises.