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 long-lived credentials let it move from a compromised workstation or pipeline into GitHub, npm and cloud environments.

Why it matters: It matters because NHI and IAM teams have to treat standing credential sprawl as a propagation path, not just a hygiene issue, especially where developer and CI identities can publish, modify or pivot across systems.

Context

Shai Hulud is a supply chain worm that exploited long-lived credentials in developer and CI environments rather than a new software flaw. The security problem is standing access: when tokens, keys and publishing rights remain valid far beyond their original purpose, a single compromise can spread across code, registries and cloud.

For identity teams, the lesson is not limited to package ecosystems. Any environment where non-human identities can authenticate, publish, deploy or assume privileged actions without tight expiry and scope control can turn routine automation into an attack path.

The starting position described in the article is unfortunately typical. Development teams commonly keep durable credentials in place to reduce friction, which makes the attack pattern broadly applicable rather than exceptional.

Key questions

Q: What breaks when a compromised package can read secrets during installation?

A: The main failure is that package installation becomes an identity event. If the environment exposes tokens, keys, or certificates while a dependency executes, the attacker does not need application-level access first. They can steal reusable credentials and move into cloud, CI/CD, or internal systems that trust those secrets.

Q: Why do long-lived NHI credentials increase supply-chain risk?

A: They increase supply-chain risk because build systems, package installs, and developer tools can harvest and reuse them without a separate exploit chain. A long-lived credential stays useful long after the initial exposure, which means one compromise can extend into cloud, CI/CD, and secrets infrastructure.

Q: What are the signs that package-publishing access is becoming a governance problem?

A: Look for dormant publishing tokens, unreviewed maintainer accounts, package releases that do not match change records and automation identities with more reach than the task requires. Those are symptoms that publishing rights have drifted away from lifecycle control and are now acting as standing privilege.

Q: Should teams prioritise JIT access or secrets rotation first when defending against worms like Shai Hulud?

A: Prioritise JIT access first when the immediate issue is durable, reusable credentials that can be replayed across systems. Rotation still matters, but it does not remove the standing access window that lets a worm move from one compromised environment to another before anyone notices.

Technical breakdown

How malicious preinstall scripts turn package installs into credential harvesters

Shai Hulud did not need a novel exploit chain. It used legitimate npm package installation flow, specifically preinstall scripts that execute before installation completes and inherit the caller's environment. That execution context lets malicious code inspect local files, read cached secrets and search for tokens exposed to the process. In NHI terms, the package install became a credential collection surface because the build and developer environment granted more ambient access than the install operation needed. The worm then used the harvested credentials to move into publishing, source control and cloud scopes. This is a classic example of a trusted automation step becoming an identity trap.

Practical implication: remove secrets from install-time environments and stop assuming package execution is a low-risk context.

Why long-lived npm, GitHub and cloud credentials become propagation fuel

The worm targeted npm tokens, GitHub personal access tokens, SSH credentials and cloud API credentials because these secrets could be reused across systems. A long-lived credential is not just a password problem. It is a propagation primitive: once stolen, it can authenticate from new devices, new sessions and new contexts until someone revokes it. That makes token lifetime, scope and reuse the decisive controls. If a single credential can publish code, alter repositories and touch cloud resources, compromise is no longer local to one machine. The attacker only needs one durable identity path to move laterally through the development toolchain.

Practical implication: inventory where durable secrets can reach and shorten every credential's usable lifetime.

How package republishing and maintainer impersonation hide compromise in plain sight

The worm republished altered packages through normal release channels using real maintainer credentials. That matters because the downstream consumer sees an ordinary version update, not a security event. This is a trust-chain failure: package registries, CI systems and developers all assume publishing rights still belong to the original maintainer and that the maintainer's identity is stable. Once the attacker can exercise those rights, the package ecosystem itself becomes the delivery mechanism. The impact is amplified when repository state, publishing tokens and automation identities are not lifecycle governed as a single control plane.

Practical implication: tie publishing authority to explicit lifecycle review and revoke dormant package-publishing access quickly.

Threat narrative

Attacker objective: The attacker objective was to turn one compromised development foothold into reusable identity reach across source control, package publishing and cloud environments.

