Shai-hulud worm resurfaces in destructive npm supply-chain attack

The Shai-hulud worm just climbed back out of the npm ecosystem, and this time it hits harder. In its first wave, the Shai-hulud npm worm already showed how fast a self-replicating supply-chain attack can move through open-source packages and GitHub repositories. Now a new variant, often labeled “Sha1-hulud”, adds a far wider blast radius and an unmistakably punitive streak: when it cannot steal secrets, it attempts to wipe the victim’s home directory.

Security teams that treated the first Shai-hulud incident as a one-off now face a much louder message: this worm family looks ready to evolve in waves, not disappear.

𝗙𝗿𝗼𝗺 𝘁𝗵𝗲 𝗳𝗶𝗿𝘀𝘁 𝗦𝗵𝗮𝗶-𝗵𝘂𝗹𝘂𝗱 𝗼𝘂𝘁𝗯𝗿𝗲𝗮𝗸 𝘁𝗼 𝘁𝗼𝗱𝗮𝘆’𝘀 𝗻𝗽𝗺 𝘀𝘂𝗽𝗽𝗹𝘆-𝗰𝗵𝗮𝗶𝗻 𝘄𝗼𝗿𝗺

Back in September, the original Shai-hulud worm targeted the npm ecosystem with a self-replicating campaign that abused compromised developer accounts. Attackers stole npm maintainer credentials, logged into the registry as those maintainers, and pushed trojanized versions of legitimate packages. Every poisoned package contained logic that harvested additional secrets and tampered with other projects under the same maintainer, which allowed the worm to fan out across the ecosystem with minimal manual effort. 

That first wave already hit hundreds of repositories and high-profile packages. Researchers identified wormed packages in projects with massive download counts and deep integration into CI/CD pipelines and cloud workloads. The core playbook looked clear: abuse npm tokens, alter every reachable package, exfiltrate credentials to attacker-controlled GitHub repositories, then ride those secrets into more environments.

Defenders responded by removing malicious versions, rotating keys, and reviewing build systems. However, many teams treated Shai-hulud as a painful incident instead of a pattern. The new wave closes that illusion.

𝗡𝗲𝘄 𝘃𝗮𝗿𝗶𝗮𝗻𝘁: 𝗣𝗿𝗲𝗶𝗻𝘀𝘁𝗮𝗹𝗹 𝗲𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 “𝗦𝗵𝗮𝟭-𝗵𝘂𝗹𝘂𝗱” 𝗯𝗿𝗮𝗻𝗱𝗶𝗻𝗴

The current campaign reuses the Shai-hulud lineage but pushes it into a more invasive phase. Researchers now track the variant as “Sha1-hulud” in many reports. Instead of running after installation or at runtime only, the malware executes during the npm preinstall phase. That timing matters because it reaches developer laptops, CI runners, and other build nodes even when the application never fully launches the malicious code path.

During preinstall, the Sha1-hulud variant:

• Collects developer and CI/CD secrets such as GitHub access tokens and cloud credentials.

• Writes intermediate data into local JSON files (cloud.json, contents.json, environment.json, truffleSecrets.json) to stage exfiltration.

• Uses GitHub workflows and attacker-controlled repositories to move stolen secrets out of the environment.

Meanwhile, the campaign spreads through compromised maintainer accounts again. Attackers take control of widely used npm packages linked to ecosystems like ENS Domains, PostHog, Postman, and Zapier and push backdoored releases that carry the worm. Those packages appear in a large share of real-world environments, which multiplies the number of potential victims each time a poisoned version lands in a dependency tree. 

𝗣𝘂𝗻𝗶𝘁𝗶𝘃𝗲 𝘀𝗮𝗯𝗼𝘁𝗮𝗴𝗲: 𝘄𝗵𝗲𝗻 𝘁𝗵𝗲 𝘄𝗼𝗿𝗺 𝗰𝗮𝗻’𝘁 𝘀𝘁𝗲𝗮𝗹, 𝗶𝘁 𝘄𝗶𝗽𝗲𝘀

The most alarming change in this wave sits in the fallback logic. When the new Sha1-hulud variant fails to steal credentials or open a usable exfiltration channel, it does not simply exit. Instead, it pivots into destructive behavior.

Koi Security’s analysis notes that when exfiltration fails, the malware attempts to delete every writable file owned by the current user under their home directory. In other words, if the worm cannot monetize a victim through secrets, it tries to punish them by wiping their workspace.

That shift from pure data theft to punitive sabotage raises the stakes for developers and build operators. A compromised machine no longer only leaks credentials; it may lose local source trees, cached artifacts, and configuration files. On a developer laptop, that kind of wipe can stall active work and silently destroy unpushed changes. On a self-hosted CI runner, it can disrupt pipelines and erase local secrets that administrators forgot to treat as critical.

