Shai-hulud showed how npm supply chains fail on identity trust

At a glance

What this is: This is an independent analysis of the Shai-Hulud npm worm and its key finding that compromised developer and machine identities let attackers weaponize normal package publishing workflows.

Why it matters: It matters because IAM, NHI, and CI/CD controls now have to assume package managers, tokens, and maintainer accounts are active attack surfaces, not just delivery mechanisms.

By the numbers:

• Attackers compromised over 500 npm packages in the Shai-Hulud attack, including widely used libraries and packages tied to cybersecurity vendors.
• The worm spread to more than 180 packages poisoned in under 24 hours.
• Shai-Hulud surfaced as a malware worm on Sept. 16-17, 2025.

👉 Read CyberArk's analysis of the Shai-Hulud npm supply chain attack

Context

Shai-Hulud is a supply chain attack in which malicious code moved through npm by abusing trusted maintainer identities and machine credentials. For IAM and NHI teams, the key issue is not only package integrity but whether human accounts, API keys, and CI/CD tokens can publish changes without strong verification.

The article uses a real worm to show how quickly identity trust can be converted into downstream compromise. That starting position is typical for modern software supply chain risk: the weak point is usually not the package manager itself, but the credentials and approval paths wrapped around it.

Key questions

Q: How should security teams protect npm and package publishing workflows from identity compromise?

A: Security teams should treat package publishing as privileged access. Use phishing-resistant MFA, separate publisher roles, step-up approval for release actions, and signed artifacts. Then reduce the chance of token reuse by enforcing short-lived credentials and continuous secret scanning across developer systems and CI/CD pipelines.

Q: Why do non-human identities make supply chain attacks harder to contain?

A: Non-human identities can be copied, replayed, and reused at machine speed, which lets one compromised token or API key affect many pipelines at once. That is why containment depends on short lifetimes, narrow scope, anomaly detection, and rapid revocation across every environment that can consume the secret.

Q: What is the difference between developer account compromise and secret compromise in CI/CD?

A: Developer account compromise gives an attacker interactive access to tools and approvals, while secret compromise gives direct machine-level access without needing a login. In supply chain incidents, both matter because a stolen token can publish code, access cloud resources, and persist after the human account is secured.

Q: When should organisations treat package registries as a security boundary?

A: Organisations should treat package registries as a security boundary whenever packages can move into production automatically. If a registry or maintainer can trigger build, deploy, or publish actions, then identity controls, provenance checks, and release approvals need to be applied at that boundary, not after compromise is discovered.

Technical breakdown

How npm maintainer compromise becomes supply chain execution

The attack path begins when an adversary obtains a maintainer’s credentials, session token, or OAuth approval, then uses that access to publish poisoned updates. In npm, maintainers can push changes into packages that downstream pipelines trust automatically, which turns identity compromise into code execution at scale. Shai-Hulud also showed how an attacker can add persistence by injecting GitHub Actions workflows, ensuring future builds continue to leak secrets. The important mechanism is not just malware delivery. It is the abuse of trusted publishing rights across developer, machine, and automation identities.

Practical implication: Treat package publishing rights as privileged access and require step-up verification for release actions.

Why secrets harvesting is central to NHI risk in CI/CD

Shai-Hulud used a hidden payload to scan files, environment variables, dotfiles, and cloud metadata endpoints for secrets. That matters because CI/CD environments often contain long-lived tokens, API keys, and cloud credentials that function as non-human identities with broad access. Once stolen, those secrets can be reused outside the original environment unless they are short-lived, tightly scoped, and monitored. The attack did not depend on memory scraping or advanced exploitation. It depended on finding the normal credentials that build systems and developer workstations routinely expose to software at runtime.

Practical implication: Reduce the lifetime and scope of CI/CD secrets and monitor them as active identities, not static configuration.

How worm-like propagation changes the trust model for package ecosystems

A worm differs from a one-off compromise because it uses each victim to infect the next set of targets. In this case, once the malware found npm tokens, it could push backdoored versions of additional packages and republish top packages owned by each maintainer. That creates exponential spread and makes cleanup harder because malicious updates may already be embedded in downstream builds. The architectural failure is a trust model that assumes authenticated publishing is equivalent to trusted publishing. In a worm scenario, that assumption breaks immediately.

Practical implication: Add provenance checks, signed releases, and anomaly detection to publishing workflows before package trust is assumed.

Threat narrative

Attacker objective: The attacker’s objective was to weaponize trusted package publishing so stolen identities could spread malware and harvest more secrets across downstream environments.

1. Entry via compromised npm maintainer accounts, likely through phishing, token theft, credential reuse, or account recovery abuse.
2. Credential_harvested when the worm scanned files, environment variables, dotfiles, and cloud metadata endpoints for tokens and API keys.
3. Escalation and propagation occurred when stolen npm access was used to push malicious updates and republish additional packages.
4. Impact was downstream compromise of CI/CD pipelines, developer environments, and the broader software supply chain.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity trust debt is now a supply chain problem, not just an IAM problem. When package publishing rights, maintainer accounts, and CI/CD tokens all carry the ability to alter production software, the organisation inherits cumulative trust it did not explicitly design. That is identity trust debt: privileged access that has been spread across too many human and machine identities to audit cleanly. Practitioners should treat every publishing path as a governed identity boundary.

