npm's next major release, v12, scheduled to land July 2026, will stop running dependency install scripts by default.
We’re relieved to hear it. Turning off install scripts is the most useful change npm could make to its defaults. The community suffered a barrage of supply chain attacks in the last year, like Nx s1ngularity and Shai-Hulud, that exploited postinstall scripts. This npm update is a long-awaited change that will shrink a huge supply chain attack vector.
What npm is changing
When you run npm install today, any package anywhere in your dependency tree can define lifecycle scripts called preinstall, install, or postinstall, and npm runs them for you automatically. The code executes the second you install, before you import anything or run your own code.
v12 puts a stop to that. Scripts only run for packages you have put on an allowlist, which you build with npm approve-scripts, block the rest with npm deny-scripts, and commit alongside the rest of your project.
Some other smaller changes ship with it. Git dependencies no longer resolve unless you pass --allow-git, which closes a quieter execution path where a Git dependency's npmrc could override the Git executable and run code even with --ignore-scripts set. Remote-URL dependencies, like https tarballs, also stop resolving unless you pass --allow-remote, closing off a path where an attacker could point a dependency at an external URL they control and swap the payload at any time.
The allowlist also covers code that never shows up in the scripts field. When a package ships a binding.gyp, npm runs an implicit node-gyp rebuild for it during install, so a dependency with a spotless package.json can still execute code just by carrying that one build file. v12 treats that build like a declared script, so it will be blocked unless the package is on your allowlist. Our research team recently mapped out how strange and dangerous this potential attack path is.
All of this is already in npm 11.16.0 behind warnings, so you can see what breaks before you upgrade.
The postinstall exploits that the npm change fixes
Almost every worm and credential stealer that hit npm since last fall ran during install time rather than at runtime. The pattern for these generally involves an attacker first taking over a trusted package, usually by phishing a maintainer's npm account or stealing a publish token. Then the attackers publish a new version with a postinstall script added to its package.json, often leaving the real source untouched, so nothing looks obviously off.
When anyone runs npm install, npm runs that script automatically as the user. It fingerprints the machine, downloads the real payload from an attacker server, runs it, and deletes itself, while the payload scans for tokens, SSH keys, and other goodies, then ships them off
In these attacks, you don’t even have to use the bad package or even import it to become a victim. You just have to be unfortunate enough to run npm install while the package is infected.
With v12's default in place, the install would just stop at the malicious package unless that exact package is on the allowlist you committed. The attacker can still publish the poisoned version, but on a machine with v12, it sits there as inert files in node_modules.
Why this is important
The wave of postinstall script attacks started last fall, and they haven’t really stopped. We saw this attack on a Red Hat package just a week ago. Some of the big attacks that took advantage of this and kept our security researchers up at night include:
- Nx s1ngularity, August 2025. A stolen publish token pushed malicious Nx versions whose postinstall script, telemetry.js, ran on install. It scraped GitHub tokens, npm credentials, SSH keys, and crypto wallets, then uploaded them to public GitHub repos. The roughly 2,300 credentials it harvested seeded future attacks.
- Shai-Hulud, November 2025. A self-replicating worm that hit close to 500 packages across Zapier, ENS, PostHog, Postman, and AsyncAPI, installed the Bun runtime during setup, ran TruffleHog to scrape secrets, and dumped them into public GitHub repos.
- The axios hijack, March 2026. A hijacked maintainer account shipped a dependency that existed only to run a postinstall hook and drop a cross-platform RAT. axios does about 100 million downloads a week.
- Mini Shai-Hulud, May 2026. A spinoff worm of the OG Shai Hulud, planting a preinstall hook that pulled the Bun runtime and ran a credential stealer. It moved through over a hundred packages across TanStack, UiPath, and Mistral AI and became the first npm worm to publish malware carrying valid build provenance.
This is not only an npm problem, although npm is the biggest target. The same idea shows up in other ecosystems, like PHP's Composer, where more than 200 Laravel-Lang versions were rewritten in May to automatically run a credential stealer via the autoloader (Composer now has native malware filtering powered by Aikido to protect downstream users).
What to do now
Upgrade to npm 11.16.0 or later, as all three changes are already there behind warnings. If you’re already on 11.15.0+, --allow-git is available now, and --allow-remote since 11.15.0, so you can start locking those down without waiting for v12. For scripts, run npm approve-scripts --allow-scripts-pending to see what would get blocked, approve the packages you trust, and commit the updated package.json. Whatever you skip stops running when v12 lands. Check this, because plenty of legitimate packages use install scripts for native builds and setup, and once the default flips, those installs need approval.
You can also install Safe Chain by Aikido, a free secure wrapper for npm, npx, and yarn that sits in your current workflow and checks every package for malware before install. It blocks you from accidentally installing malware and enforces a waiting period on new package versions, which prevents a good number of compromised packages from getting on your device.
Good defaults protect the people who never open a changelog (which is almost everyone, almost all the time, except security researchers and the appropriately paranoid). npm making this one safe by default is the right call. It should not have taken a year of public wreckage to happen, and it won’t solve everything, but we’re glad it’s here.
