Shai-hulud shows why static secrets still fuel supply chain worms

At a glance

What this is: Defakto Security analyses the Shai-Hulud npm supply chain worm and shows that static secrets, not exotic exploitation, powered its spread across packages, repos, and cloud-connected tooling.

Why it matters: IAM and NHI teams need to treat long-lived tokens as propagation fuel because one compromised secret can turn developer and CI/CD access into a supply chain outbreak.

By the numbers:

• The worm spread through more than 300 compromised packages in days.
• Early reporting put the number of infected packages around 180-200.

Context

Shai-Hulud is a supply chain worm that spread through the npm ecosystem by abusing the secrets already present in developer and CI/CD environments. In practical terms, the security problem is not code execution alone but the trust granted to static credentials that persist across builds, repositories, and cloud services.

That matters for non-human identity governance because package publishing, build automation, and developer tooling often rely on long-lived tokens with broad privilege. When a single credential can be reused to publish packages, access repos, and query cloud metadata, the identity model itself becomes part of the propagation path.

The incident is a familiar pattern, not an isolated edge case. What changed here was the speed and the breadth of secrets harvested, not the basic failure mode: unmanaged, persistent credentials remain too easy to steal and too useful once taken.

Key questions

Q: What breaks when static secrets are used in npm supply chains?

A: Static secrets turn a supply chain compromise into a propagation event because the same credential can be reused to publish malicious packages, access repositories, and reach cloud services. The failure is not only exposure but persistence. Once a token survives beyond one task, attackers can weaponise it across multiple systems.

Q: Why do long-lived automation tokens increase supply chain risk?

A: They increase risk because a stolen token remains valid long enough to be copied, reused, and chained into additional compromise steps. In a worm scenario, standing privilege and broad scope let one secret fuel many actions. That makes the issue an identity design problem, not only a secret hygiene problem.

Q: What signs suggest a build or publishing flow is overexposed?

A: Look for credentials stored in environment variables, shared config files, developer machines, or metadata services, especially when the same identity can publish code and reach cloud resources. Those patterns indicate the flow is carrying secrets with more access than the task requires, which is exactly what supply chain worms exploit.

Q: Should teams prioritise key rotation or dynamic identity for package publishing?

A: Dynamic identity should come first when package publishing or CI/CD relies on reusable secrets with broad reach. Rotation still leaves the organisation managing stored credentials and reacting after compromise. Ephemeral identities reduce the number of reusable secrets in circulation and remove the easiest path for worm propagation.

Technical breakdown

How the worm used post-install execution to harvest secrets

Shai-Hulud relied on a post-install script embedded in infected npm packages. That script ran automatically on installation and searched for credentials in environment variables, local files, cloud metadata services, and developer tooling. The important architectural point is that the package did not need a sophisticated exploit chain. It used ordinary execution rights inside build and developer contexts to reach secrets that were already present. Once those secrets were collected, the worm could reuse them across repositories and publishing workflows. In NHI terms, the package became a credential collection point, not just malicious code.

Practical implication: Treat post-install execution in package supply chains as a credential exposure event, not just a software integrity issue.

Why static credentials gave the worm propagation power

Static secrets are durable because they are designed to survive across sessions, jobs, and environments. That persistence creates standing privilege, which means a stolen token can be reused until someone notices and revokes it. In this incident, GitHub tokens, npm publish tokens, and cloud credentials became the fuel for republishing malicious packages and expanding access. Rotation helps only after compromise and only if the organisation can find every copy. The underlying weakness is that a persistent secret remains valid long enough to be weaponised across multiple systems.

Practical implication: Map every long-lived publish and automation token to a revocation owner and a defined expiry path.

Why dynamic identities change the control model

Dynamic identity replaces stored credentials with short-lived, task-scoped authentication issued at runtime. That changes the trust model from possession of a reusable secret to proof of identity for a specific workload at a specific moment. For package publishing and CI/CD, this means the authorisation window is narrow and the credential disappears when the job ends. The architectural value is not just less rotation effort. It is that there is no durable secret to steal, reuse, or copy into attacker-controlled repos. In effect, the attack surface shifts from secret custody to runtime issuance and policy control.

Practical implication: Move high-risk publishing and automation flows toward ephemeral, runtime-issued identities rather than reusable tokens.

Threat narrative

