{"id":26205,"date":"2026-09-21T15:15:35","date_gmt":"2026-09-21T23:15:35","guid":{"rendered":"https:\/\/www.palada.net\/index.php\/2026\/09\/21\/update-to-npm-blocks-install-scripts-what-it-means-for-appsec\/"},"modified":"2026-09-21T15:15:35","modified_gmt":"2026-09-21T23:15:35","slug":"update-to-npm-blocks-install-scripts-what-it-means-for-appsec","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2026\/09\/21\/update-to-npm-blocks-install-scripts-what-it-means-for-appsec\/","title":{"rendered":"Update to npm blocks install scripts: What it means for AppSec"},"content":{"rendered":"
\n
\n

A longstanding security deficiency in the popular npm package manager \u2014 having the installation of scripts turned on by default \u2014 will be addressed in the next version of the software, expected to be released in July.<\/p>\n

The change, in version 12 of npm, means the command <\/span>npm-install<\/em><\/span><\/a> 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<\/span><\/a>.<\/p>\n

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.\u00a0<\/p>\n

\u201cFlipping the default forces an explicit decision instead of a silent one.\u201d <\/em>
\u2014<\/em>John Laliberte<\/em><\/span><\/a><\/p>\n

Here\u2019s what you need to know about the npm hardening by Microsoft subsidiary GitHub \u2014 and what it means for the broader problem of software supply chain security.\u00a0<\/p>\n

[ Learn: <\/strong>Why RL Built Spectra Assure Community <\/strong><\/a>| <\/strong>Join for free<\/strong><\/a> ]<\/strong><\/p>\n

How npm\u2019s move takes aim at supply chain worms<\/h2>\n

The move takes on one of the hardest problems in software \u2014 securing how the world distributes and consumes open source code, said Laliberte. \u201cEvery company that ships software pulls from this ecosystem, so improvements here protect everyone downstream,\u201d he said.<\/p>\n

He added, \u201cTurning off arbitrary code execution at install time and making code execution allowlist by default removes one of the adversary\u2019s favorite footholds.\u201d\u00a0<\/p>\n

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<\/span><\/a>.<\/p>\n

\u201cIt 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.\u201d<\/em>
\u2014<\/em>Jacob Krell<\/em><\/span><\/a><\/p>\n

Brett Smith, a software developer at SAS, said turning off install scripts will \u201cstop feeding the worms.\u201d<\/p>\n

\u201cDisabling 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.\u201d<\/em>
\u2014<\/em>Brett Smith<\/em><\/span><\/a><\/p>\n

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.<\/p>\n

\u201cAutomatic 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 \u2014 a version-pinned, auditable record of what runs on install and who approved it.\u201d<\/em>
\u2014<\/em>Collin Hogue-Spears<\/em><\/span><\/a><\/p>\n

However, Waseem Ahmed, head of engineering at Secure.com, said npm\u2019s changes might not fix enough, while giving developers new headaches. He noted that Miasma, in its most recent wave of attacks<\/span><\/a>, for example, has already adapted. \u201cIt 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,\u201d he said.<\/p>\n

\u201c<\/em>The install-time vector is being deprecated by npm at the same moment attackers are already moving past it.\u201d<\/em>
\u2014<\/em>Waseem Ahmed<\/em><\/span><\/a><\/p>\n

Will npm\u2019s new safeguard create developer friction?<\/h2>\n

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.\u00a0<\/p>\n

\u201cPackages 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.\u201d<\/em>
\u2014<\/em>Noelle Murata<\/em><\/span><\/a><\/p>\n

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.<\/p>\n

SAS\u2019s 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. \u201cYou are about to need explicit approval.\u201d<\/p>\n

\u201cI expect approval fatigue to set in quickly, followed by developers writing approval plugins or broad allowlists that completely circumvent the new security feature.\u201d<\/em>
\u2014Brett Smith<\/em><\/p>\n

Suzu Labs\u2019 Krell pointed out that the average npm project carries 79 transitive dependencies. \u201cAuditing install scripts is real work, but teams that blanket-approve scripts will absorb zero security benefit,\u201d he said.<\/p>\n

Black Duck security engineer Boris Cipot said developers will now have to review scripts, maintain allowlists, and adjust CI pipelines. \u201cThat adds friction and slows things down, at least initially,\u201d he said. \u201cIt also shifts responsibility from the ecosystem to the developer, who now must decide what\u2019s safe to run instead of relying on npm defaults.\u201d But that doesn\u2019t mean npm is on the wrong track, he added.<\/p>\n

\u201cThis 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.\u201d<\/em>
\u2014<\/em>Boris Cipot<\/em><\/span><\/a><\/p>\n

What about npm\u2019s broader security strategy?<\/h2>\n

Although turning off install scripts will improve npm security, it won\u2019t eliminate the package manager\u2019s broader security problems. \u201cDisabling scripts does nothing about typosquats you install deliberately and nothing about the maintainer account takeovers that enable attacks like Miasma in the first place,\u201d Secure.com\u2019s Ahmed said.<\/p>\n

\u201cThe Red Hat compromise didn\u2019t require exploiting install scripts at all. The attacker abused npm\u2019s GitHub Actions trusted publishing flow to ship malicious packages carrying valid provenance. That\u2019s an access and trust problem, not an execution problem.\u201d<\/em>
\u2014Waseem Ahmed<\/em><\/p>\n

Ahmed said that the quieter changes in version 12 \u2014 seven-day token lifetimes, mandatory 2FA to publish, and trusted publishing workflows \u2014 matter more in aggregate, because they go after how attackers get in rather than what they can do once they\u2019re inside.<\/p>\n

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. \u201cInstall scripts hit your entire dependency tree automatically. Runtime malware is limited to packages you actually load. The remaining gap is governance.\u201d<\/p>\n

Xcape\u2019s Murata said this action moves the problem without eliminating it.<\/p>\n

“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.”<\/em>
\u2014Noelle Murata<\/p>\n

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 \u2013allow-remote<\/em> and \u2013allow-git<\/em>, have been introduced to close some other dangerous dependency patterns. \u201cAs the proverb says, \u2018The journey of a thousand miles starts with a single step.\u2019 Hopefully this is the right one for npm,\u201d she said.<\/p>\n

Software supply chain security: A work in progress<\/h2>\n

Agnidipta Sarkar, chief evangelist at ColorTokens, said the move acknowledges that the npm ecosystem has become dependent on install scripts. \u201cThe 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,\u201d he said.<\/p>\n

This move is a classic security-versus-compatibility tradeoff, Sarkar said. \u201cThe security risks have been understood for years, but the operational disruption of changing defaults at npm\u2019s scale is enormous.\u201d But, he added, changes on the large language model front make more delays utenable.<\/p>\n

\u201cThis 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.\u201d<\/em>
\u2014Agnidipta Sarkar<\/a><\/p>\n

Tomislav Peri\u010din, 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<\/span><\/a>. To respond, developers and development organizations must back efforts to strengthen both, he said.<\/p>\n

\u201c[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?\u201d<\/em>
\u2014<\/em>Tomislav Peri\u010din<\/em><\/span><\/a><\/p>\n

Traditional vulnerability and secrets scanning is no longer enough, Peri\u010din wrote. A vulnerability might get exploited and give you a headache. With malware, there is no doubt.\u00a0<\/p>\n

\u201c[Shai-Hulud] used it to walk out the front door with all of your secrets \u2014 secrets that it will happily abuse to start another series of attacks.\u201d <\/em>
\u2014Tomislav Peri\u010din<\/em><\/p>\n

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\u010din wrote.\u00a0\u00a0<\/p>\n

Learn about <\/em>ReversingLabs Spectra Assure for builders <\/em><\/a>\u2014\u00a0and how to <\/em>get started with Spectra Assure Community (free)<\/em><\/a> to help you secure your open-source software development.<\/em><\/p>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

A longstanding security deficiency in the popular npm package manager \u2014 having the installation of scripts turned on by default \u2014 will be addressed in the next version of the software, expected to be released in July.The change, in version 12 of npm, meansthe commandnpm-installwill 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<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[32775],"tags":[],"class_list":["post-26205","post","type-post","status-publish","format-standard","hentry","category-reversinglabs"],"_links":{"self":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/26205","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/comments?post=26205"}],"version-history":[{"count":0,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/26205\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/media?parent=26205"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/categories?post=26205"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/tags?post=26205"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}