What Is the Shai Hulud npm Worm and How to Protect Against It

Shai Hulud didn’t invent a new supply chain weakness. It took advantage of something most teams already struggle with: long-lived credentials sitting on developer laptops and CI runners. Once it landed in a workstation or pipeline, it went hunting for secrets, then moved into GitHub, npm, and cloud environments.

The damage is huge. More than 25,000 GitHub repositories showed signs of credential exposure tied to the operation, and hundreds of npm packages were altered and republished as “normal” updates. 

Teams that treated non-human identity (NHI) security as a secondary layer discovered that the worm viewed those identities as primary targets. NHIs had more rights and seldom expired. When credentials outlive their usefulness, the Shai Hulud npm worm is a perfect illustration of how quickly a local compromise turns into an ecosystem issue.

What is the Shai Hulud npm Worm?

Shai Hulud 2.0 spread through legitimate packages that contained malicious preinstall scripts. Those scripts ran before installation finished and inherited the environment in which they executed. The worm used this position to inspect local files, gather tokens, and transmit them externally. Equipped with the victim’s npm credentials, it automatically backdoored and republished other packages the maintainer controls.

The pattern wasn’t complicated, but it was frustratingly effective. It waited for a normal install, ran its preinstall script, and searched for credentials with real reach. Once it had one, it republished a backdoored version under the maintainer’s identity and propagated through standard npm channels. Everything looked routine because, operationally, it was.

The worm targeted a predictable set of secrets, including npm tokens, GitHub credentials (e.g., PATs/SSH creds), and cloud API credentials (AWS/GCP/Azure), plus CI environment secrets where available. These secrets already existed because they enabled faster local development and pipeline automation. Because these tokens were long-lived, the worm could reuse them across systems, moving from a single machine into source control, registries, and cloud environments. This is why secret management can’t be treated as a side project, as these tokens are the worm’s fuel. 

This combination of availability, scope, and longevity created the conditions for rapid propagation. The worm did not need to be sophisticated. It only needed access to credentials that could reach beyond the machine it first compromised.

Why the Shai Hulud Worm Is Malicious

Shai Hulud is dangerous because it moves through trusted identity relationships that were never designed to defend against compromise. It does not rely on a single exploit. It relies on normal development workflows and the credentials those workflows expose.

The worm embeds itself in preinstall scripts that run automatically during dependency installation. From there, it focuses on harvesting credentials rather than disrupting systems. Access is the objective. Tokens that can touch source control, publishing, and cloud are worth more than the laptop or runner they were stolen from. 

With the right token, an attacker can change code and reach production-like systems without ever needing to “own” the original machine. The Shai Hulud worm spread by acting like a normal maintainer. It reused real npm tokens to republish packages, so the poisoned versions looked legitimate, and they flowed downstream the same way any routine update would.

Several factors make this behavior particularly damaging:

• Preinstall scripts run by default during dependency installation, often before most security controls or CI guardrails can run.
• Stolen credentials enable unauthorized publishing and changes to repositories.
• NHIs often hold broad, persistent permissions.
• Each new installation exposes additional environments and secrets.

The main issue Shai Hulud exploits is a growing web of interconnected identities that link development systems, such as CI pipelines and cloud resources, together. This factor gives attackers clear paths across environments with little resistance. 

Impact of the Shai Hulud Worm

The operational impact of Shai Hulud extended across development, CI, and production environments. What began as a dependency issue quickly exposed structural weaknesses that exist in many engineering organizations, particularly around credential handling and trust in automation.

At the supply chain level, the worm modified hundreds of npm packages. Teams had to audit both transitive and direct dependencies, frequently without knowing which builds had pulled compromised versions. Integrity verification became sluggish and insufficient as a result. That scramble is exactly what effective supply chain risk management is meant to prevent: clear containment boundaries and fast credential rotation.

After credentials were stolen, the compromise became more serious. Attackers were able to alter repositories, publish unapproved package versions, and initiate continuous integration workflows under false identities. The risk extended beyond source control into cloud environments. Several areas felt the impact most acutely:

• Pipeline instability: Malicious scripts were introduced into build systems and altered execution paths, leading to compromised artifact generation, test behavior, and deployment reliability.
• Maintainer impersonation: Actual npm publishing keys were used to distribute modified packages, thereby undermining ecosystem trust and raising concerns over the accuracy of updates.
• NHI compromise: Service accounts and automation identities became the easiest pivot points. Their permissions were broad, their activity rarely scrutinized, and the worm moved through them without triggering the alerts teams rely on for user abuse.

Once the stolen secrets surfaced in public repositories, containment became significantly harder. Those credentials no longer had a defined boundary, which forced organizations to rapidly revoke, replace, and reassess every access path tied to the affected identities.

How to Know if You Are Affected by the Shai Hulud npm Worm

You can detect potential compromise by focusing on deviations in dependency structure, identity behavior, and repository activity. Look for:

• Packages that include unexpected preinstall scripts, such as setup_bun.js
• New versions of your packages were published without approval.
• Publishing activity by unknown identities or service accounts.
• Unapproved changes to GitHub workflows or repository settings appear without a corresponding change record.
• Sudden creation of GitHub tokens tied to users or automation that do not normally mint credentials.
• Cloud activity that originates from unfamiliar locations or involves sudden increases in privilege.
• CI jobs that run commands or scripts outside the planned sequence.
• Public GitHub repos referencing Shai Hulud that contain your secrets.
• Any shift in NHI patterns is unlikely to be benign because their behavior is normally consistent.

