Shai-Hulud shows why npm supply chain security needs identity controls

At a glance

What this is: This article examines the Shai-Hulud npm supply chain worm and shows how it used stolen tokens, malicious package code and workflow abuse to spread.

Why it matters: It matters because software teams need to govern CI/CD identities, publishing rights and secret exposure as tightly as they manage application code and dependencies.

Context

The core problem is not just malicious npm code. It is that build and publishing systems often trust tokens, workflows and package provenance more than they should, which lets an attacker move from a compromised dependency into a wider software delivery environment.

In supply chain attacks, the security boundary is no longer the repository alone. CI/CD runners, package registries, workflow permissions and exposed secrets all become part of the attack surface, and that creates a direct governance problem for NHI, secrets and workload identity controls.

Key questions

Q: What breaks when a malicious npm package can read developer secrets during install?

A: The main failure is that package execution inherits identity context it should never need. Once a malicious install can read environment variables, local files, and CI secrets, it can steal credentials that survive beyond the original infection. That turns a code dependency problem into an access-control incident, because the attacker gains reusable authentication material, not just a one-time foothold.

Q: Why do standing CI/CD tokens create so much risk in supply chain attacks?

A: Standing tokens remain usable long after the moment they were created, so a compromise can persist through normal operations and even through partial remediation. In supply chain environments, that means one stolen token can be reused to push artefacts, alter tags, or seed downstream packages. Short-lived access and verifiable revocation are the controls that reduce that exposure.

Q: What are the signs that a package compromise is reaching developer systems?

A: Watch for unexpected outbound network requests from Python processes, temporary payload files in system directories, and interpreter activity tied to package import rather than normal application flow. Those signals indicate that package execution has crossed from dependency loading into active payload delivery.

Q: How should security teams respond when a trusted JavaScript package is compromised?

A: Treat the event as both a supply-chain incident and a secrets exposure risk. Freeze affected builds, inventory every direct and transitive dependency, rotate any token or API key that may have touched the compromised runtime, and validate that package provenance is clean before redeploying. The goal is to stop inherited trust from becoming inherited compromise.

Technical breakdown

How malicious npm packages turn trusted installs into execution

npm packages can execute code during installation through post-install scripts, which means a dependency is not just static content. If an attacker controls the package or a maintainer account, the package can run commands, inspect environment variables, contact external services or modify local files as soon as it is installed. That makes package trust a runtime problem, not only a source-control problem. In Shai-Hulud-style attacks, the package itself becomes the execution vehicle inside developer machines or CI jobs. The control gap is usually weak provenance, excessive package trust and insufficient restrictions on what install-time code can do.

Practical implication: treat package installation as code execution and restrict what install-time scripts are allowed to access.

Why tokens and workflow permissions become the real target

The attacker objective is often not the package itself but the identities behind publishing, automation and repository access. npm tokens, GitHub tokens and CI credentials let a worm publish new malicious versions, create workflows and reach additional repositories or secrets. In identity terms, those tokens act as machine identities with standing privilege, often without tight lifecycle governance or scope limits. Once one token is stolen, the attacker can reuse the same trust relationship across multiple systems. This is where supply chain compromise becomes an identity compromise: the malware is simply riding on authorised credentials and poorly bounded workflow permissions.

Practical implication: scope publishing tokens and workflow credentials as tightly as privileged admin accounts.

How runtime monitoring exposes secret harvesting and propagation

Runtime controls matter because many supply chain attacks only reveal themselves after the malicious code starts behaving differently from legitimate packages. Indicators can include child process spawning, unusual outbound connections, access to cloud metadata endpoints, repository creation or suspicious secret-scanning activity from a build agent. eBPF- or LSM-based runtime monitoring gives defenders visibility into those behaviours at execution time, which is when exfiltration and propagation actually occur. This is especially relevant in CI/CD, where automation can spread the compromise quickly. A package review process alone will not catch a malicious action that only appears once the code is installed and running.

Practical implication: instrument CI/CD and developer environments for process, network and secret-access anomalies during package execution.

Threat narrative

Attacker objective: The attacker aims to turn trusted software delivery identities into a propagation channel for secret theft and downstream package poisoning.