𝗛𝗼𝘄 𝘁𝗵𝗲 𝗦𝗵𝗮𝗶-𝗵𝘂𝗹𝘂𝗱 𝘄𝗼𝗿𝗺 𝗺𝗼𝘃𝗲𝘀 𝘁𝗵𝗿𝗼𝘂𝗴𝗵 𝗻𝗽𝗺 𝗮𝗻𝗱 𝗚𝗶𝘁𝗛𝘂𝗯

At a high level, the Shai-hulud worm family follows a repeatable pattern. The new wave keeps that structure but tightens the screws:

First, attackers obtain or brute-force access to npm maintainer accounts, or they leverage previously stolen tokens that still grant publish rights. With those privileges, they release modified versions of popular packages. Each trojanized package embeds install-time logic that immediately runs when a victim installs it directly or as a transitive dependency. 

Next, the malware collects secrets from local configuration files, environment variables, and sometimes cloud metadata endpoints. It then pushes those secrets into GitHub repositories whose descriptions reference “Shai-Hulud” or “Sha1-Hulud: The Second Coming”, effectively turning GitHub into a staging area for stolen credentials. Because many victims run npm installs inside CI, the worm often lands on machines that already hold automation tokens with broad access. 

Finally, the campaign uses automation to alter additional packages under the same compromised maintainers. In past waves, the worm republished entire maintainer portfolios after injecting its payload. In this wave, it also deploys malicious GitHub Actions workflows and self-hosted runners that give attackers durable remote execution on infected projects. Those workflows can exfiltrate further secrets, then remove themselves to reduce obvious forensic traces. 

Because the attack chain relies heavily on existing automation npm lifecycle scripts and CI workflows Shai-hulud behaves less like a one-shot backdoor and more like an ecosystem parasite.

𝗪𝗵𝘆 𝘁𝗵𝗶𝘀 𝘄𝗮𝘃𝗲 𝗵𝗶𝘁𝘀 𝘀𝗼 𝗺𝗮𝗻𝘆 𝗿𝗲𝗽𝗼𝘀𝗶𝘁𝗼𝗿𝗶𝗲𝘀

Reports from several research teams converge on one uncomfortable number: this Sha1-hulud campaign touches tens of thousands of GitHub repositories and hundreds to roughly a thousand npm packages. That scale stems from three reinforcing dynamics. s in the npm graph such as utilities from major SaaS vendors and open-source tooling ecosystems appear in a significant percentage of production environments. Once attackers compromise even a few of those packages, they inherit reach into a huge fraction of pipelines.

Second, modern development practices rely heavily on transitive dependencies. Teams often track only direct dependencies while thousands of nested packages flow in unchecked. When the Shai-hulud worm lands in a transitive dependency, it still executes on install and still exfiltrates secrets, even if no one adds it explicitly to a package.json file.

Third, traditional monitoring rarely focuses on developer endpoints and build hosts with the same rigor that production workloads receive. That blind spot gives Shai-hulud a comfortable habitat: it thrives on machines that hold powerful credentials but run with softer detection and weaker hardening.

𝗛𝗼𝘄 𝘁𝗼 𝗿𝗲𝗮𝗰𝘁 𝗶𝗳 𝘆𝗼𝘂 𝘀𝘂𝘀𝗽𝗲𝗰𝘁 𝗦𝗵𝗮𝗶-𝗵𝘂𝗹𝘂𝗱 𝗲𝘅𝗽𝗼𝘀𝘂𝗿𝗲

When you suspect exposure to Shai-hulud or Sha1-hulud, treat it as a full supply-chain incident, not a routine malware alert. You should move on three fronts at the same time: detection, containment, and credential hygiene.

For detection, search your environments including CI runners and developer endpoints for known indicators of compromise, such as the characteristic JSON files the malware writes, references to Shai-hulud in GitHub repository descriptions, and suspicious workflows or runners that appeared recently. You also want to review npm install logs, build logs, and dependency graphs for known affected packages from current advisories.

For containment, remove compromised package versions from projects and lock builds to known-good versions. In some cases, you may need to temporarily freeze npm updates while you verify dependency trees and review your internal package mirrors. That pause hurts velocity, but it prevents a chaotic mix of clean and poisoned builds while the investigation unfolds.

For credential hygiene, rotate everything that a compromised machine or CI job could have touched: npm tokens, GitHub personal access tokens, SSH keys, and cloud credentials for AWS, GCP, and Azure. Short-lived, scoped tokens make that step much less painful next time, so this wave also gives you a strong case to accelerate secure token management work you postponed earlier. 

𝗛𝗮𝗿𝗱𝗲𝗻𝗶𝗻𝗴 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿 𝗲𝗻𝗱𝗽𝗼𝗶𝗻𝘁𝘀 𝗮𝗻𝗱 𝗰𝗶/𝗰𝗱 𝗽𝗶𝗽𝗲𝗹𝗶𝗻𝗲𝘀 𝗮𝗴𝗮𝗶𝗻𝘀𝘁 𝗦𝗵𝗮𝗶-𝗵𝘂𝗹𝘂𝗱

