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

At a glance

What this is: Shai-Hulud was a self-propagating npm worm that spread by stealing static secrets from build and developer environments.

Why it matters: It matters because identity teams must treat secrets sprawl, standing privilege, and runtime credential design as one governance problem across NHI, CI/CD, and human-operated workflows.

By the numbers:

• Early reporting from Wiz, Sonatype, and Krebs put the number of infected packages around 180 to 200.
• 300, e outlets now put the total above 300, including CrowdStrike-maintained packages.
• Shai-Hulud compromised 300+ npm packages in days.

👉 Read Defakto Security's analysis of the Shai-Hulud npm supply chain worm

Context

Shai-Hulud is a supply chain worm that moved through npm packages by stealing secrets rather than breaking cryptography. The primary problem is not package compromise alone, but the identity trust model underneath it: static tokens, publish credentials, and cloud secrets that remain valid long enough to be reused elsewhere.

For IAM and NHI programmes, the lesson is that developer tooling, CI/CD pipelines, and workload credentials now share the same attack surface. When a single secret can be copied, replayed, and reused across systems, rotation becomes a cleanup task after exposure instead of a control that prevents blast radius.

Key questions

Q: What breaks when static secrets are used in npm and CI/CD pipelines?

A: Static secrets break because they can be copied, reused, and replayed long after the original job completes. In a supply chain worm, one exposed token can publish malicious code, access adjacent systems, and expand compromise without needing a new exploit. The real failure is durable trust in a credential that should never have persisted.

Q: Why do static tokens increase lateral movement risk in software supply chains?

A: Static tokens increase lateral movement risk because they often authenticate across multiple tools, repositories, and cloud services. Once stolen, the same credential can be used to move from package installation into publishing, source control, and automation. That makes blast radius a governance issue, not just a detection issue.

Q: How do security teams know whether secret rotation is actually working?

A: Rotation is working only if stolen credentials become unusable quickly enough to prevent reuse. If a token still authenticates across several systems, or if it remains valid for long periods after exposure, the control is not reducing blast radius enough. The stronger signal is whether the environment can function without persistent secrets at all.

Q: Who is accountable when a supply chain worm spreads through exposed secrets?

A: Accountability sits with the teams that own secret issuance, pipeline design, and repository access, not just with incident responders after the fact. Governance frameworks such as the NIST Cybersecurity Framework and OWASP Non-Human Identity Top 10 both point to access control, lifecycle management, and secure automation as shared responsibilities.

Technical breakdown

How Shai-Hulud turned static secrets into propagation fuel

The worm dropped a post-install script into infected npm packages, then searched local files, environment variables, and accessible tooling for credentials. That meant GitHub tokens, npm publish tokens, cloud keys, and other secrets became the payload, not the target. Once harvested, those secrets enabled the attacker to publish more poisoned packages and widen the infection chain without needing a new exploit.

Practical implication: reduce the number of places where secrets can exist in build and developer environments.

Why key rotation cannot stop a secret-harvesting worm

Key rotation shortens exposure, but it does not remove standing trust from the credential model. If a token is valid when stolen, the attacker can still use it before the next rotation cycle. In supply chain attacks, that delay is enough to publish malware, alter repositories, and pivot into adjacent systems. The control problem is persistence, not cadence.

Practical implication: replace long-lived publish credentials with short-lived, scoped runtime identity where possible.

What dynamic identity changes in npm and CI/CD pipelines

Dynamic identity issues a credential only when a workload runs, scopes it to a specific task, and expires it automatically after use. That removes the durable secret the worm depends on. In practice, this shifts trust from stored tokens to verifiable runtime identity, which is a better fit for pipelines, automation, and package publishing workflows that do not need permanent access.

Practical implication: redesign pipeline authentication so jobs authenticate ephemerally rather than reusing stored secrets.

Threat narrative

Attacker objective: The attacker’s objective was to harvest reusable secrets and turn one compromised package into a self-propagating supply chain infection.

1. Entry began with compromised or malicious npm packages that executed a post-install script on installation, creating initial access to developer and build environments.
2. Credential access followed as the script hunted for GitHub tokens, npm publish tokens, cloud metadata credentials, API keys, passwords, and other secrets in files, environment variables, and logs.
3. Escalation occurred when stolen credentials were used to create attacker-controlled repositories, push malicious workflows, and publish additional poisoned packages, allowing the worm to propagate further.
4. Impact was a rapidly expanding supply chain infection across hundreds of packages, with exposed credentials extending the blast radius into cloud, CI/CD, and adjacent SaaS environments.

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

Static credential persistence is the failure mode this worm exploited. The article shows that the issue was not token theft in isolation, but the fact that secrets remained valid, reusable, and spread across developer, CI/CD, and cloud environments. That is a governance failure, not a tooling quirk. The implication is that programmes built around static credential stewardship are managing the symptom after the compromise has already happened.

