Why do stolen maintainer accounts and CI/CD tokens create such large npm blast radius?

Why npm blast radius grows so fast after maintainer or CI/CD compromise

npm is built to reuse trust at scale. Once an attacker gets a maintainer account or a publishing token, they inherit the ability to distribute code through direct installs and through the dependency tree. Because package managers and automation pull updates faster than humans can inspect them, the compromise spreads through trust relationships, not just through the malware itself.

The key issue is that the attacker does not need broad infrastructure access. They only need one publishing path that downstream systems already trust, which is why a single stolen token can affect many projects at once. That makes npm compromise a supply chain problem first, and a credential problem second.

How a single publishing identity reaches many downstream projects

In npm, maintainers and CI/CD jobs often hold the authority to publish versions, update package metadata, and trigger release workflows. That authority is effectively inherited by every consumer that depends on the package, including transitive dependants that the end user never explicitly chose. The result is multiplicative exposure: one account can influence many repositories, applications, and build systems.

That is why the blast radius is larger than the initial account compromise. A malicious release can be cached, mirrored, or automatically adopted by dependency update bots, and then pulled into CI pipelines or production builds before anyone reviews the change. NHIMG’s Ultimate Guide to NHIs — What are Non-Human Identities is useful background here because package publishing tokens, service accounts, and automation credentials are all identity-bearing access paths that can carry delegated authority across systems.

The same pattern appears when the attacker steals CI/CD tokens rather than a human maintainer password. A pipeline token often has enough privilege to sign artifacts, publish packages, read secrets, or access private repositories, so the compromise jumps from one identity to the release machinery that fans out to everyone downstream.

Why automated installation makes the damage immediate

npm ecosystems are especially sensitive to automation because dependency resolution happens continuously and at machine speed. When a poisoned package version is available, build tools, lockfile refreshes, bots, and developer workstations may ingest it with little or no manual review. That means the attacker can achieve execution on the consumer side even if the payload is simple.

The risk is not only malicious code. A compromised package can also exfiltrate environment variables, CI secrets, cloud credentials, signing material, or repository tokens during install or test phases. NHIMG’s Guide to the Secret Sprawl Challenge is directly relevant because leaked pipeline secrets are often the next object of theft after the first package compromise.

That is why the ecosystem behaves like a trust amplifier. Direct dependencies create one reach path, transitive dependencies create many more, and install-time execution turns a publishing event into a runtime event. In practice, the attacker only needs one successful version publish to convert trusted distribution into broad execution.

Risk and Threat Considerations

npm compromise becomes high impact when the stolen identity can publish, modify, or trigger automation across multiple packages. The dangerous condition is not just that a maintainer account was stolen, but that the account sits inside a release channel that downstream consumers trust by default.

Failure mechanism: Attackers abuse publishing authority, CI/CD tokens, or automation credentials to push a malicious package version, then let dependency resolution and install-time execution distribute it across many environments before detection.

Impact: The compromise can reach transitive consumers, CI runners, developer laptops, and production build systems, creating wide secret exposure, code execution, and follow-on supply chain compromise.

Practitioner Guidance

What to prioritise: Treat package publishing credentials and CI/CD tokens as release-critical identities, not convenience secrets. The first question is whether the token can publish, sign, or read secrets, because that determines whether the compromise is a local account issue or a ecosystem-wide exposure.

What to verify: Check whether release automation uses short-lived credentials, whether token scope is limited to a single package or environment, and whether publishing requires an additional human approval step for sensitive releases. When those controls are missing, assume the blast radius is larger than it appears.

Common mistake: Teams often focus on the malicious payload and ignore the distribution channel. In npm, the package content matters, but the compromised publishing path is usually the real force multiplier.

Practitioner takeaway: Shrink blast radius by narrowing publishing authority, isolating CI tokens from broad repository access, and making package releases harder to automate than package installs.

Related resources from NHI Mgmt Group

• Why do stolen CI tokens and publishing tokens create such a large blast radius?
• Why can a single SaaS app create such a large blast radius?
• Why do CI/CD secrets create such a large blast radius in supply chain attacks?
• Why do exposed secrets in CI/CD pipelines create such a large blast radius?