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 malicious npm package campaign that harvested credentials, spread across repositories, and triggered destructive fallback behaviour when theft failed.

Why it matters: It matters because modern software delivery now depends on identities, tokens, and CI/CD trust chains that can be abused to move from one compromised workstation or pipeline into many downstream environments.

By the numbers:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes

👉 Read Checkmarx's analysis of the Shai-Hulud second-coming npm worm

Context

Malicious packages are a supply chain problem with an identity problem underneath it. Once attacker code is published into a public registry, the package itself becomes the delivery vehicle, and the real blast radius is determined by which secrets, tokens, and build permissions it can reach after installation. In this campaign, the primary weakness was not just malicious code, but the trust placed in developer workstations, CI/CD systems, and repository credentials.

For NHI and IAM teams, the relevance is direct. GitHub tokens, npm credentials, and pipeline secrets are non-human identities in practice, even when they are managed informally by developers or DevOps teams. A campaign that can steal, reuse, and propagate those credentials shows why identity lifecycle controls, secret containment, and runtime validation need to extend into software supply chain security.

The starting position is typical for modern software teams: broad dependency use, distributed secrets, and implicit trust in package install paths. That combination is now a standard exposure pattern, not an edge case.

Key questions

Q: What breaks when malicious packages can execute during installation?

A: Traditional dependency scanning becomes too late because the package has already run. At that point, the attacker can harvest secrets, change repositories, or drop destructive payloads before defenders have a chance to intervene. Security teams need pre-install controls, execution restrictions, and fast identity revocation, not only post-facto cleanup.

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: How should organisations reduce the impact of malicious package worms?

A: They should prevent untrusted packages from executing, isolate build hosts, and keep publishing identities separate from normal developer access. The goal is to make stolen secrets and compromised installs less useful for lateral spread. Response plans should also include immediate revocation of any credentials present in the affected pipeline.

Q: What frameworks help govern malicious package and secret exposure risk?

A: MITRE ATT&CK helps map credential access and lateral movement, while NIST SP 800-53 and NIST CSF support access control, monitoring, and recovery. For identity-specific software supply chain controls, OWASP NHI is also relevant because stolen tokens and repository credentials behave as non-human identities in practice.

Technical breakdown

How malicious npm packages become self-replicating worms

A malicious package does not need a software vulnerability to succeed. It is published as code that runs during normal install or build activity, often through lifecycle scripts or adjacent tooling hooks. Once executed, it can read local environment variables, browser-stored tokens, SSH material, and CI/CD credentials, then use those credentials to publish further packages or tamper with repositories. That turns ordinary dependency resolution into an execution path. The key architectural shift is that trust in the package registry is not enough if the install process itself can execute attacker-controlled logic.

Practical implication: treat package installation as an execution boundary and block untrusted lifecycle behaviour before it reaches developer or pipeline environments.

Why credential harvesting turns supply chain exposure into identity abuse

The campaign’s power comes from the credentials it steals, not only from the malware itself. GitHub, npm, and related tokens often carry enough privilege to create releases, modify repositories, or push new artifacts, which means a single compromise can become a distributed identity event. In NHI terms, these are standing secrets with no strong lifecycle control, no contextual validation, and often no tight scope. Once the attacker holds a valid token, the package ecosystem becomes a credential propagation layer rather than just a code distribution layer.

Practical implication: scope developer and CI/CD tokens to the minimum publishing and read actions required, then rotate and revoke them as soon as abnormal package activity appears.

Why destructive fallback behaviour matters in malicious package defense

The reported deletion of user directories when credential theft failed shows that malicious packages often include multiple objectives. If exfiltration is blocked, the malware can still create operational harm, disrupt builds, and increase the chance that defenders miss the initial compromise because the incident looks like a workstation failure or corrupted environment. This is why supply chain security cannot stop at detection after install. Prevention, inspection, and controlled execution paths matter because the package may already contain a second-stage impact condition.

Practical implication: isolate build hosts, restrict filesystem write access, and use pre-install blocking for known malicious packages rather than relying only on post-detection cleanup.

Threat narrative

Attacker objective: The attacker aims to turn trusted package distribution and developer identity assets into a self-propagating compromise that spreads across repositories and CI/CD systems.

1. Entry occurs when developers or pipelines install a malicious npm package that is disguised as legitimate software.
2. Credential access follows when the package harvests GitHub, npm, and related secrets from workstations or CI/CD environments.
3. Escalation and lateral movement happen when stolen credentials are reused to infect additional packages and repositories, amplifying distribution.
4. Impact is delivered through broad repository contamination, build disruption, data theft risk, and destructive deletion when credential theft fails.

NHI Mgmt Group analysis