Key rotation was designed for exposure management, not for secretless trust. That assumption fails when an attacker can harvest and reuse a token within the same propagation window. In this case, rotation cadence did not matter because the credential itself was the attack fuel. The implication is that security teams must distinguish between reducing exposure time and eliminating the durable secret class altogether.

Secret sprawl becomes identity blast radius when one credential can authenticate across multiple systems. The worm used GitHub, npm, cloud, and automation secrets as interchangeable access material, which means the boundary between application security and identity governance has already collapsed. A secret is no longer just a secret when it can publish code, access storage, and alter workflows. Practitioners need to treat every reusable token as a cross-domain identity event.

Dynamic runtime identity is the structural response, not a faster rotation schedule. The article’s strongest strategic point is that ephemeral, task-scoped credentials change the attacker’s economics by removing durable material to steal. That aligns with NHI governance thinking: access should exist only for the job, only for the moment, and only for the workload that needs it. The implication is that secretless design is now a governance requirement for high-risk automation.

Secret reuse across pipelines and packages is the named governance concept this attack exposes. When the same credential can be found in build systems, developer machines, and publishing workflows, compromise of one location becomes compromise of the whole process chain. The control gap is not just duplication, but the absence of lifecycle boundaries for secrets that outlive their intended task. Practitioners should read this as a signal that secret governance must move from inventory to containment.

From our research:

• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 62% of all secrets are duplicated and stored in multiple locations, creating unnecessary redundancy and increasing the risk of accidental exposure.
• Read Guide to the Secret Sprawl Challenge for the operational patterns behind secret sprawl and exposure paths.

What this signals

Secret sprawl is now a supply chain resilience issue, not just an IAM housekeeping problem. When a worm can harvest reusable credentials from package installs, the programme question shifts from where secrets are stored to whether the business can operate without them. The relevant benchmark is not rotation frequency, but whether runtime identity can replace persistent secrets in the most exposed paths. For practitioners mapping that transition, the OWASP Non-Human Identity Top 10 remains a useful external reference point.

Secret reuse across pipelines creates identity blast radius. The same credential often spans source control, automation, and cloud access, which means one leak can trigger multiple downstream failures. Teams should trace where credentials are shared, duplicated, or injected into jobs, then decide which of those paths can move to ephemeral identity instead of persistent tokens.

Secret reuse across pipelines creates identity blast radius. With 62% of all secrets duplicated and stored in multiple locations, per The 2025 State of NHIs and Secrets in Cybersecurity, the control problem is structural. Teams should trace where credentials are shared, duplicated, or injected into jobs, then decide which of those paths can move to ephemeral identity instead of persistent tokens.

For practitioners

• Inventory every reusable credential in build and publish paths Map GitHub, npm, cloud, and CI/CD secrets to the jobs and repositories that can actually use them. Prioritise credentials that appear in environment variables, config files, logs, and package hooks, because those are the locations a worm can harvest first.
• Replace long-lived publish tokens with ephemeral workload identity Use runtime-issued identities for package publishing, deployment, and automation wherever the platform allows it. The goal is to remove secrets that can be copied and replayed, not just shorten their lifetime after exposure.
• Separate secret scope from repository scope Do not allow one token to authenticate across multiple applications, packages, or tenants. Narrow the token to a single task or environment so that compromise cannot automatically become lateral movement into adjacent systems.
• Harden post-install and CI execution paths Treat package install scripts, workflow runners, and automation hooks as high-risk execution points. Review where untrusted code can run before secrets are loaded, and stop mounting credentials into jobs that do not need them.
• Create a secret exposure response runbook Define what happens when a secret is found in a repo, log, or package artifact. The response should include revocation, impact assessment, and repository cleanup, because once a secret has been copied, containment depends on speed and scope clarity.

Key takeaways

• Shai-Hulud shows that static secrets remain a practical propagation mechanism for supply chain worms.
• The attack’s scale and speed demonstrate that key rotation cannot compensate for credentials that can be copied and reused across environments.
• The most effective governance response is to reduce secret persistence by moving high-risk automation toward ephemeral, runtime-issued identity.

Key terms

• Static Secret: A static secret is a credential that remains valid until it is manually changed or revoked. In practice, this includes tokens, API keys, and long-lived certificates. The governance problem is persistence: once copied, the secret can be reused across environments until someone notices and acts.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across repositories, logs, developer tools, tickets, and automation systems. It weakens central control because the same secret often exists in multiple places, increasing exposure and making revocation slower, harder, and more error-prone.
• Ephemeral Identity: Ephemeral identity is a short-lived, runtime-issued credential tied to a specific task, workload, or session. It reduces exposure by expiring automatically when the job ends. In NHI governance, this is the practical alternative to permanent secrets for high-risk automation.
• Identity Blast Radius: Identity blast radius is the amount of damage that can occur when one credential is compromised. It depends on how broadly the credential is shared, what systems it can reach, and how long it remains valid. Smaller blast radius comes from narrow scope and short lifetime.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Defakto Security: Shai-Hulud npm supply chain attack analysis. Read the original.