Notifications
Clear all
Topic starter
02/08/2026 11:27 am
TL;DR: npm v12 will stop running dependency install scripts by default, closing a major supply chain attack path that recent worms and credential stealers repeatedly abused, according to Aikido. The change matters because package install remains a trust boundary, and allowlist-based execution is now the safer default for modern software supply chains.
NHIMG editorial — based on content published by Aikido: npm v12 delivers one of the biggest security improvements in years
By the numbers:
- Shai-Hulud hit close to 500 packages across Zapier, ENS, PostHog, Postman, and AsyncAPI.
- axios does about 100 million downloads a week.
Questions worth separating out
Q: How should teams control dependency install scripts in modern pipelines?
A: Teams should move from blanket execution to explicit approval.
Q: Why do postinstall attacks so often lead to secret theft?
A: Because install-time code runs in a privileged environment that already has access to developer tokens, build credentials, and repository secrets.
Q: What breaks when organisations rely on default package manager behaviour?
A: Default behaviour assumes dependency authors are trustworthy enough to execute code during installation.
Practitioner guidance
- Build an install allowlist and enforce it in CI Approve only the packages that truly need lifecycle execution, commit the allowlist with the repository, and fail builds when a new dependency tries to run code outside that boundary.
- Isolate build identities from reusable secrets Use short-lived tokens, narrow scopes, and separate CI credentials so a compromised dependency cannot reach the same identities used for source control, registry access, or cloud operations.
- Review alternate execution paths beyond postinstall Audit git dependencies, remote tarballs, and implicit native rebuilds separately, because attackers often route around the most obvious script controls.
What's in the full article
Aikido's full post covers the operational detail this post intentionally leaves for the source:
- Exact npm v12 behaviour changes for lifecycle scripts, git dependencies, and remote-URL packages.
- Step-by-step approval workflow for packages that legitimately need native builds or setup scripts.
- Practical upgrade guidance for teams still on npm 11.15.0 or earlier.
- Reference to Aikido's Safe Chain wrapper for pre-install malware checks and waiting periods.
👉 Read Aikido's analysis of npm v12 and install-time supply chain attacks →
npm v12 and postinstall scripts: what changes for security teams?
Explore further
02/08/2026 12:43 pm
Install-time execution is now a supply chain control problem, not a package hygiene problem. The core failure mode is blanket trust in dependency lifecycle hooks. Once execution happens before import, the attacker controls the earliest and most privileged moment in the build path. Security teams should treat install policies as part of software access governance, because package execution can become identity compromise within one build cycle.
A question worth separating out:
Q: How should security teams respond when a build may have run malicious dependency code?
A: Treat it as a potential credential incident, not just a software issue. Revoke exposed tokens, rotate any secrets available to the build host, inspect package provenance, and review source control and registry activity for follow-on abuse. Build compromise often becomes identity compromise very quickly.
👉 Read our full editorial: npm v12 makes install-time supply chain attacks harder to execute