Shai-Hulud shows why secret sprawl and package trust fail together. A worm does not need novel exploitation if build systems already expose tokens, keys, and metadata endpoints. The article’s lesson is that secrets management, developer authentication, and artifact provenance are one control plane in practice, even if teams manage them separately. Security teams should unify these controls before the next malicious update chain starts.

Phishing-resistant authentication is necessary, but it is not sufficient. Hardware keys and better login hygiene reduce initial compromise, yet the attack also relied on exposed CI secrets, reusable tokens, and weak release governance. That means package ecosystems need privileged workflow controls, not only stronger login controls. The practitioner conclusion is to secure the publish path end to end.

Package signing and workflow integrity need to become default assumptions. The article references Sigstore and Cosign because release provenance matters when attacker-controlled identities can publish legitimate-looking artifacts. Signed packages, protected workflows, and bounded token scope make it harder for a stolen identity to masquerade as a trusted maintainer. Practitioners should raise provenance verification into normal release governance.

Non-human identities in software pipelines deserve the same review discipline as human admins. API keys, tokens, service principals, and pipeline credentials can all move an attack forward without a human ever logging in during the incident. That makes lifecycle control, rotation, and anomaly detection essential, not optional. Practitioners should inventory machine identities with the same seriousness they apply to privileged humans.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Our research also found that organisations maintain an average of 6 distinct secrets manager instances, which creates fragmentation that weakens centralised control.
• For a broader breach pattern view, the 52 NHI Breaches Analysis shows how identity compromise repeatedly turns trust relationships into downstream exposure.

What this signals

Identity trust debt: as software pipelines accumulate maintainer accounts, API keys, and automation tokens, the blast radius of one compromise expands faster than most governance models can track. The practical response is to map publishing rights, signing rights, and secret ownership as a single control surface, then review it like any other privileged access estate.

With 43% of security professionals already concerned that AI systems may learn and reproduce sensitive patterns from codebases, secret handling is now part of software resilience, not a narrow DevSecOps issue. Teams that still rely on static tokens in build paths are creating exposure that survives account recovery, credential rotation delays, and routine developer churn.

The next control gap is provenance, not just detection. As package ecosystems continue to be used as distribution channels, organisations need signed releases, protected workflows, and clear revocation paths that can invalidate poisoned artifacts before they reach production. Practitioners should assume future attacks will target the path of trust, not only the source code itself.

For practitioners

• Classify package publishing as privileged access Require step-up verification, release approvals, and separate admin roles for package publication so maintainer compromise cannot directly alter artifacts.
• Shorten the life of CI/CD secrets Replace long-lived npm, GitHub, and cloud tokens with ephemeral credentials, least privilege scopes, and automated rotation tied to job execution.
• Add provenance checks to builds Verify signed artifacts and enforce workflow integrity so downstream pipelines do not trust a package solely because it came from a familiar registry.
• Scan for leaked tokens continuously Monitor repositories, build logs, and developer endpoints for exposed credentials and treat every finding as an active non-human identity exposure event.
• Segment release paths from development paths Isolate build agents, restrict publishing permissions, and use separate trusted environments for signing so a compromised workstation cannot publish directly.

Key takeaways

• Shai-Hulud turned identity compromise into package propagation, proving that npm supply chain risk is really a trust-and-access problem.
• The breach shows how quickly developer credentials, machine tokens, and CI/CD secrets can convert one compromised maintainer into widespread downstream exposure.
• Teams should respond by tightening publish controls, shortening secret lifetimes, and treating package provenance as a core security requirement.

Key terms

• Non-Human Identity: A non-human identity is any credentialed software or machine actor that can authenticate and perform actions, including service accounts, API keys, tokens, certificates, and AI agents. In practice, these identities often outnumber humans and can move faster, stay hidden longer, and create broader blast radius when compromised.
• Identity trust debt: Identity trust debt is the accumulation of unchecked access paths, long-lived secrets, and inherited trust relationships that make compromise easier to spread. It appears when organisations scale publishing, automation, and integration without equally strong lifecycle controls, leaving attackers with many ways to reuse one stolen credential.
• Software provenance: Software provenance is the evidence that shows where an artifact came from, who created it, and whether it was altered before use. For security teams, it means signed releases, controlled build paths, and verification steps that reduce the chance of trusted software carrying hidden malicious changes.

Deepen your knowledge

Shai-Hulud, package publishing trust, and CI/CD secret exposure are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for developer identities and machine identities from a similar starting point, it is worth exploring.

This post draws on content published by CyberArk: Sandworm in the supply chain, lessons from the Shai-Hulud npm attack on developer and machine identities. Read the original.