Shai Hulud npm worm exposed the cost of standing credential sprawl

At a glance

What this is: This is an analysis of the Shai Hulud npm worm and how it turned exposed developer and pipeline credentials into ecosystem-wide compromise.

Why it matters: It matters because IAM, NHI, PAM, and lifecycle teams have to treat long-lived non-human credentials as a primary attack surface, not an implementation detail.

👉 Read Apono's analysis of the Shai Hulud npm worm and secret exposure

Context

Shai Hulud is a supply chain worm that used trusted development paths, not a novel exploit chain, to spread through npm, GitHub, CI runners, and cloud environments. The primary keyword here is npm worm governance because the incident shows how package ecosystems become identity problems as soon as long-lived credentials are available.

The governance gap is simple: many programmes still assume developer and pipeline secrets are short-lived, tightly scoped, or easy to contain once discovered. In practice, those credentials often persist across tools and environments, which turns one workstation compromise into a wider NHI lifecycle failure.

For identity teams, the issue is not just malware detection. It is the combination of standing privilege, reusable tokens, and weak lifecycle discipline across developers, automation identities, and publishing workflows. That is why the right response sits across NHI governance, PAM, and secure software supply chain controls.

Key questions

Q: What breaks when npm install scripts can access long-lived credentials?

A: The install step stops being a safe execution boundary. A malicious preinstall script can read cached secrets, harvest tokens, and use legitimate identities to republish packages or access cloud systems. The failure is not only malware execution, but the presence of durable credentials in a context that assumes untrusted code cannot reach them.

Q: Why do standing NHI credentials increase supply chain blast radius?

A: Because the same token can often authenticate across repositories, registries, and cloud environments. When access persists after the task that needed it has ended, one compromise can spread laterally through trusted systems before anyone can revoke it. Standing privilege turns a local incident into an ecosystem problem.

Q: What do security teams get wrong about developer and CI secrets?

A: They often treat these secrets as operational conveniences instead of high-value identities. In practice, developer laptops and CI runners are rich credential stores, and tokens that remain valid for long periods are ideal for republishing, impersonation, and downstream access. Secrets should be governed like privileged access, not cache data.

Q: How should teams reduce the risk of package republishing abuse?

A: Use just-in-time publishing rights, separate maintainer credentials from day-to-day development access, and require explicit approval for release actions. Combine that with token rotation, workflow change monitoring, and rapid revocation so a stolen publishing identity cannot remain useful long enough to spread poisoned packages.

Technical breakdown

How the worm used preinstall scripts to gain execution

Shai Hulud relied on a normal npm behaviour: preinstall scripts run before installation completes and inherit the surrounding environment. That means a malicious package can inspect local files, environment variables, and cached credentials before most downstream controls have a chance to react. The key technical problem is not code execution alone, but execution in a context where secrets are already present. In supply chain terms, the package boundary becomes an identity boundary. If a developer laptop or CI runner holds reusable tokens, the script can harvest them without needing to break isolation first.

Practical implication: remove secrets from build and install contexts so package execution never occurs inside a credential-rich environment.

Why npm, GitHub, and cloud tokens became the propagation path

The worm targeted npm tokens, GitHub PATs and SSH credentials, cloud API keys, and CI environment secrets because those identities can reach far beyond the first infected machine. Once the attacker has a maintainer token, package republishing can look routine, and once cloud credentials are available, the compromise can extend into infrastructure. This is a classic NHI chaining problem. A single identity can authenticate across multiple planes of trust, and the worm only needs one reusable token to begin moving laterally through source control, registries, and cloud services.

Practical implication: classify publishing, repository, and cloud credentials as distinct trust domains and limit cross-domain reuse.

Why long-lived secrets made routine updates look legitimate

The worm was effective because it operated through normal release mechanics rather than forcing obvious failure. Maintainer identities, publishing permissions, and CI automation all behaved as expected from the outside, which made poisoned packages look like standard updates. The underlying failure mode is standing privilege. When an identity can publish repeatedly without re-authentication or just-in-time approval, compromise becomes durable. That is a governance issue as much as a technical one, because the environment treats reusable access as acceptable state instead of temporary exception.

Practical implication: replace persistent publishing credentials with time-bound, task-scoped access and revocation-by-default.

Threat narrative

Attacker objective: The attacker objective was to turn one trusted installation path into a repeatable mechanism for stealing credentials and republishing poisoned software under legitimate identities.

1. Entry occurred when the malicious package executed a preinstall script during a normal npm install and inherited the victim environment.
2. Credential access followed as the worm searched local files, CI variables, and cached tokens for npm, GitHub, and cloud secrets with reuse potential.
3. Impact emerged when stolen identities were used to republish packages, alter repositories, and extend compromise into cloud and pipeline 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

