Npm supply chain attacks now exploit identity, not code

At a glance

What this is: This is an analysis of how npm supply chain attacks now use compromised identities and pipeline credentials to publish malicious packages that look legitimate.

Why it matters: It matters because AppSec, IAM, and PAM teams need to control publishing identities, token scope, and install-time execution before malicious packages reach developers or CI/CD.

👉 Read Xygeni's analysis of npm supply chain attacks and compromised identities

Context

Npm supply chain attacks are a trust problem as much as a malware problem. The weak point is often not the repository itself, but the identities and tokens that can publish packages into the ecosystem, which makes this a governance issue for IAM, PAM, and NHI teams as well as AppSec.

When attackers steal a maintainer account, a publishing token, or a CI/CD credential, they inherit the right to distribute code that developers already trust. That means package integrity controls, secret management, and pipeline identity controls have to be treated as one connected attack surface, not separate tool categories.

The 2025 to 2026 attack wave described here is typical of the current risk pattern: identity compromise first, package publication second, install-time execution third.

Key questions

Q: What breaks when npm publishing identities are not tightly controlled?

A: Attackers can use a stolen maintainer account or CI/CD token to publish malicious packages that look legitimate to developers and automation. That bypasses code-centric reviews because the trust decision happens before the code is even installed. The control failure is publication authority without strong lifecycle governance.

Q: Why do npm supply chain attacks remain effective even when teams scan dependencies?

A: Dependency scanning is usually post hoc, while these attacks often execute at publish time or install time. If a package runs malicious code during installation, the harm can occur before a scanner has any chance to flag it. Teams need controls that inspect and gate new packages before installation.

Q: What do security teams get wrong about token rotation in CI pipelines?

A: They often treat rotation as equivalent to removal. Rotation shortens exposure, but it still leaves a valid secret that can be stolen during its lifetime. If the workflow can operate without a standing secret, secretless publishing is the stronger control because it removes the object attackers want to steal.

Q: Who should be accountable when compromised npm packages spread through CI and developer systems?

A: Accountability should sit with the teams that own workflow identity, dependency governance, and secret management together, because the failure spans all three. Security, platform engineering, and application owners need a shared response model for package poisoning, credential rotation, and publishing control. That shared ownership is what prevents a supply-chain issue from becoming an open-ended identity incident.

Technical breakdown

Why identity compromise is the real entry point in npm attacks

Most npm supply chain incidents begin with stolen publishing authority rather than a break-in to the registry itself. Attackers phish a maintainer, steal a CI/CD token, or pull an OIDC token from runner memory, then use that identity to publish a malicious package under a name developers already trust. Because npm updates are automated, the malicious release can spread before any human review catches it.

Practical implication: treat package publishing identities as high-value privileged accounts and lock them behind strong authentication, short-lived tokens, and explicit approval paths.

Why install-time execution makes package scans arrive too late

A package can execute code during installation through install scripts, postinstall hooks, or embedded payloads. That means the harmful action can happen on a developer laptop or build runner the moment npm install runs, before a repository scanner or endpoint tool sees the package as a threat. Static analysis is still useful, but it does not stop a package that has already executed.

Practical implication: block or sandbox install-time scripts by default and inspect new releases before installation, not only after they land in source control.

How self-propagating worms turn one identity breach into many packages

The most dangerous pattern is persistence plus propagation. Once a malicious package steals credentials from one developer or pipeline, it can publish the next poisoned package automatically. That turns one compromised identity into a machine-speed distribution channel across the dependency graph, which is why registry monitoring and pipeline anomaly detection matter as much as code review.

Practical implication: monitor for publish-after-publish behaviour, not just suspicious code, and revoke credentials as soon as propagation is suspected.

Threat narrative

Attacker objective: The attacker wants to convert trusted publishing authority into broad downstream code execution and secret theft across the npm ecosystem.

1. Entry occurs when an attacker steals a maintainer account, publishing token, or CI/CD identity and uses that trusted access to publish a malicious npm package.
2. Credential access and persistence follow when the package or pipeline logic steals additional secrets from developer or runner environments, creating a reusable distribution foothold.
3. Impact occurs when malicious installs or self-propagating releases execute across developer workstations and build systems, enabling broad supply chain compromise.

NHI Mgmt Group analysis

