Npm supply chain attacks now exploit identity, not code

At a glance

What this is: This is an analysis of npm supply chain attacks shifting from code tampering to identity compromise, with attacker access increasingly obtained through maintainer accounts, publishing tokens, and CI/CD credentials.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern package publication identities and pipeline credentials as attack paths, not just the code they authorize.

By the numbers:

• The article says the biggest wave in npm’s history spanned August 2025 to mid-2026.
• A package in the wave was downloaded 100 million times a week.

Context

Npm supply chain compromise is no longer just a code integrity problem. The primary failure point is identity, because a malicious package often enters the ecosystem through a stolen maintainer account, a publishing token, or a CI/CD credential that already has permission to publish trusted software.

That shifts governance from repository scanning to publication control, secrets hygiene, and pipeline oversight. For IAM, PAM, and NHI programmes, the question is no longer only which code was shipped, but which identities were allowed to ship it and whether those identities were bounded tightly enough to contain abuse.

Key questions

Q: What fails first in an npm supply chain attack when identities are compromised?

A: The first failure is usually publication trust, not code validation. Once a maintainer account or CI/CD token is stolen, the attacker can publish a package that looks legitimate to downstream tooling and developers. That means the control that failed was the identity allowed to publish, especially when the package ecosystem assumes trusted names are trustworthy by default.

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

A: Because package ecosystems amplify a single privileged identity across many consumers. A stolen publishing credential can reach direct and transitive dependencies, and automated installation means the malicious package can execute before human review. The scale comes from trust inheritance, not from the sophistication of the payload alone.

Q: How should security teams build detection for malicious npm packages at publish time?

A: Security teams should combine fast package intake with layered enrichment, static analysis, and automated quarantine of suspicious records. Publish-time detection works best when the pipeline can scale horizontally, requeue failures, and filter benign packages before expensive analysis. The goal is to catch install-time abuse early, before malicious code reaches developers or production environments.

Q: How should IAM teams govern npm publishing and CI/CD identities?

A: They should treat package publishing accounts, tokens, and runner credentials as privileged non-human identities with explicit ownership, lifecycle control, and tight scope. That means separating publish rights from routine development access, enforcing strong authentication, and revoking or rotating credentials that are no longer needed.

Technical breakdown

Trusted publication identities as the entry point

In npm attacks, the attacker usually does not break the registry. They compromise the identity that can publish to it, such as a maintainer account, a personal access token, or an OIDC token available in CI/CD runner memory. That makes the package release process the real trust boundary. Once the attacker can publish under an established package name, downstream consumers inherit that trust automatically, including transitive dependencies they never selected directly.

Practical implication: Treat publishing identities as privileged assets and scope them separately from normal developer access.

Why install-time execution is the real blast radius

npm is dangerous because packages can execute code during installation, not just after deployment. Malicious install scripts, obfuscated payloads, or sleeper logic can run the moment npm install executes on a developer workstation or build runner. That means the compromise can occur before conventional repository scanning or endpoint review has any chance to intervene, especially when the package name is already trusted.

Practical implication: Reduce or sandbox install-time script execution wherever the package does not absolutely require it.

How self-propagating worms turn identity theft into scale

The Shai-Hulud pattern shows how stolen credentials can be reused to publish the next malicious package automatically. Instead of a one-off compromise, the attacker converts stolen publishing access into propagation logic that extends through the dependency graph. That is why identity compromise in npm is not a single account problem; it is a supply chain amplification problem that multiplies through automation and transitive trust.

Practical implication: Watch for automated publishing activity following credential theft because it indicates propagation, not just intrusion.

Threat narrative

Attacker objective: The attacker wants trusted package publication capability that lets malicious code reach developers and build systems through legitimate-looking updates.

1. Entry occurs when attackers phish a maintainer, steal a publishing token, or extract an OIDC credential from CI/CD runner memory.
2. Credential access gives them permission to publish a malicious package under a name developers already trust.
3. Impact follows when install scripts or worm logic executes at install time and spreads through the dependency graph before review can stop it.

Breaches seen in the wild

• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
• Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.

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

Publication identity is now the control plane for npm risk. The article shows that attackers are no longer relying primarily on code novelty. They are compromising the identities that can publish software, which means the governance failure sits in credential authority, not in source code review. For identity teams, package publication is a privileged action and should be treated like any other high-risk approval path.

npm supply chain compromise exposes an NHI governance gap, not just a developer hygiene problem. CI/CD tokens, OIDC credentials, and publishing tokens are non-human identities with production-grade reach, yet many programmes still treat them as disposable implementation detail. That assumption breaks once a single token can publish to a trusted registry. Practitioners should govern these credentials as lifecycle-managed machine identities, not as incidental build artifacts.

Self-propagating package malware is a trust amplification problem. The Shai-Hulud pattern matters because one stolen identity can create a chain reaction through automated publishing and transitive dependencies. That makes blast-radius control the decisive issue: short-lived credentials, publish-time approvals, and pipeline segregation matter more than after-the-fact code review. The practitioner conclusion is simple, if uncomfortable: trust must be bounded before publication, not inspected after it.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
• Read next: AI Supply Chain Security and AI-BOM Guide

What this signals

Publication-time identity control is the new supply-chain boundary. npm compromise now succeeds when the attacker can borrow or steal the identity that is allowed to publish, which means registry trust has become an IAM problem as much as an AppSec problem. Security teams should expect their software supply chain controls to fail if publishing credentials are treated as ordinary developer secrets rather than privileged non-human identities.

92% of organisations expose NHIs to third parties, according to the Ultimate Guide to NHIs, which is exactly the kind of external dependency surface these campaigns exploit. In practice, that means supplier access, build automation, and release tooling all need the same lifecycle scrutiny that teams already apply to human admin accounts. The practical shift is to govern who can publish, not just what gets published.

For practitioners

• Strengthen publishing identity controls Require hardware-backed MFA, device binding, and separate privileged accounts for package publication so a stolen maintainer login cannot directly ship releases.
• Treat CI/CD tokens as high-risk NHIs Inventory OIDC tokens, runner credentials, and publishing secrets, then scope and rotate them aggressively with explicit ownership and expiry.
• Reduce install-time execution exposure Disable or sandbox postinstall scripts by default and allow exceptions only for packages that have a documented operational need.
• Monitor for publication-pattern anomalies Look for unlock-inject-relock behaviour, unusual version bursts, or rapid successive publishes that indicate pipeline abuse rather than normal release activity.

Key takeaways

• npm supply chain attacks now exploit identity at publication time, so the main control gap is who can publish trusted software, not whether the code looks suspicious after release.
• The biggest failures involve maintainer accounts, publishing tokens, and CI/CD identities that can push malicious packages into the registry under legitimate names.
• Teams reduce exposure by tightening publishing privileges, limiting install-time execution, and monitoring release pipelines for abnormal behaviour.

Key terms

• Publishing Identity: The account, token, or credential set that authorises changes to a software package distribution channel. It is a privileged non-human identity because it can affect many downstream systems at once, so compromise of this identity can become an ecosystem-wide security event.
• 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.
• Self-propagating worm: A self-propagating worm is malware that automatically spreads from one compromised system to another without waiting for a human operator to copy it. In software supply chains, propagation often happens through trusted accounts, package registries, or update channels that the worm can reuse.
• Publication-Time Control: Publication-time control is the governance applied before software is accepted into a registry, signed, or distributed. It focuses on who may publish, what credentials they use, and whether the release action is sufficiently constrained to prevent identity abuse.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and the controls behind privileged publishing access. It is designed for practitioners who need to manage identity risk across human, non-human, and automated delivery paths.