1. Entry occurs when a maintainer account, publishing token or workflow credential is abused to push malicious npm code into a trusted package.
2. Credential access follows when the payload harvests npm tokens, GitHub credentials, environment variables and other secrets from developer or CI contexts.
3. Escalation and propagation happen when stolen tokens are reused to publish more packages, create workflows and extend the worm into additional repositories.
4. Impact is secret leakage, poisoned package distribution and broader downstream compromise across organisations that consume the affected libraries.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.

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

Identity controls are now part of software supply chain defence. This attack pattern shows that package trust alone is insufficient when publishing tokens, workflow credentials and CI identities can be reused after compromise. The governance failure is not just weak dependency review, but standing machine access that can be repurposed for propagation. Practitioners should treat npm publishing and CI credentials as governed identities, not simple convenience tokens.

Shai-Hulud is a model for credential-powered supply chain propagation. The worm did not need to break cryptography or exploit a deep platform flaw to spread. It leveraged legitimate automation paths, which means the control problem sits in lifecycle management, scope reduction and runtime observation. That makes the relevant question whether build and release identities are bounded enough to stop reuse after theft.

Secret leakage and provenance failure reinforce each other. When secrets are discoverable in environment variables, logs or developer machines, malicious package code can harvest them quickly. When provenance is weak, defenders lose confidence in what should be allowed into a build in the first place. The named concept here is credential-powered package propagation: a supply chain failure mode where one stolen token becomes the mechanism for repeated compromise. Practitioners need to govern both the credential and the artifact path.

Runtime containment is the missing layer most teams underweight. Static inspection of dependencies cannot explain what a package does once installed, which is where secret scanning, external callbacks and repo creation become visible. This is why supply chain defence must join identity, provenance and runtime policy instead of treating them as separate programmes. The practitioner conclusion is to design for blast-radius reduction, not just package cleanliness.

Third-party exposure turns local compromise into shared risk. The article’s breach pattern is broader than one maintainer account because npm ecosystems are heavily interconnected and trust is transitive. That means third-party publishing rights, delegated workflows and reused secrets become governance issues for the whole software estate. Teams should assume downstream propagation is the default failure mode unless identities are tightly scoped and observed.

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.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Credential-powered package propagation: the key failure mode here is not just malicious code in a dependency, but legitimate automation identities being reused to spread that code. Teams that still separate software supply chain security from identity governance are leaving the real attack path ungoverned.

CI/CD runners and publishing tokens are now high-value identities, not plumbing. As attackers learn to move from package compromise to workflow abuse, the governance focus has to shift from dependency trust to controlled issuance, scoped access and runtime containment.

For practitioners

• Tighten CI/CD publishing permissions Remove broad publish rights from build identities and require explicit approval for package releases, workflow changes and registry access.
• Scan for exposed secrets before publish Continuously inspect repositories, build logs and environment variables for npm tokens, GitHub credentials and cloud keys before they can be harvested.
• Enforce package provenance and attestation Block unverified packages from internal builds and require signed, traceable provenance for dependencies and release artifacts.
• Monitor runtime behaviour in developer and CI environments Alert on child-process spawning, unusual network calls, metadata-service access and unexpected repository creation from package execution.
• Prepare a token revocation and rebuild playbook Define how to rotate credentials, unpublish or replace packages, and rebuild affected pipelines when a supply chain compromise is detected.

Key takeaways

• Shai-Hulud shows that npm supply chain compromise is also an identity problem because publish tokens, workflow permissions and build credentials can be repurposed for propagation.
• The breach pattern matters because malicious install-time code can steal secrets and use authorised automation to spread beyond the first compromised package.
• Identity scope, provenance enforcement and runtime monitoring are the controls most directly able to reduce blast radius when package trust fails.

Key terms

• 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 runner: A CI/CD runner is the execution environment that performs build, test, or deployment jobs. It often has access to source code, tokens, and cloud credentials, which makes it a high-value identity surface when workflows are compromised.
• Package provenance: Package provenance is the ability to prove where software came from, who published it, and whether it has been modified before installation. In MCP sprawl, weak provenance means installation can happen faster than trust can be established, which increases secret exposure risk.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management and agentic AI identity. It helps practitioners connect identity controls to the delivery pipelines and operational risks their programmes actually face.