Identity compromise is now the primary supply chain control failure in npm abuse. The article shows that attackers do not need to break npm itself if they can borrow a maintainer’s key to the registry. That shifts the governance problem toward publishing identities, CI/CD tokens, and secrets hygiene across the software delivery chain. Practitioners should treat package publishing as a privileged action with explicit lifecycle control.

Pre-install detection has become a necessary control boundary, not an optional enhancement. Traditional AppSec tools were designed to find vulnerable code after it exists, but npm attacks increasingly execute during installation or immediately after publication. That creates a publication-to-execution gap that static scans cannot close on their own. Teams need controls that inspect new packages before trust is granted, not after damage starts.

Secret sprawl creates the conditions for package-level blast radius expansion. Once one token or maintainer account is compromised, attackers often pivot into more identities and more publishing paths. This is the same failure mode seen across NHI governance generally: too many credentials with too much standing privilege and too little visibility into where they can publish or delegate. The lesson is to reduce standing publishing authority before it becomes a propagation channel.

Shai-Hulud-style propagation is a named concept teams should now track as a control gap. It describes the transition from one stolen identity to an automated chain of malicious package publication. That pattern turns a single compromise into a registry-wide risk multiplier and makes revocation speed, token scope, and pipeline anomaly detection central governance issues. Practitioners should assume propagation is possible once publication identity is lost.

OWASP NHI Top 10 concerns now apply directly to software supply chain identities. Package publishing accounts, runner tokens, and automation credentials behave like non-human identities with high blast radius and weak human oversight. That makes NHI lifecycle management relevant to AppSec in a way many teams still underweight. The practical conclusion is that software release identities need the same scrutiny as human admin access.

What this signals

Secret governance is now a release-engineering issue as much as an IAM issue. If publishing credentials can create registry-wide impact, then lifecycle control, rotation cadence, and approval boundaries for non-human identities need to sit inside the software delivery operating model, not beside it.

Teams should expect more attacks that blend package publication, token theft, and install-time execution. The relevant standards conversation is increasingly about entitlement scope and auditability, which is where NIST SP 800-53 and MITRE ATT&CK help anchor detection and control design.

Publication identity will become a visible category of NHI risk. Package maintainer accounts, CI runners, and automation tokens are already functioning as non-human identities with high trust and weak review. That means organisations need to inventory, classify, and govern them with the same seriousness applied to service accounts and privileged administrative access.

For practitioners

• Lock down package publishing identities Require hardware-backed MFA, narrow token scope, and explicit ownership for npm publishing accounts, CI/CD tokens, and runner credentials.
• Block install-time script execution by default Disable or sandbox postinstall and other install scripts for packages that do not genuinely need runtime code execution during installation.
• Monitor for publish-after-publish propagation Watch for repeated releases, unusual namespace changes, and unlock-inject-relock patterns that indicate a stolen identity is being used to spread malicious packages.
• Treat OIDC and CI runner tokens as privileged secrets Scope runner credentials tightly, rotate them aggressively, and review whether build identities can publish or sign artefacts without additional controls.

Key takeaways

• Npm supply chain attacks succeed because attackers steal the identities that are allowed to publish trusted code.
• The scale of the current wave shows that one compromised maintainer or token can create ecosystem-wide exposure before detection arrives.
• Teams need pre-install inspection, tight token governance, and identity controls for publishing workflows, not just post-release scanning.

Key terms

• Npm Supply Chain Attack: An npm supply chain attack is a compromise that enters through the package distribution pipeline rather than the target application itself. Attackers usually abuse a maintainer account, publishing token, or build identity to ship malicious code that downstream developers and automation treat as trusted software.
• 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.

What's in the full article

Xygeni's full post covers the operational detail this analysis intentionally leaves for the source:

• Step-by-step breakdown of the unlock-inject-relock CI/CD compromise pattern seen in recent npm incidents.
• Behavioral indicators for detecting malicious package publication before install time.
• Detailed comparison of malware early warning and dependency firewall controls across npm, PyPI, Maven, NuGet, and RubyGems.
• Remediation workflow examples for handling compromised publishing identities and poisoned package versions.

👉 Xygeni's full post covers the npm attack chain, propagation patterns, and detection controls in more operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and machine identity security. It helps security and identity practitioners build stronger controls around the credentials that software pipelines use to publish and deploy code.