Malicious packages are identity attacks disguised as software attacks. The core security failure is not only that attacker code is installed, but that the code can reach usable identities inside developer and pipeline environments. Once a package steals tokens or service credentials, the campaign stops being a simple software supply chain event and becomes NHI abuse. That is why dependency controls, secrets governance, and identity scoping must be treated as one control plane, not three. Practitioners should assume the package itself is only the carrier.

Standing secret trust is the named failure mode this campaign exploits. The attack works because package install paths still rely on long-lived credentials that can be harvested and reused before teams notice. In a mature model, secrets would be tightly scoped, short-lived where possible, and invalid outside a verified execution context. The practical conclusion is that any build or developer identity capable of publishing software should be managed like privileged production access.

Malicious package prevention belongs before installation, not after scanning. Scanner-only strategies are too late when the package itself runs during installation. This strengthens the case for pre-install blocking, allowlisting, and reputation-based gating at registries and build checkpoints. For identity programmes, that means secrets, tokens, and repository permissions must be paired with execution controls rather than treated as passive artefacts.

The blast radius is wider than the package ecosystem alone. When a malicious dependency can delete local files, steal tokens, and mutate repositories, the incident becomes a developer productivity, resilience, and governance issue at once. That makes coordinated ownership essential across AppSec, IAM, DevOps, and SOC teams. Organisations should map where NHI credentials exist in software delivery and reduce every place where a stolen token can become a new trust anchor.

Supply chain worming is a governance test for agentic and machine identity controls. As more build automation and AI-assisted development tools enter software pipelines, the number of non-human identities capable of interacting with registries will increase. That creates a stronger need for least privilege, short-lived credentials, and runtime attestation around every automated actor. The practitioners who treat this as a pure malware problem will miss the identity layer that makes propagation possible.

What this signals

The immediate signal for practitioners is that software delivery has become an identity-rich attack surface, not just a code quality problem. As dependency ecosystems expand and automated build systems multiply, a single stolen token can now create a chain of package tampering, repository compromise, and operational disruption. That pattern makes secrets containment and token lifecycle management central to supply chain resilience.

Credential propagation window: the time between a secret being exposed and that secret becoming operationally useful to an attacker is the control window that matters most. In environments where package installs can execute code, the window is often measured in minutes, not review cycles. Practitioners should align secret revocation, build isolation, and registry blocking around that window rather than around audit cadence.

The longer-term programme implication is that AppSec, IAM, and DevOps will need shared governance for non-human credentials. The control question is no longer whether a dependency is trusted at publication time, but whether the identity that installs, signs, or publishes it is bound to the right scope at runtime.

For practitioners

• Inventory package-publishing identities and CI/CD tokens Map every GitHub, npm, and pipeline credential that can publish, modify, or install software. Classify them as non-human identities, restrict them to the smallest necessary scope, and remove any token that can be reused across multiple repositories or environments. This reduces the number of credentials a malicious package can steal and repurpose.
• Block malicious packages before installation Add pre-install controls at developer endpoints, build systems, and private registries so known malicious versions never execute. Pair repository reputation checks with policy enforcement in CI/CD, and do not rely on post-scan alerts alone. The control point must sit before package code can run.
• Separate build trust from developer convenience Remove broad write access from standard developer tokens and require dedicated publishing identities for release activity. Use short-lived credentials for release pipelines, and ensure those identities cannot be reused interactively from workstations. That makes token theft less useful for propagation.
• Isolate and harden build hosts Use restricted filesystem permissions, sandboxed runners, and network egress limits on build and test systems. The campaign’s destructive fallback behaviour means compromised environments should have less ability to delete directories or reach secondary repositories. Containment limits both damage and spread.
• Link AppSec findings to identity revocation workflows When a malicious package is detected, trigger immediate revocation and rotation for any credentials used in the affected environment. The response path should connect package intelligence with identity operations so stolen tokens are disabled before they can be reused.

Key takeaways

• This campaign shows that malicious packages are identity abuse events, because they convert stolen developer and CI/CD credentials into propagation paths.
• The evidence points to a scale problem, with hundreds of compromised packages and tens of thousands of affected repositories creating a broad blast radius.
• The limiting control is pre-install prevention combined with rapid credential revocation, not detection after the package has already executed.

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.
• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Pre-Install Blocking: Pre-install blocking is a control that prevents a package from being downloaded or executed if it matches a known malicious reputation or policy violation. It matters because a package that never runs cannot steal secrets, alter repositories, or trigger downstream infection during installation.

What's in the full article

Checkmarx's full article covers the operational detail this post intentionally leaves for the source:

• How Malicious Package Protection flags infected versions across npm, Maven Central, PyPI, and other registries
• How the Malicious Package Identification API can block package installation before code reaches the build step
• How the research team validates suspicious packages before they are added to the malicious package database
• How Checkmarx AI Developer Assist surfaces protection directly inside the developer workflow

👉 Checkmarx's full post covers the malicious package mechanics, the spread pattern, and the protection workflow in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity control to the operational risks that now shape software delivery and automation.