You gain long-term leverage when you treat developer machines and build pipelines as first-class security assets, not side channels. That mindset change matters more with each Shai-hulud wave.

On developer endpoints, you should deploy endpoint detection tuned for developer workflows, not generic office profiles. Monitor for unusual npm behaviors, unexpected GitHub Actions files appearing in repositories, and network connections to unknown GitHub repositories or artifact stores. At the same time, you can constrain where developers store long-lived tokens and how they authenticate to registries and cloud services.

Inside CI/CD pipelines, you should assume dependencies can execute hostile code during install. You can reduce that risk by disabling or restricting lifecycle scripts such as preinstall on shared runners where practical, enforcing strict egress rules from build nodes, and using short-lived automation tokens with tightly scoped permissions. Combined, those steps reduce the blast radius when a wormed package inevitably slips through. 

𝗧𝗿𝗲𝗮𝘁𝗶𝗻𝗴 𝘁𝗵𝗲 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝘀𝘂𝗽𝗽𝗹𝘆 𝗰𝗵𝗮𝗶𝗻 𝗮𝘀 𝗰𝗿𝗶𝘁𝗶𝗰𝗮𝗹 𝗶𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲

The Shai-hulud worm no longer looks like an oddity. It now illustrates a category of self-replicating supply-chain threats that treat open-source registries and automation platforms as a single, shared attack surface. When you step back, the pattern becomes hard to ignore: attackers view the software supply chain as critical infrastructure. Defenders need to mirror that stance. 

Supply-chain security leaders already recommend three broad shifts. First, monitor developer endpoints and treat them as high-value assets rather than lightly protected workstations. Second, exert more control over npm lifecycle scripts and other install-time execution paths, because those hooks now sit at the center of real-world attacks. Third, modernize token handling so that plaintext, long-lived credentials do not linger on disk across your ecosystem. Short-lived, scoped credentials and artifact signing move you in that direction.

When you design your own guardrails around maintainers, publishing workflows, CI/CD environments, and runtime consumption of dependencies, you build a structure that shrinks the room Shai-hulud can move in. You cannot prevent every compromise, but you can contain the spread and blunt the impact.

𝗪𝗵𝗮𝘁 𝘁𝗵𝗶𝘀 𝗻𝗲𝘅𝘁 𝘄𝗮𝘃𝗲 𝘁𝗲𝗹𝗹𝘀 𝘀𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝘁𝗲𝗮𝗺𝘀

In this new campaign, the Shai-hulud npm worm adopts a more aggressive posture. It still steals secrets at scale. Now it also threatens to wipe home directories when exfiltration fails, and it leans harder on CI/CD integration through GitHub Actions and self-hosted runners. That trajectory points at a future where supply-chain worms behave more like full-blown ecosystem parasites with hybrid motives monetization, access, and punishment.

Security teams that respond only by cleaning up this wave miss the bigger lesson. You now have a live example that shows how rapidly a determined actor can push destructive logic into thousands of repositories by abusing everyday tooling. The right response combines tactical cleanup with strategic hardening, so the next self-replicating campaign has far less room to grow.

𝗙𝗔𝗤𝘀

What is the Shai-hulud worm in the npm ecosystem?
The Shai-hulud worm is a self-replicating malware family that targets npm packages and GitHub repositories. It spreads by abusing compromised maintainer accounts, injecting malicious install-time code into packages, stealing secrets from developer and CI/CD environments, and then using those secrets and accounts to infect additional packages and projects.

How does the new Sha1-hulud variant differ from the original Shai-hulud wave?
The new Sha1-hulud variant executes during the preinstall phase, which exposes developer laptops and build systems earlier in the pipeline. It targets a wide range of secrets GitHub tokens, npm credentials, and multi-cloud keys and it adds a destructive fallback: when it cannot exfiltrate data.

How can teams check whether their npm projects pulled in malicious Shai-hulud packages?
Teams should review dependency graphs and lockfiles for known affected packages from current advisories, then cross-reference those names and versions against the latest lists from security vendors and ecosystem partners. They should also inspect npm install logs, CI build outputs.

What should a developer do if they suspect their account or tokens were exposed?
A developer should immediately revoke and regenerate all relevant credentials, including npm tokens, GitHub personal access tokens, SSH keys, and any cloud access keys that may live on the same machine. They should also notify their security team, review recent commits and publishes for unauthorized changes.

Which long-term measures matter most to prevent the next Shai-hulud wave?
Long-term, teams gain the most by securing maintainer identities with strong MFA, enforcing safer token handling, controlling npm lifecycle scripts in CI/CD, tightening egress from build systems, and monitoring developer endpoints for supply-chain abuse patterns. Artifact signing and stricter review for dependency changes also help, because they make it harder for wormed packages to move silently into production.