npm v12 blocks install scripts: What it means for software security

A longstanding security deficiency in the popular npm package manager — having the installation of scripts turned on by default — will be addressed in the next version of the software, expected to be released in July.

The change, in version 12 of npm, means the command npm-install will no longer execute preinstall, install, or postinstall scripts from dependencies unless they are explicitly allowed in a project, the npm team explained in a GitHub blog.

For years, a single compromised package could run whatever the adversary wanted the moment a developer or build system installed that package, said John Laliberte, CEO of ClearVector. 

“Flipping the default forces an explicit decision instead of a silent one.”
—John Laliberte

Here’s what you need to know about the npm hardening by Microsoft subsidiary GitHub — and what it means for the broader problem of software supply chain security. 

[ Learn: Why RL Built Spectra Assure Community | Join for free ]

How npm’s move takes aim at supply chain worms

The move takes on one of the hardest problems in software — securing how the world distributes and consumes open source code, said Laliberte. “Every company that ships software pulls from this ecosystem, so improvements here protect everyone downstream,” he said.

He added, “Turning off arbitrary code execution at install time and making code execution allowlist by default removes one of the adversary’s favorite footholds.” 

Jacob Krell, senior director for secure AI solutions and cybersecurity at Suzu Labs, said the move is targeted at the recent rise of worm-based supply chain attacks.

“It shuts down the execution path every major npm supply chain worm has used in the past year. Shai-Hulud, Mini Shai-Hulud, and Miasma all spread through preinstall or postinstall scripts that fire automatically during installation. Version 12 blocks those by default.”
—Jacob Krell

Brett Smith, a software developer at SAS, said turning off install scripts will “stop feeding the worms.”

“Disabling install scripts by default should make npm install considerably safer by stopping random code executions that are often leveraged for nefarious acts in the main package and its potentially malicious transitive dependencies.”
—Brett Smith

Version 12 of npm changes the most dangerous default in the JavaScript ecosystem, said Collin Hogue-Spears, senior director of solution management at Black Duck Software.

“Automatic install scripts let Shai-Hulud and the Nx compromise turn one poisoned package into many in hours, running with the CI credentials and publishing tokens that fueled the next round. Version 12 severs retrieval from execution and leaves behind a committed allowlist in package.json — a version-pinned, auditable record of what runs on install and who approved it.”
—Collin Hogue-Spears

However, Waseem Ahmed, head of engineering at Secure.com, said npm’s changes might not fix enough, while giving developers new headaches. He noted that Miasma, in its most recent wave of attacks, for example, has already adapted. “It now injects persistent backdoors directly into AI coding assistant configuration files, including developer IDE settings and GitHub Actions workflows, re-executing the payload every time a developer opens the project,” he said.

“The install-time vector is being deprecated by npm at the same moment attackers are already moving past it.”
—Waseem Ahmed

Will npm’s new safeguard create developer friction?

Noelle Murata, a senior security engineer at Xcape, explained the concern about deprecating the install-time vector. While turning off install scripts by default has security benefits, it can create some challenges for developers. Legitimate software packages that have relied on this feature will break, she said. 

“Packages that require platform-specific binaries in order to function locally will fail. There will be approval fatigue, so humans will be compelled to either just click though the prompts or bypass them entirely, [using] the command-line option to approve all.”
—Noelle Murata

Real packages will look like malware, as authors will move to using installation methods that bypass the npm restrictions, she added. And defenders will have a harder time distinguishing signal from noise, since there will be less distinction in behavior from so-called good and bad software installations.

SAS’s Smith said that disabling install scripts by default will break a significant amount of legitimate software that depends on arbitrary code execution scripts for native module compilation, binary downloads, and configuration. Node-gyp, esbuild, Sharp, Puppeteer, and many other tools run at install time, he said. “You are about to need explicit approval.”

“I expect approval fatigue to set in quickly, followed by developers writing approval plugins or broad allowlists that completely circumvent the new security feature.”
—Brett Smith