Attacker objective: The attacker objective was to turn one infected package into a self-propagating supply chain worm that harvested reusable credentials and used them to spread further.

1. Entry occurred when infected npm packages executed a post-install script inside developer and build environments and began searching for exposed secrets.
2. Credential access followed as the worm dumped environment variables, queried cloud metadata services, and scanned files for GitHub, npm, Atlassian, and Datadog credentials.
3. Escalation and propagation happened when stolen tokens were pushed into attacker-controlled repositories and then used to publish more poisoned packages.
4. Impact was the broad compromise of npm supply chain assets, CI/CD contexts, and cloud-connected tooling at scale.

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).
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Static secrets create a propagation layer, not just an exposure layer. Once a token can be reused across package publishing, source control, and cloud access, it becomes part of the attacker's distribution mechanism. Shai-Hulud showed that the compromise path does not stop at theft; the same credential can be used to publish more malware and widen the blast radius. Practitioners should treat every persistent secret as a possible propagation asset.

Key rotation is a containment tactic, not a structural answer. Rotation reduces how long a stolen secret remains useful, but it still assumes the secret exists, is found, and can be retired before reuse. In a worm scenario, that assumption is weak because the attacker can act faster than governance cycles. The practical conclusion is that rotation cannot be the primary trust model for high-risk non-human identities.

Ephemeral credential trust debt: The longer organisations depend on stored automation tokens, the more they accumulate trust that can only be repaid through cleanup after compromise. That trust debt shows up as secret sprawl, unclear ownership, and broad permission scope across build systems. The implication is that identity programmes must reduce the number of credentials that can outlive a single task, not just improve how they are rotated.

Supply chain worms expose the limits of infrastructure-only thinking. The incident was enabled by identity behaviour as much as by package execution. Build systems, developer laptops, and cloud metadata services all became identity surfaces because they held reusable secrets. NHI governance therefore needs to sit alongside supply chain security, not underneath it as a back-office control.

Dynamic identity is becoming the default control boundary for automation. Where workloads, pipelines, and publishing flows can authenticate without storing a reusable secret, the attacker's options shrink materially. That does not eliminate compromise, but it removes the easiest path from one infected artifact to many. Practitioners should re-centre controls on runtime issuance and explicit scope rather than permanence.

From our research library:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
• Read next: Guide to NHI Rotation Challenges

What this signals

Dynamic credential issuance, not faster rotation, is the relevant programme shift. The Shai-Hulud pattern shows that once a credential can be reused across packaging, source control, and cloud access, the organisation has already accepted a propagation path. Teams should therefore design build and publishing workflows so the identity disappears when the task ends, rather than hoping rotation will outrun abuse.

Supply chain security and NHI governance now overlap at the point of issuance. Static secrets create an audit trail after the fact, but they do little to limit the first compromise's reach. Programmes that still depend on persistent automation tokens should watch for where task-scoped authentication can replace stored credentials without breaking delivery.

For practitioners

• Eliminate reusable publish tokens Replace long-lived npm, GitHub, and cloud automation tokens with short-lived identities issued at runtime for each publishing or build task.
• Inventory secret-bearing build paths Trace where environment variables, metadata services, and local files expose credentials in developer and CI/CD environments, then remove the highest-value exposures first.
• Bind automation to task scope Limit each non-human identity to one publishing or deployment purpose so a stolen credential cannot be reused across repos, workflows, and cloud services.
• Retire standing privilege from pipeline identities Review automation accounts that persist across jobs and move them toward task-scoped issuance, automatic expiry, and explicit ownership.

Key takeaways

• Shai-Hulud exposed a supply chain weakness in which static secrets enabled a package worm to spread beyond the initial infection point.
• The incident reached hundreds of compromised packages in days, showing how quickly reused credentials can widen blast radius.
• The limiting control is not faster rotation alone but reducing the number of long-lived secrets that can be stolen and replayed.

Key terms

• Static Secret: A secret, such as an API key or password, that does not change automatically over time. Static secrets require manual or scheduled rotation and represent a higher security risk than dynamic secrets or managed identities.
• Dynamic Identity Generation: Dynamic identity generation is the practice of creating machine identities on demand rather than relying on long-lived, reusable credentials. This reduces standing trust and helps limit the blast radius of compromise. It is especially useful in automated pipelines, managed services, and environments where connections change frequently.
• 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.
• 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.

Deepen your knowledge

NHI governance, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.