Shai-Hulud-style npm worms expose the limits of supply chain controls

At a glance

What this is: This is an analysis of a self-replicating npm worm campaign that used developer and CI/CD credentials to spread through packages and repositories, showing that malicious packages can behave as the exploit itself.

Why it matters: It matters because software supply chain controls that focus on post-install detection miss the point where malicious code first enters the build and dependency path, which affects application, CI/CD, and identity governance alike.

By the numbers:

• The campaign had spread through over 770 npm packages at the time of writing.

Context

Malicious open-source packages are a supply chain problem because they arrive as trusted dependencies and execute inside the build or runtime path before many controls can react. When the package itself is the attacker payload, scanners tuned to latent vulnerabilities are already one step behind the threat.

This campaign also has a genuine identity angle because it targeted GitHub, NPM, and CI/CD credentials, then used those credentials to propagate further. That makes credential governance, secrets hygiene, and package trust part of the same control problem, not separate ones.

The pattern is typical of modern software supply chain attacks: the threat moves through normal developer workflows, then multiplies through automation, registries, and repository trust.

Key questions

Q: What breaks when malicious npm packages execute during CI/CD installs?

A: The main failure is that package installation becomes code execution inside a trusted build context. That lets attacker-controlled scripts read memory, steal secrets, and potentially publish more malicious artifacts before defenders notice. The control that breaks is the assumption that dependency installation is operationally harmless. Treat install-time execution as a governed security boundary, not a routine developer convenience.

Q: Why do compromised CI/CD credentials make supply chain attacks much worse?

A: CI/CD credentials often sit at the centre of publish, build, and deployment workflows, so one stolen token can reach many repositories and environments. If those credentials are not scoped, rotated, and monitored like privileged identities, attackers can use them to publish malicious packages, access secrets, and spread laterally across trusted automation.

Q: What are the signs that malicious package controls are failing?

A: Common signs include package installation occurring before trust checks, unexplained CI/CD token use, unexpected dependency changes, and repository activity tied to compromised developer accounts. If a team can only detect bad packages after they are installed, the control is already too late for this threat model.

Q: How should security teams respond when a package worm deletes developer directories?

A: Treat it as both a supply chain compromise and an endpoint incident. Isolate affected workstations, revoke exposed credentials, block the malicious package version, and check whether publishing or repository access was abused to spread the worm further. Recovery has to cover builds, endpoints, and identity assets together.

Technical breakdown

How malicious npm packages behave as the exploit

A malicious package is not just software with a hidden flaw. It is attacker-controlled code published into a trusted registry and executed when installed. That means the compromise begins at dependency resolution, not after exploitation of a vulnerability in the package. In practice, the package can run arbitrary commands during install hooks, access local tokens, inspect developer environments, and interact with CI/CD contexts. Traditional vulnerability management struggles here because there is no defect to patch in the usual sense. The control question becomes whether the package was allowed to enter the pipeline at all.

Practical implication: move controls to pre-installation checks and package allowlisting, not only post-install scanning.

Why stolen developer and CI/CD credentials amplify spread

Once the package steals GitHub, NPM, or CI/CD credentials, the attack shifts from single-host compromise to propagation. Those credentials let the malware publish or tamper with packages, access repositories, and reach additional automation surfaces. In supply chain terms, the identity used to build and ship software becomes the bridgehead for lateral spread. This is where NHI governance matters, because tokens, registry secrets, and pipeline service accounts are non-human identities with real privilege and lifecycle requirements. If those identities are over-scoped or long-lived, the worm can reuse them repeatedly across environments.

Practical implication: inventory and restrict build-time secrets, registry tokens, and pipeline service accounts as governed NHIs.

Why destructive fallback behavior changes the risk model

The destructive step matters because it shows the campaign was not only about theft. When credential harvesting failed, the malware deleted user directories, turning a supply chain intrusion into workstation damage and operational disruption. That fallback behavior raises the impact from confidentiality into availability and productivity loss. It also undermines the assumption that package risk is limited to downstream code compromise. In reality, a malicious dependency can trigger direct damage on developer endpoints before any production deployment happens.

Practical implication: include developer workstation containment and endpoint recovery in supply chain response planning.

Threat narrative

Attacker objective: The attacker objective was to turn trusted package distribution and developer identity into a self-replicating theft and disruption mechanism across open-source ecosystems.