Suzu Labs’ Krell pointed out that the average npm project carries 79 transitive dependencies. “Auditing install scripts is real work, but teams that blanket-approve scripts will absorb zero security benefit,” he said.

Black Duck security engineer Boris Cipot said developers will now have to review scripts, maintain allowlists, and adjust CI pipelines. “That adds friction and slows things down, at least initially,” he said. “It also shifts responsibility from the ecosystem to the developer, who now must decide what’s safe to run instead of relying on npm defaults.” But that doesn’t mean npm is on the wrong track, he added.

“This improves security, but it definitely makes the developer experience worse in the short term. But there has always been, and will always be, a trade-off between security and comfort.”
—Boris Cipot

What about npm’s broader security strategy?

Although turning off install scripts will improve npm security, it won’t eliminate the package manager’s broader security problems. “Disabling scripts does nothing about typosquats you install deliberately and nothing about the maintainer account takeovers that enable attacks like Miasma in the first place,” Secure.com’s Ahmed said.

“The Red Hat compromise didn’t require exploiting install scripts at all. The attacker abused npm’s GitHub Actions trusted publishing flow to ship malicious packages carrying valid provenance. That’s an access and trust problem, not an execution problem.”
—Waseem Ahmed

Ahmed said that the quieter changes in version 12 — seven-day token lifetimes, mandatory 2FA to publish, and trusted publishing workflows — matter more in aggregate, because they go after how attackers get in rather than what they can do once they’re inside.

Krell, while noting that npm version 12 closes the install-hook path, added that malicious code can move to the module body and fire at runtime when an application loads it. “Install scripts hit your entire dependency tree automatically. Runtime malware is limited to packages you actually load. The remaining gap is governance.”

Xcape’s Murata said this action moves the problem without eliminating it.

"Malware will still be deployed via packages. [While] npm may still be involved, software supply chain risk mitigations must be approached with a defense-in-depth mindset."
—Noelle Murata

A more comprehensive approach would be to use install-time cool-downs and package firewalls, Murata said. And work with development teams is needed, to analyze dependency trees and prioritize security issues. Murata said that new flags, such as –allow-remote and –allow-git, have been introduced to close some other dangerous dependency patterns. “As the proverb says, ‘The journey of a thousand miles starts with a single step.’ Hopefully this is the right one for npm,” she said.

Software supply chain security: A work in progress

Agnidipta Sarkar, chief evangelist at ColorTokens, said the move acknowledges that the npm ecosystem has become dependent on install scripts. “The industry has effectively accumulated supply chain technical debt, and npm is only now in a position to begin paying it down. Changing the default behavior risks breaking applications, build systems, and developer workflows across the industry,” he said.

This move is a classic security-versus-compatibility tradeoff, Sarkar said. “The security risks have been understood for years, but the operational disruption of changing defaults at npm’s scale is enormous.” But, he added, changes on the large language model front make more delays utenable.

“This is the right time to do it. Post Mythos, such risks must be eliminated, else the CISO, the CIO, and the CEO risk their jobs and reputation.”
—Agnidipta Sarkar

Tomislav Peričin, chief software architect and co-founder of ReversingLabs, wrote about the original Shai-Hulud worm attack that it underscored the importance of transparency and integrity across open-source ecosystems, dependencies, and CI/CD pipelines. To respond, developers and development organizations must back efforts to strengthen both, he said.

“[Unless] something changes, another worm is inevitable, and the only unknown is when. The question now is: How do we protect DevOps infrastructure against such inevitable threats?”
—Tomislav Peričin

Traditional vulnerability and secrets scanning is no longer enough, Peričin wrote. A vulnerability might get exploited and give you a headache. With malware, there is no doubt. 

“[Shai-Hulud] used it to walk out the front door with all of your secrets — secrets that it will happily abuse to start another series of attacks.”
—Tomislav Peričin

The software supply chain is complex and requires augmentation of traditional security checks with more nuanced, behavioral-based detection that can spot malicious code and other anomalies, Peričin wrote.  

Learn about ReversingLabs Spectra Assure for builders — and how to get started with Spectra Assure Community (free) to help you secure your open-source software development.