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.
At a glance
What this is: npm v12 changes install-time execution so dependency scripts no longer run by default, reducing the chance that poisoned packages can execute during installation.
Why it matters: This matters because package install is a trust boundary for software supply chains, and security teams need to control when third-party code can execute in build and developer environments.
Context
Install-time execution is the problem here: dependency code can run before a developer imports anything or a build pipeline completes. In npm today, lifecycle scripts and certain dependency paths can turn package installation into code execution, which makes the package manager itself part of the attack surface.
That matters for software supply chain governance because poisoned packages often target the moment of trust, not runtime application logic. For identity and access teams, the intersection is clear: attacker-chosen install paths routinely steal tokens, SSH keys, and other secrets from developer and CI environments.
The article’s starting position is not unusual. Install hooks have been a long-standing abuse path across open-source ecosystems, and npm v12 is responding to a pattern security teams already know from recent worm and credential-theft campaigns.
Key questions
Q: What breaks when npm dependencies can execute install scripts automatically?
A: Install-time scripts turn a dependency into active code, so package presence is no longer the same as package safety. A malicious dependency can run before scanners or review processes notice it, which means the control point shifts from manifest review to execution governance and runtime monitoring.
Q: When should teams prioritise allowlisting over script blocking alone?
A: Teams should prioritise allowlisting when packages legitimately need install-time execution, because the real decision is not whether scripts exist but which packages are trusted to run them. A positive approval model is more durable than a pure blocklist when ecosystems rely on native builds, Git dependencies, or remote artifacts.
Q: What are the signs that install-time package trust is failing?
A: Common warning signs include unexpected lifecycle activity, packages that execute during install without a clear operational need, unreviewed Git or remote dependencies, and secret exposure from build or developer environments after a new version is published. Those are the signals that dependency trust has become too broad.
Q: What should teams do when a malicious package has already been installed on developer machines?
A: Isolate affected systems, identify every machine that installed the package, and remove the dependency from build paths and caches. Then hunt for follow on downloads, temporary files, suspicious Python processes, and outbound requests to the attacker infrastructure. Rebuild affected environments from trusted sources, rotate any credentials exposed on those systems, and add detections for the package name and its indicators of compromise.
Technical breakdown
Why install-time scripts are a supply chain execution boundary
npm lifecycle hooks such as preinstall, install, and postinstall execute during package installation, before an application ever runs. That makes the package manager an execution environment, not just a dependency fetcher. Attackers exploit that by slipping malicious code into a package update or a compromised maintainer account, then waiting for install events to trigger payload delivery. The risk is amplified because the victim does not need to import the package for code to run. In practice, that means build systems, developer laptops, and CI runners all become execution targets whenever they resolve infected dependencies.
Practical implication: Treat package installation as code execution and gate it with allowlists, review, and monitoring.
How npm v12 narrows hidden execution paths
The default change matters because it moves from implicit execution to explicit approval. npm v12 blocks lifecycle scripts unless a package is on an allowlist, and it also gates other execution-adjacent paths such as Git dependencies, remote-URL dependencies, and implicit node-gyp rebuilds triggered by binding.gyp. Those mechanisms are different on the surface, but they share the same governance issue: unreviewed third-party content can still execute code during install. Blocking them by default reduces the number of places where malicious code can hide behind normal dependency management.
Practical implication: Review non-script install paths separately, especially Git, remote tarballs, and native-build dependencies.
Why allowlists are now the safer default for package trust
An allowlist is not just a blocklist with a nicer name. In supply chain terms, it creates a positive approval model where known packages are permitted to execute and everything else remains inert. That is especially important in ecosystems where maintainers can be phished, publish tokens can be stolen, and attackers can update a trusted package without changing obvious source files. npm 11.16.0 already exposes the new behavior behind warnings, which gives teams a transition window. The underlying security pattern is simple: the less you execute by default, the smaller the blast radius when a package is compromised.
Practical implication: Use the warning period to inventory legitimate install scripts and convert them into explicit approvals.
Threat narrative
Attacker objective: The attacker wants silent code execution during installation so they can harvest credentials, pivot through developer or CI environments, and seed follow-on compromise.
- Entry occurs when an attacker compromises a maintainer account or steals a publish token for a trusted package.
- Credential abuse follows when the attacker publishes a poisoned version that adds a postinstall or similar install-time hook.
- Impact occurs when npm install executes the malicious payload and the malware steals tokens, SSH keys, or other secrets from the machine.
Breaches seen in the wild
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Install-time execution is now a governance problem, not just a build convenience issue. Package managers that run third-party code by default turn dependency resolution into a trusted execution boundary, which is exactly where supply chain attackers want the control gap to live. The practical lesson is that package install must be treated as an approval event, not an automatic one.
Allowlisting is the right security primitive for this class of risk. A deny-by-default model limits what can execute before code reaches runtime, which is where defenders typically have better monitoring. For organisations with CI/CD runners and developer fleets, this is an NHI-adjacent control issue because the credentials most often stolen here belong to machines, build agents, and service workflows, not end users.
Postinstall abuse exposed a standing trust assumption that no longer holds. Many teams assumed package metadata and source visibility were enough to judge safety, but attackers repeatedly hid payloads in lifecycle hooks, native build files, and alternate dependency paths. The new default validates that execution control belongs at install time, and practitioners should re-evaluate every place where third-party code can run without explicit approval.
Supply chain hardening is shifting from detection after compromise to pre-execution restraint. That is a useful signal for the market because it favours explicit trust, provenance checks, and dependency governance over reactive malware hunting alone. Teams that still rely on post hoc secret detection are protecting the wrong layer of the problem.
CI/CD runners are becoming a primary identity surface in supply chain attacks. The article’s examples show that the most valuable target is often the machine identity that can install packages, reach internal systems, and exfiltrate secrets. Practitioners should govern those identities as high-risk execution principals, not as ordinary build infrastructure.
From our research library:
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
Install-time controls are becoming a first-class supply chain boundary. The important shift is not just that scripts are blocked by default, but that dependency execution is moving from implicit behaviour to explicit governance. That is the right pattern for ecosystems where third-party packages can reach developer laptops and CI runners with machine credentials attached.
CI/CD runner identity is now part of package trust. When package managers execute code during install, the runner is no longer a passive tool. It becomes a high-value machine identity that can be abused to fetch secrets, reach internal services, and propagate compromise if its permissions are broader than the build truly needs.
For practitioners
- Inventory all install-time execution paths Catalog lifecycle scripts, Git dependencies, remote tarballs, and native build triggers across your repositories and build pipelines so you know where code can still run during install.
- Move package execution to explicit approval Adopt allowlists for packages that are permitted to run scripts, and require teams to justify every approved dependency that executes during installation.
- Test npm 11.16.0 warnings before upgrading Use the warning period to identify what will break when scripts stop running by default, then fix or approve only the dependencies that genuinely need execution.
- Harden developer and CI secrets exposure Assume install-time malware will look for tokens, SSH keys, and cloud credentials, then reduce what those environments can access by default.
- Review third-party package trust separately from source review Do not assume a clean repository means safe execution, because an attacker can preserve visible source while abusing lifecycle hooks and implicit build behavior.
Key takeaways
- Install-time execution remains the core weakness in software supply chains because it lets a poisoned package run before anyone imports it or reviews runtime behaviour.
- The change in npm v12 matters because it replaces automatic script execution with explicit approval, which reduces the attack surface for credential theft and malware delivery.
- Security teams should inventory every path that can execute during package installation and treat build and developer machine identities as high-risk access points.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Install-time malware in the article steals tokens, SSH keys, and other secrets from build environments. |
| NHI-07 — Long-Lived Secrets | The article shows why exposed build and publish tokens remain dangerous when install-time code can steal them. | |
| Recommendation — Scan install paths for secret-harvesting malware and revoke any credentials exposed during package execution. Replace long-lived publish and build secrets with shorter-lived credentials and stronger rotation controls. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The attack pattern centers on stealing credentials and shipping them out during package installation. |
| Recommendation — Map install-time malware to credential access and exfiltration tactics so detection hunts include package-manager abuse. | ||
| CIS Controls v8 | CIS-5 — Account Management | Maintainer account compromise and token theft are central entry points in the incidents cited by the article. |
| Recommendation — Harden account and token lifecycle controls for package publishers and build systems to reduce impersonation risk. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about restricting which code is allowed to execute during software installation. |
| Recommendation — Limit install-time permissions so only explicitly approved packages can execute during dependency resolution. | ||
Key terms
- Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
- Lifecycle Script: A lifecycle script is code that runs automatically during package installation or build steps, such as preinstall or postinstall hooks. These scripts are useful for legitimate automation but create a high-risk execution path because they can run before developers fully inspect the package.
- Allowlist: An allowlist is a controlled set of approved origins, methods, or headers that are permitted to interact with a resource. In CORS, it is the practical mechanism that prevents accidental openness while still allowing deliberate cross-origin access when the business need is valid.
- Publish token: A credential that authorises a package maintainer or automation process to publish or overwrite software artefacts. In identity terms, it is a high-value non-human credential with direct supply chain impact, so it needs rotation, scope limitation, and strict lifecycle ownership.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect identity control to the wider supply chain risks their programmes already face.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org