1. Entry occurred when developers or CI/CD systems installed a malicious npm package that was already designed to execute on use.
2. Credential harvesting followed as the package attempted to steal GitHub, NPM, and related secrets from workstations and pipeline environments.
3. Propagation and escalation occurred when the stolen credentials were reused to infect other packages and repositories, allowing the worm to spread autonomously.
4. Impact included compromised software supply chains, exposed developer secrets, failed builds, deleted home directories, and lost productivity.

Breaches seen in the wild

• Checkmarx KICS supply chain attack 2026: Credentials stolen via Trivy let attackers poison Checkmarx KICS Docker images, VS Code extensions and Actions to steal developer secrets.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

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

Malicious packages are now a primary control boundary, not a secondary software quality issue. When the package is the payload, the security decision happens before installation, not after code review or dependency inventory. That changes the control model for supply chain security, because detection alone does not prevent execution. Practitioners should treat package admission as a high-risk trust decision, not a routine procurement step.

Credential theft is the propagation mechanism that turns a package incident into an ecosystem incident. The article shows how GitHub, NPM, and CI/CD secrets become reusable identity bridges for replication. That is an NHI governance problem as much as a software supply chain problem, because pipeline tokens and registry credentials behave like privileged machine identities. Practitioners should govern those secrets as infrastructure-grade assets with narrow scope and short lifetimes.

Delete-on-failure behavior is a warning that supply chain attacks now target developer operations directly. The fallback destruction of home directories broadens the blast radius from code compromise to workstation damage and productivity loss. This is the kind of behaviour that exposes weak assumptions about where supply chain risk ends. Practitioners should include developer endpoint resilience in the same incident planning used for repository compromise.

Pre-installation enforcement is becoming the decisive control pattern for open-source risk. The article’s most important lesson is that traditional vulnerability scanning is not enough when malicious code is delivered as a dependency. Controls such as package identification, registry screening, and build-time blocking matter because they intercept the threat before it can execute. Practitioners should push controls left to the point where the dependency is first trusted.

What this signals

Package admission is becoming the new trust boundary for software teams. If malicious code can reach execution through a trusted registry, then the only durable answer is to screen, block, and validate packages before installation. That pushes security work into the developer workflow and the CI/CD path, where trust is actually granted.

Shai-Hulud-style worm behaviour exposes a combined identity and supply chain failure mode. Registry tokens, repository credentials, and pipeline secrets are not passive configuration items, they are non-human identities that can be stolen and reused at scale. Security teams should govern them with the same discipline they already expect for privileged accounts.

Developer resilience now belongs in supply chain planning. A malicious package that deletes user directories shows that the blast radius is not limited to code integrity. Teams need endpoint recovery, build integrity, and credential revocation to be part of the same response playbook.

For practitioners

• Block malicious packages before installation Enforce pre-install package screening in CI/CD, developer IDEs, and registry access paths so suspicious npm artifacts never reach execution.
• Govern registry and pipeline credentials as NHIs Inventory GitHub, NPM, and CI/CD tokens, scope them tightly, rotate them aggressively, and revoke unused secrets quickly.
• Treat package publishing rights as high-risk access Review who can publish, modify, or recover packages and repositories, then apply separation of duties to reduce blast radius.
• Add workstation damage to supply chain response plans Plan for deleted home directories, failed builds, and endpoint recovery as part of the response to malicious package incidents.

Key takeaways

• The core risk is not hidden weakness in a legitimate dependency, but attacker code published as a dependency and executed on install.
• The campaign’s ability to reuse stolen GitHub, NPM, and CI/CD credentials made it a propagation problem as much as a compromise problem.
• The most effective control point is before installation, backed by governed secrets, package screening, and recovery planning for developer systems.

Key terms

• Malicious Package: A malicious package is software published into a legitimate repository but designed to execute harmful code when installed. It abuses normal dependency workflows so that the attacker’s code reaches the environment through trust in the package ecosystem, not through a traditional exploit.
• Supply Chain Worm: A supply chain worm is malware that uses one compromise to propagate into adjacent packages, repositories, or automation systems. In identity terms, it becomes far more dangerous when it can harvest and replay secrets that let it publish, move, or persist without further exploitation.
• CI/CD Credential Broker: A CI/CD system that does more than build and deploy because it also stores or issues credentials for cloud and application access. In practice, this creates a hidden identity tier inside delivery infrastructure, where compromise of the pipeline can expose downstream permissions.
• Package Admission: Package admission is the decision point where tooling or policy determines whether a dependency is allowed into a build or deployment workflow. In mature programmes, this is where trust is enforced, exceptions are recorded, and automation is constrained by policy.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.