Most early signals appear in automation layers. NHIs do not deviate from routine unless something external influences them. Monitoring that layer provides the strongest detection point.

7 Ways to Protect Against the Shai Hulud Worm and Similar Attacks

Catching the next malicious script is not the goal of defending against Shai Hulud, as most of that is reactive. Removing the access conditions that allow a single compromised dependency to become a multi-system incident is the real work. Here’s how.

1. Remove Standing Credentials Through Just In Time Access

Shai Hulud was effective because the credentials it discovered were already valid and already powerful, some that were never meant to be permanent. That persistence gave the worm time to reuse them across repositories, registries, and cloud environments. 

Just-in-Time (JIT) access changes that dynamic. Using a cloud-native access management platform like Apono, you can apply this model consistently across both human users and non-human identities. The result is that access is available only for the duration of a task. 

2. Enforce Least Privilege Across Developers, Pipelines, and NHIs

Over-permissioning is rarely intentional. It is usually the result of pressure, such as a pipeline failure and blocked release. So someone broadens access to get things moving again, and the permission is never revisited. Over time, identities accumulate rights they no longer need.

When one of those identities is compromised, every attached permission becomes available to the attacker. Limiting privilege to a specific action, environment, and time window prevents that cascade. 

3. Secure CI and CD Systems by Removing Embedded Secrets

Because CI pipelines are situated between source code and production systems, they are appealing targets. That bridge is exactly why CI hardening is inseparable from cloud data security; pipeline credentials often have direct paths to production cloud resources. The pipeline configuration contains static secrets that make that access reusable and long-lasting. Once uncovered, those secrets are perpetually replayable. A more resilient approach removes secrets from pipelines entirely. 

4. Restrict and Monitor Publishing Rights

Package publishing rarely gets much attention once it is working. Tokens are created to keep releases moving and then left in place because changing them is more likely to cause trouble than praise. Over time, no one is quite sure who owns those credentials or how often they should be reviewed.

Shai Hulud exploited that drift. It reused valid maintainer credentials and pushed altered packages through standard release mechanisms. Nothing about the process looked unusual, which is why the updates traveled as far as they did before anyone noticed.

Constraining publishing access changes that outcome. Limiting who can publish, what they can publish, and how long that access exists reduces the window for abuse. 

5. Apply Zero Trust Controls Across Development Tooling

In many environments and for teams, Zero Trust initially applies, but not much beyond. Credentials are accepted once and then reused by developer tools without reassessing context, and access persists until it is explicitly revoked, even when the surrounding conditions no longer exist. This is the gap that Shai Hulud exploits, as stolen credentials remain usable even when the original context no longer exists.

In practice, that persistence shows up in a few predictable ways:

• Credentials remain valid across sessions. Access continues from different machines.
• Changes in device state go unnoticed.

Let’s look at a real-world example. Apono takes a different approach, where access is treated as a continuous decision rather than a one-time event. Each request is evaluated using the current identity attributes and the state of the requesting device. When those conditions no longer meet policy requirements, access is denied instead of preserved. 

Source

6. Track NHI Behavior Continuously

Non-human identities operate on schedules, repeating the same actions and creating useful predictability. When something goes wrong, the signal usually appears as a deviation rather than a spike in activity. That might look like:

• access to resources that the identity has never touched before
• activity outside its normal execution window
• permissions being exercised in a new context

Changes in behavior, scope, and timing are often the first indication that an automation identity has been compromised. Deviations from established patterns tend to surface upstream, before activity becomes overtly malicious, which is exactly where worms like Shai Hulud gain their footing.

7. Strengthen Developer Workstations

Developer machines remain a common entry point because access accumulates quietly over time as tokens get cached, among other bad habits, to reduce workflow friction. Tooling continues to assume a high level of trust long after the original context has changed.

Removing stored tokens, requiring hardware-backed authentication, and using secrets scanning tools to catch exposed tokens before they land in commits or logs. More importantly, local access should never grant durable privileges into production systems. When access is temporary and tightly scoped, a compromised workstation no longer serves as a gateway to the rest of the environment.

Why Containing Worms Requires Containing Privilege

When access outlives intent, compromise stops being local. The Shai Hulud infection was able to spread through repositories, pipelines, and cloud systems more quickly than most controls were designed to stop, thanks to those access paths.

Apono breaks the continuity attacks Shai Hulud relies on. Access is issued when needed, removed when it is no longer required, and never left standing by default across development, CI, and cloud systems. When credentials expire, and privilege is tied to intent, a compromised dependency stays local instead of rippling outward.

Supply chain attacks will continue. The organizations that hold up best are the ones that control privilege as aggressively as they control code. That starts with understanding where standing access still exists, how long it persists, and which access paths create unnecessary blast radius.

To help teams take that first step, we’ve put together a practical Zero Standing Privileges (ZSP) Checklist – a quick way to assess your current access posture and identify where privilege needs to be tightened before the next incident tests it.