Notifications
Clear all
Topic starter
02/08/2026 11:25 am
TL;DR: npm is changing default behaviour so dependency install scripts no longer run automatically, closing a long-used supply chain attack path that let compromised packages execute code during install, according to Semgrep. The real lesson is that trusted package execution should be explicit, not inherited from the dependency tree.
NHIMG editorial — based on content published by Semgrep: npm removes default script execution and changes the package supply chain trust model
By the numbers:
- axios is used in roughly 80% of cloud and code environments with approximately 83 million weekly downloads.
- the first compromise hit an endpoint 89 seconds after publication
- around 2.2% of npm packages actually use install scripts
Questions worth separating out
Q: What breaks when dependency install scripts are disabled by default?
A: Packages that rely on install-time compilation or setup, such as native addons or binary downloaders, may need explicit approval or alternate build paths.
Q: Why do install scripts create such a large supply chain risk?
A: They turn package installation into code execution, often inside environments that contain secrets and elevated build privileges.
Q: What do security teams get wrong about dependency scanning?
A: They often assume a clean manifest means a clean environment.
Practitioner guidance
- Block automatic dependency script execution Default to disallowing preinstall, install, and postinstall scripts in dependency installs, then allow only the packages that have a documented operational need for build-time code execution.
- Separate install environments from secret-bearing environments Reduce the number of secrets present during package installation by using short-lived credentials, isolated build identities, and environment-specific token scoping.
- Inventory transitive packages that request scripts Review dependency trees for packages that use lifecycle hooks, especially transitive dependencies that were never explicitly approved.
What's in the full article
Semgrep's full article covers the operational detail this post intentionally leaves for the source:
- A closer walkthrough of npm v12 defaults and which script paths are blocked by allowScripts, allow-git, and allow-remote.
- Examples of legitimate lifecycle-script use cases such as native addons and binary downloads, useful when deciding what to allowlist.
- The attack patterns behind Axios, Shai-Hulud, and similar package compromise campaigns that used install-time execution.
- Practical comparison points across npm, pnpm, Bun, and Yarn for teams standardising package policy.
👉 Read Semgrep's analysis of npm's default script execution change →
npm script execution is changing, but what does that mean for teams?
Explore further
02/08/2026 12:42 pm
Default script execution was the real governance failure, not just malicious packages. npm’s previous model assumed that third-party install scripts could be trusted unless proven otherwise. That assumption collapsed because package managers distribute code across highly privileged environments that often contain secrets. The control failure is the default, not the exception, and that is why blocking automatic execution changes the governance baseline for the entire ecosystem.
A question worth separating out:
Q: How should organisations respond when package installs can access secrets?
A: They should treat package installation as a privileged workflow and remove secrets that are not required for build or install. Use short-lived credentials, tighter environment segmentation, and script allowlists so install-time code cannot read more than it needs. That reduces the blast radius if a dependency is compromised.
👉 Read our full editorial: npm removes default script execution: supply chain risk shifts left
