Because the payload runs before the developer starts the application, it can reach environment-resident secrets such as cloud credentials, CI tokens, and SSH keys. That makes the installation step a credential exposure window, especially on build hosts and developer workstations where secrets are already present.
Why install-time payloads are dangerous before the app ever starts
Install-time code in npm runs during dependency installation, not after the application has entered a controlled runtime. That timing matters because package managers, build scripts, and CI jobs often execute with access to developer and pipeline context that includes cached credentials, tokens, and environment variables. In other words, the attacker does not need to wait for your app to make a risky API call, because the installer itself becomes the execution point.
For a secret stealer, the installation phase is attractive because it is usually trusted, automated, and noisy only after the damage is done. The payload can read process environment values, inspect local files, query CLI helpers, and reach material that would never be present in a minimal runtime container. This is why install hooks are especially effective on developer workstations, shared build hosts, and self-hosted runners.
In package ecosystems, that creates a large blast radius. A single malicious dependency can execute on many machines with different secret stores, and the same package may be installed repeatedly across branches, environments, and teams. When that payload lands inside a poisoned package path, the exposure is not limited to source code; it can include cloud credentials, CI tokens, signing keys, and SSH material already available to the installation process. The same class of abuse shows up in Shai Hulud npm malware campaign, where malicious packages were used to expose secrets from real build and developer environments.
What makes install-time access different from ordinary application compromise
Ordinary application compromise usually depends on the app running, handling requests, or reaching a vulnerable code path. Install-time execution removes that constraint. The attack happens at the point where dependency tooling is resolving and preparing code, so the payload inherits the trust placed in the package manager, scripts, and developer workflow rather than in the application itself.
This also changes what the attacker can steal. At install time, the most valuable targets are often environment-resident secrets that support delivery and operations, not just user-facing application data. Those secrets may be present because the machine is doing real work, such as publishing artifacts, authenticating to cloud services, or connecting to source control. Once stolen, they can be reused for repository access, infrastructure access, secret rotation bypass, or later supply chain abuse. Nx s1ngularity attack 2025 is a good example of why this matters: package compromise paired with token theft quickly turned into broad secret exposure.
The timing is especially dangerous because installation is often assumed to be a safe preprocessing step. Teams may treat it as lower risk than running the application, but from an attacker’s perspective it is often the best place to harvest credentials before defenders have any runtime telemetry, business logic validation, or user interaction to detect misuse.
Where the secret exposure actually comes from in practice
The exposure usually comes from three overlapping conditions: secrets are already present, the installer can execute code, and the environment does not strongly separate build-time from operational trust. On a developer workstation, that may mean shell profile exports, cloud provider credentials, SSH keys, and local agent sessions. On a CI runner, it may mean deployment tokens, package registry credentials, or access to internal infrastructure.
Install-time malware does not need sophisticated exploitation when those conditions exist. It can simply enumerate environment variables, inspect common credential locations, query metadata or helper processes, and transmit what it finds. That is why the risk is not just “malicious code exists,” but “malicious code executes at the exact point when sensitive material is most likely to be reachable.” The theft pattern seen in Bitwarden CLI npm compromise 2026 and TrapDoor supply chain campaign 2026 shows how package execution can be turned directly into credential collection.
That makes the true control problem one of execution scope and secret placement. If the installation environment has more privilege, broader network access, or longer-lived credentials than the application needs, then the install step becomes a secret exposure window rather than a harmless preflight task.
Risk and Threat Considerations
Install-time code execution is high risk because it turns dependency installation into an opportunity for secret harvesting, and the exposed material is often enough to move from a single machine into cloud, CI/CD, source control, or registry abuse. The attacker does not need to compromise the application later if the installation step already reveals reusable credentials.
Failure mechanism: A malicious package script runs with the same local permissions and environment visibility as the installer, then reads environment variables, credential files, or helper outputs before the developer or pipeline notices.
Impact: Stolen secrets can be reused immediately for lateral movement, artifact tampering, repository access, cloud access, or additional supply chain compromise, often with little forensic separation between the install event and the later abuse.
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 OWASP API Security Top 10 address the attack and risk surface, while CIS Controls v8 sets 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 payloads steal exposed secrets during package execution. |
| NHI-05 — Overprivileged NHI | Build and install environments often carry excess access that raises blast radius. | |
| NHI-07 — Long-Lived Secrets | Long-lived tokens on workstations and runners are prime targets for install-time theft. | |
| Recommendation — Remove secrets from install contexts and enforce least-privilege credential placement. Reduce install-time privilege and separate build credentials from deployment access. Shorten secret lifetime and rotate credentials used in package installation paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | Credential sprawl and stale access widen the impact of install-time secret theft. |
| CIS-6 — Access Control Management | Install-time malware abuses excessive access available on build and dev hosts. | |
| CIS-16 — Application Software Security | Package scripts are an application supply chain entry point for code execution. | |
| Recommendation — Inventory and remove unnecessary accounts, tokens, and shared credentials. Restrict build and developer systems to the minimum access they need. Validate dependency provenance and limit lifecycle-script execution where possible. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Overexposed secrets in install environments often reflect unsafe deployment and runtime configuration. |
| API2 — Broken Authentication | Stolen tokens and keys from installs can be reused to impersonate trusted systems. | |
| Recommendation — Harden build and runner configuration so secrets are not reachable during package installation. Treat install-time token theft as an authentication compromise and rotate affected credentials. | ||
Practitioner Guidance
What to prioritise: Treat any environment that installs untrusted packages as a secret-bearing execution surface. If build hosts or developer workstations hold high-value credentials, reduce their lifetime and scope before tightening package policy, because package controls alone will not stop a malicious script from reading already-present secrets.
What to verify: Confirm that install jobs do not inherit unnecessary cloud, registry, or SSH credentials, and check whether package installation is allowed to run arbitrary lifecycle scripts by default. If scripts are required, assume they can observe everything available to the install process and design the environment accordingly.
Decision rule: If the machine can authenticate to production systems, rotate or isolate those credentials before using it for package installation from untrusted sources. If you cannot remove the secrets, move the install into a constrained environment with minimal blast radius.
Practitioner takeaway: The real control is not “trust npm less” in the abstract, it is to prevent install-time code from ever sharing a runtime with secrets that would be unacceptable to expose.
Related resources from NHI Mgmt Group
- Why do install-time hooks and startup persistence increase the risk of malicious npm packages?
- Why do CI/CD runners increase the risk of secret theft from malicious packages?
- Why do install-time scripts and hidden runtime directories increase supply chain risk in npm environments?
- Why does import-time code execution increase supply-chain risk so much?