Shai-Hulud v2 “Second Coming”: Inside the npm Supply Chain Worm

Sakibul Ali Khan December 3, 2025 Research

Introduction

Shai-Hulud v2 (“The Second Coming”) is a live reminder that npm install is effectively remote code execution on your laptops and CI. In late November 2025, a second, more aggressive wave of the Shai-Hulud npm worm appeared, abusing preinstall scripts, a fake Bun runtime, and GitHub Actions runners to steal secrets and backdoor pipelines at scale.

Across different vendors, we’re seeing ≈700–830+ malicious npm packages and 25k–28k+ public GitHub repos created or polluted with stolen secrets, including packages tied to Zapier, ENS Domains, PostHog, Postman and others (now cleaning up). If exfiltration or persistence fails, some variants attempt to wipe the user’s home directory, which is why this matters for individual developers in Bangladesh or anywhere as much as for big SaaS orgs.

How it works

Supply-chain basics: trust is the exploit

A supply-chain attack is successful when an attacker doesn’t have to break into your servers; they only need to land in something you already trust. Registries like npm (and, in other ecosystems, Maven) exist so developers can reuse packages. Maintainer accounts are the “keys to the kingdom”: compromise a maintainer (or any workflow that can publish on their behalf), and you can ship a malicious update that looks legitimate. Once that update is installed, one of the highest-leverage footholds is install lifecycle scripts such as preinstall, postinstall, and developers who run code automatically during dependency installation. That’s why “we only installed a library” can still become “we executed attacker code”.

Why CI/CD makes it catastrophic

CI/CD expands the blast radius because runners routinely carry secrets by design: GitHub tokens, npm publish tokens, cloud credentials, signing keys, and access to private repos. GitHub Actions also adds a powerful mixing bowl of trust boundaries: workflows can be triggered by PRs, run with elevated permissions, and interact with artifacts and caches. Multiple analyses of this wave highlight how automation identity becomes the pivot: once a token leaks, the attacker can create repos, commit files, register runners, and publish packages, so without “hacking” anything else.

Kill chain: from maintainer compromise to preinstall execution

In Shai-Hulud v2, the story typically starts with initial access and commonly described as compromised maintainers and, in at least some incidents, abuse of GitHub Actions workflow patterns that can expose secrets at PR time. From there a popular package gets a trojanized release that adds a preinstall hook. Researchers repeatedly document the same staging names: setup_bun.js (a loader) and bun_environment.js (the core payload). The loader ensures the Bun runtime exists, then uses it to run the payload, which is large and heavily obfuscated; in some writeups the payload forks into a detached background process so the install “looks normal” to the developer or CI log.

Secrets harvesting: turning dev + CI into a vault

Once bun_environment.js runs, the campaign shifts from “malicious package” to “account compromise at scale.” Reports describe broad harvesting from environment variables and local configuration (for example, npm tokens and GitHub tokens), plus cloud credential discovery across AWS/GCP/Azure paths when available. Several analyses also describe the attacker leveraging integrated secret scanners (notably TruffleHog) to extract additional secrets from repositories during CI execution, converting your own codebase into a searchable vault.

Exfiltration pattern: public GitHub repos as the drop-site

What makes this wave unusually visible is also what makes it effective: exfiltration is often performed by creating a new public GitHub repository under the victim’s account with a random name, marked with the description “Sha1-Hulud: The Second Coming”, and then uploading structured JSON files through normal Git operations or the GitHub Contents API. Researchers have documented filenames such as environment.json, system.json, cloud.json, and files tied to Actions secrets exfiltration (for example actionsSecrets.json), which can be created after pushing a malicious workflow (some reports name workflow artifacts like discussion.yaml).

How big is it?

Because numbers are moving while takedowns and new infections continue, it’s important to state scope carefully. As of December 3, 2025 (Asia/Dhaka), reporting on compromised npm packages varies widely depending on methodology: Socket describes 500+ packages and 700+ versions, while JFrog reports 459 publicly identified packages plus 337 additional findings (796 total) and 1000+ versions, and other trackers and analyses describe ~795–800+ as the campaign evolves. For GitHub exposure, sources range from roughly 25k affected repositories (Wiz) to ~27.8k results visible via GitHub search patterns (RedHunt), with Aikido showing ~26.3k repositories exposed in their snapshot. Readers should treat these as ranges and monitor the live trackers for the latest affected-package lists.

Shai-Hulud v2 “Second Coming”: Inside the npm Supply Chain Worm

Persistence + destructive behavior: runners and home-wipe risk

Shai-Hulud v2 also raises incident response urgency through persistence and potential destructive behavior. Multiple reports describe the payload registering a self-hosted GitHub Actions runner (often with a distinctive name such as “SHA1HULUD”) and hiding runner files under a directory like $HOME/.dev-env, which can turn a developer machine or a CI host into an attacker-controlled execution target long after the initial install. And several sources note that if the malware cannot authenticate to GitHub or npm (meaning it can’t exfiltrate or propagate), it may attempt to wipe files in the user’s home directory, which shifts priorities toward containment and forensics preservation early in the response.

Beyond JavaScript: Maven spillover and shared identities

Finally, while npm is the primary battlefield, there is reason for polyglot organizations to pay attention beyond JavaScript. Reporting notes limited Maven spillover, but even a small bridge matters when the same CI identities publish to multiple registries, and when build systems share tokens and runners across stacks. The victims named in public reporting include well-known ecosystem packages and organizations (including Zapier and ENS-adjacent packages), and the common thread is not “they wrote insecure code,” but that high-trust automation paths were available to be abused after credentials were exposed.

Conclusion

Shai-Hulud v2 shows that supply-chain incidents rarely stop at a “bad package” and they quickly become identity and CI/CD takeovers. This week, hunt for unexpected preinstall/postinstall behavior and staging files like setup_bun.js / bun_environment.js, plus suspicious GitHub activity such as newly created public repos labeled “Sha1-Hulud: The Second Coming,” odd workflow changes, and surprise self-hosted runners (often under $HOME/.dev-env). Contain by removing affected versions, rotating any exposed tokens (GitHub, npm, cloud), rebuilding compromised runners, and tightening Actions permissions and publishing paths so one leaked credential can’t restart the chain. After containment, do a quick retro: confirm what secrets were accessible to the compromised identities, review dependency-update history and lockfiles for the entry point, and document indicators for your team’s runbook. Longer term, prefer npm ci with lockfiles, basic dependency allow-listing (or a proxy registry), and stronger maintainer authentication so the next wave needs more than “someone ran npm install.”