Standing credential trust is the broken premise this worm exposed. The article shows that long-lived developer, registry, and cloud secrets were treated as acceptable because they supported convenience and automation. That assumption fails when malware can execute inside the same environment that stores those secrets, because the credential outlives the context that justified it. The implication is that NHI governance must stop treating persistence as neutral state and start treating it as an exposure condition.

Package publishing is an identity governance problem, not just a software release problem. A maintainer token that can republish packages, alter repositories, and trigger downstream CI effectively behaves like a high-value NHI with broad blast radius. OWASP NHI and the NIST Cybersecurity Framework both point practitioners toward tighter access scope, verification, and recovery discipline. The practical conclusion is that publishing rights need lifecycle controls equal to their operational reach.

Shai Hulud demonstrates that identity reuse across tools creates identity blast radius. When the same credential can unlock source control, package registries, and cloud systems, the compromise domain expands faster than most teams can investigate. Identity blast radius: the total downstream damage created when one identity can traverse multiple trust boundaries. The lesson for practitioners is that cross-system reuse should be treated as a design flaw, not an efficiency gain.

Developer convenience has become a governance liability when it leaves tokens on laptops and runners. The worm did not require exotic privilege escalation, only access to the identities teams had left in place to keep workflows moving. That is a lifecycle failure across human, NHI, and CI contexts, because the same access survives changes in user state, machine state, and task state. Practitioners should read this as a signal that access review cadences are too slow for secrets that can be copied instantly.

Secret exposure and package integrity are converging into one control plane. The same incident ties together code repositories, npm publishing, CI environments, and cloud credentials, which means isolated point controls will miss the full chain. NIST CSF recovery and protect functions become relevant only if identity states are already bounded and revocable. The field-level takeaway is that supply chain security now depends on non-human identity governance as much as code scanning.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets in AppSec.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and they are 13% more likely to be categorised as critical than code-based leaks.
• For a broader breach lens, the 52 NHI Breaches Analysis shows how exposed credentials and lifecycle gaps repeatedly turn small footholds into wider compromise.

What this signals

Secret sprawl is now a control-plane problem, not a developer hygiene issue. If your programme still treats tokens in laptops, CI runners, and chat tools as edge cases, it will miss the propagation path that modern supply chain attacks actually exploit. With 28% of secrets incidents originating outside code repositories, the attack surface is already wider than most review processes assume.

Identity blast radius should become a first-class metric for release engineering. The question is no longer whether a secret exists, but how many systems it can reach before revocation. Teams that can map credential reuse across GitHub, npm, CI, and cloud will be better positioned to contain incidents before they become ecosystem events.

Standing privilege remains the structural weakness that keeps turning secret exposure into broad compromise. Lifecycle controls need to move faster than the credential reuse window, which is why short-lived access and revocation automation should sit alongside scanning and detection in the programme roadmap. For teams managing NHIs, this is a governance maturity issue as much as a security operations one.

For practitioners

• Remove standing secrets from build and install paths Strip npm, GitHub, and cloud credentials from developer and CI runtime environments so preinstall scripts cannot read reusable tokens during routine package installs.
• Scope publishing rights to time-bound approvals Treat package publishing as a privileged action that requires just-in-time access, short duration, and explicit revocation after each release.
• Segment credential domains by trust boundary Separate source-control, package-registry, and cloud credentials so one leaked token cannot cross from development tooling into production infrastructure.
• Monitor for abnormal republishing and workflow drift Alert on unexpected package versions, new repository workflow changes, and CI jobs that execute outside the planned release sequence.
• Rebuild workstation hygiene around secrets loss Remove cached tokens, require hardware-backed authentication, and scan commits and logs before they reach shared repositories.

Key takeaways

• Shai Hulud succeeded because persistent credentials were left in the same environments where malicious code could execute.
• The scale of the incident shows that package ecosystems and cloud access are now linked through reusable non-human identities.
• Automated revocation, short-lived publishing access, and removal of embedded secrets are the controls that would have reduced the blast radius.

Key terms

• Standing Privilege: Standing privilege is access that remains available after the immediate task or approval that justified it has ended. In NHI programmes, it is especially dangerous because tokens, keys, and service accounts can be copied and reused long after the original business need disappears.
• Identity Blast Radius: Identity blast radius is the downstream scope of damage created when one credential or account is compromised. It is determined by how many systems, repositories, registries, and cloud resources the identity can reach, and it grows quickly when credentials are shared across trust boundaries.
• Preinstall Script Abuse: Preinstall script abuse occurs when malicious package code runs during dependency installation and uses that execution context to inspect files, variables, or tokens. The risk is high because the script executes inside a trusted workflow that often already has access to valuable secrets.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across developer machines, CI systems, logs, chat tools, and repositories. It weakens governance because revocation, ownership, and review become harder as the same secret appears in more places and remains valid for longer.

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 Apono: What Is the Shai Hulud npm Worm and How to Protect Against It. Read the original.