{"id":8453,"date":"2026-06-11T00:46:50","date_gmt":"2026-06-11T00:46:50","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=8453"},"modified":"2026-06-11T00:46:50","modified_gmt":"2026-06-11T00:46:50","slug":"github-finally-pulls-the-plug-on-automatic-install-script-execution-for-npm","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=8453","title":{"rendered":"GitHub finally pulls the plug on automatic install script execution for npm"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

The ability for attackers to leverage automatic install script execution in npm will finally come to an end when expected changes arrive from GitHub in July. Coders will still be able to enable the function, but the default setting will block it.\u00a0<\/p>\n

In V12, default settings are changing, GitHub said in its changelog<\/a>, noting, \u201cit turns an npm install behavior that runs automatically today into one you explicitly opt into.\u201d\u00a0<\/p>\n

Specifically, the post said, \u201callowScripts defaults to off: npm install will no longer execute preinstall, install or postinstall scripts from dependencies unless they are explicitly allowed in your project. This includes native node-gyp builds; a package with a binding.gyp and no explicit install script still gets blocked, because npm runs an implicit node-gyp rebuild for it. Prepare scripts from git, file, and link dependencies are blocked the same way.\u201d<\/p>\n

Analysts, consultants, and users generally applauded the change, but said that it would only narrow the exposure to supply chain attacks instead of eliminating it.\u00a0<\/p>\n

Attacks likely to move elsewhere<\/h2>\n

Sonu Kapoor<\/a>, maintainer for CVE Lite CLI in the OWASP Incubator Project, said that this change is likely to force the supply chain attacks that leveraged the automatic execution to move elsewhere.<\/p>\n

\u201cThis does not eliminate npm supply chain risk, it removes a major automatic execution path,\u201d Kapoor said. \u201cAttackers can still move to other paths: malicious package code that runs at application runtime, compromised maintainer accounts, dependency confusion, typo-squatting, poisoned GitHub Actions workflows, malicious transitive dependencies, or stolen publishing tokens. This closes one very dangerous door, but it does not secure the whole house.\u201d<\/p>\n

Still, attacks leveraging the setting <\/a>have been regularly used in supply chain attacks.\u00a0<\/p>\n

However Alan Parkinson<\/a>, director of secure medical device firm Threat Detective, said more sophisticated attackers have already moved beyond this hole.\u00a0<\/p>\n

\u201cThe install script attack vector has been known for years,\u201d Parkinson said. \u201cMost security teams marked it as low risk and moved on to higher risk threats. What raised its profile wasn\u2019t the technical exploitability changing, it was a run of high-profile victims and some threat actors openly chasing notoriety.\u201d<\/p>\n

He added, \u201cthe pre and post install scripts was never a clever attack vector to begin with. Running code from an install hook is crude and noisy, which is why it caused such visible damage. The more capable actors are already moving to other methods, so v12 mainly shuts the door on less sophisticated threat actors.\u201d<\/p>\n

Although GitHub declined an interview, Zach Steindler<\/a>, a GitHub principal engineer, answered questions by email.\u00a0He said the volume and pace of supply chain attacks forced the default settings change.\u00a0<\/p>\n

\u201cWe\u2019ve seen attackers target these capabilities to quickly propagate attacks from one compromised package to many. Years of security and usability research have shown that it\u2019s not enough to make secure functionality available; the secure path has to be the default in order for it to be widely adopted,\u201d Steindler said. <\/p>\n

He added, \u201cwe believe that these changes are a great way to provide high impact secure defaults while still providing the option for some users to fall back on functionality they might need in some circumstances.\u201d<\/p>\n

Change overdue<\/h2>\n

Sanchit Vir Gogia<\/a>, chief analyst at Greyhound Research, said that GitHub\u00a0was the last of the repositories to make the setting default change.\u00a0\u201cRivals moved first: Yarn, pnpm and Bun all block third party install scripts by default in their own ways,\u201d Gogia said. \u201cNpm is not inventing a new doctrine. It is finally adopting one.\u201d<\/p>\n

Steindler didn\u2019t dispute Gogia\u2019s comment.\u00a0<\/p>\n

\u201c<\/strong>It\u2019s not easy being the stewards of the largest package repository in the world. Community consensus on what security capabilities should be standard, and when it\u2019s okay to make breaking changes shifts over time. From our continual conversations with the community, it was clear it was time to make this change,\u201d Steindler said. <\/p>\n

\u201cThe recent attacks are alarming,\u201d he noted, \u201cbut stewarding these package repositories is a multi-decade effort, not just a moment in time. As attacks evolve, so will our defensive security capabilities. We\u2019re in this for the long haul.\u201d<\/p>\n

Gogia said that the change, although overdue, is a good one.\u00a0<\/p>\n

\u201cNpm is removing one of the most comfortable hiding places for software supply chain risk: code that executes the moment a developer types install,\u201d Gogia said. \u201cWith npm v12, execution becomes something that must be approved, recorded in the project, and committed for review. That is not a design adjustment. It is a change in control philosophy.\u201d<\/p>\n

Bad defaults become infrastructure<\/h2>\n

Gogia had his own take on why GitHub waited so long.<\/p>\n

\u201cNpm waited because its risky default acquired a constituency. As far back as 2016, npm\u2019s own position was that the convenience of install scripts outweighed the worm risk, with an opt-out flag for the cautious. The trade-off was a documented product decision, not an oversight,\u201d he said. <\/p>\n

\u201cThe trouble with bad defaults is that they become infrastructure,\u201d he added. \u201cNative module builds, browser installers such as Playwright and Cypress, Electron download flows and Husky hooks all grew around automatic execution. Turning it off became less a technical adjustment and more a constitutional reform.\u201d<\/p>\n

Liability changed hands<\/h2>\n

The real pressure for the change, however, came from regulators.<\/p>\n

\u201cThe deeper answer is that the liability changed hands. Once regulation such as the EU Cyber Resilience Act and securities disclosure rules placed supply chain failure on corporate balance sheets, a documented unsafe default became indefensible,\u201d Gogia said.\u00a0<\/p>\n

Kapoor agreed that long-used procedures enabled this security hole to survive longer than it should have.\u00a0<\/p>\n

\u201cThe reason this likely was not done long ago is compatibility,\u201d he said. \u201cInstall scripts are not only used by attackers. Many legitimate packages use them to compile native modules, download platform-specific binaries, generate files, or complete setup steps. Changing the default breaks assumptions that have existed in the npm ecosystem for years. That is why these security changes often arrive slowly. The safer default is obvious from a security perspective, but painful from an ecosystem compatibility perspective.\u201d<\/p>\n

In addition, he noted, \u201cthe bigger point is that package managers are moving from implicit trust to explicit trust. That is the right direction. Developers should have to approve which dependencies are allowed to execute code during install. But approval cannot become a blind checkbox. Teams need visibility into which package wants to run a script, whether it is direct or transitive, why it is there, and whether it belongs in the project at all.\u201d<\/p>\n

Kapoor added that this change matters because install-time execution often happens in privileged environments with access to tokens, secrets, internal registries, build artifacts, or deployment paths. \u201cEven if the script does not compromise production directly, it may be able to steal enough context to support the next stage of an attack,\u201d he said.<\/p>\n

Value in the pain<\/h2>\n

Cybersecurity consultant Brian Levine<\/a>, executive director of FormerGov, agreed that the closing of this security hole is a very good thing.\u00a0<\/p>\n

\u201cIt seems like virtually every major supply chain attack of the last decade has had the same original sin: code that ran automatically because the ecosystem let it. Npm finally closing that door by default is overdue, but it\u2019s genuinely significant. This is the package manager for hundreds of billions of downloads a month,\u201d Levine said. <\/p>\n

\u201cWhen npm changes its defaults, it changes the security posture of practically every enterprise dev environment on the planet. It may have been the last large code repository to still allow this kind of automated execution.\u201d<\/p>\n

Levine added that this change might not merely stop a security hole, but the new process may meaningfully improve security.\u00a0<\/p>\n

\u201cThere\u2019s actually something valuable buried in this migration pain. Having developers explicitly approve which packages can run code and commit that list to source control is a form of software supply chain governance that many organizations never had,\u201d Levine said. \u201cIt creates an auditable record which is meaningful, especially for regulated industries.\u201d<\/p>\n

This article originally appeared on InfoWorld<\/a>.<\/em><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

The ability for attackers to leverage automatic install script execution in npm will finally come to an end when expected changes arrive from GitHub in July. Coders will still be able to enable the function, but the default setting will block it.\u00a0 In V12, default settings are changing, GitHub said in its changelog, noting, \u201cit […]<\/p>\n","protected":false},"author":0,"featured_media":8454,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-8453","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/8453"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=8453"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/8453\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/8454"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=8453"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=8453"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=8453"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}