1. Entry occurred through a legitimate package install where malicious preinstall scripts executed inside a developer or CI environment.
2. Credential harvesting followed as the scripts inspected local files and collected npm, GitHub and cloud secrets with reuse potential.
3. Escalation happened when the stolen credentials were used to republish packages, alter repositories and access additional environments under trusted identities.
4. Impact was ecosystem-wide propagation through normal dependency and publishing workflows, with repository exposure and altered package versions spreading outward.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

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 sprawl is the real blast-radius multiplier: Shai Hulud succeeded because the compromised identities already had broad, persistent reach across repositories, registries and cloud. That is not a malware sophistication story. It is a governance failure in which durable access outlived the task it was meant to support. The practitioner conclusion is that exposure should be measured by reachable privilege, not by the point of initial compromise.

Long-lived credentials are no longer just operational convenience, they are propagation fuel: The worm used tokens that had enough breadth to publish, modify and pivot, which means the identity itself became the transport layer. OWASP-NHI treats secret leakage, long-lived secrets and overprivileged NHI as distinct problems for a reason. Once one credential can span multiple control planes, containment depends on identity lifecycle, not endpoint cleanup.

Package trust and identity trust have collapsed into the same problem space: Modern software supply chains assume the publisher, the repo maintainer and the automation identity are still aligned. Shai Hulud showed how quickly that assumption fails when secrets are reusable and rarely expired. The named concept here is identity blast radius: the set of systems a single credential can reach before governance catches up. Practitioners must govern that radius directly.

Developer and CI identities need the same lifecycle rigor as human accounts: The article shows a common misconception that only users require review while service accounts merely enable work. In practice, CI tokens, npm publishing keys and GitHub credentials often hold the highest-risk permissions in the environment. The implication is straightforward: access governance must cover non-human identities as first-class subjects, not as exceptions tucked inside engineering tooling.

Zero Trust loses value when credential context is not re-evaluated at issuance: The worm exploited the fact that once a token existed, it could be replayed across machines and sessions. That means continuous verification has to apply to non-human authentication paths, not only user sign-in flows. For practitioners, this is a warning that policy checked at login is not enough when the real action happens later through a standing secret.

From our research library:

• 30.9% of organisations store long-term credentials directly in code, according to the Ultimate Guide to NHIs.
• 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

Identity blast radius is the better planning unit than endpoint compromise: Shai Hulud shows that a workstation infection becomes a programme problem when one token can publish, deploy or alter multiple systems. Security teams should map the reachable scope of each NHI and remove any credential that can cross trust boundaries without fresh authorisation.

Developer tooling needs lifecycle governance, not just hardening: Cached secrets, package publishing rights and CI credentials behave like privileged identities, even when they are embedded in engineering workflows. That means access review, expiry and offboarding rules have to extend into build systems and source-control automation, not stop at human accounts.

For practitioners

• Eliminate standing publishing credentials Move npm publishing, repository write access and cloud API use toward short-lived, task-scoped authorization instead of reusable long-lived tokens.
• Remove secrets from CI and developer environments Stop storing durable tokens in pipelines, local config files and cached environment variables where preinstall scripts or build steps can read them.
• Constrain maintainer and automation privileges Review which identities can publish packages, alter repository settings or mint new tokens, then narrow those rights to the minimum reachable scope.
• Audit for cross-system credential reuse Map which GitHub, npm and cloud secrets are valid in more than one environment and treat every shared credential as an elevated propagation path.

Key takeaways

• Shai Hulud turned ordinary package installation and publishing paths into a credential propagation channel by exploiting long-lived secrets.
• The article cites more than 25,000 exposed GitHub repositories and hundreds of republished npm packages, showing how fast standing access can widen impact.
• The most effective control shift is to reduce reusable privilege at issuance time, because once secrets are replayable the compromise boundary has already failed.

Key terms

• Standing Credential: A standing credential is any secret that remains usable until it is manually rotated or revoked. In NHI governance, it creates durable access that can be stolen, replayed, or propagated from trusted tooling unless runtime boundaries and expiry are built in.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Preinstall Script Exposure: Preinstall script exposure is the risk created when package scripts run automatically before installation finishes and inherit the caller's environment. That execution context can reveal local files, cached secrets and automation credentials, which turns ordinary dependency handling into a credential collection opportunity.
• Publishing Identity: The account, token, or credential set that authorises changes to a software package distribution channel. It is a privileged non-human identity because it can affect many downstream systems at once, so compromise of this identity can become an ecosystem-wide security event.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.