We are tracking a major resurgence of the Shai-Hulud malware campaign, now emerging as a new variant referred to as “Sha1-Hulud: The Second Coming.” This outbreak has already outgrown the original Shai-Hulud incident, with more than 800 npm packages confirmed as trojanized and tens of thousands of GitHub repositories affected, spreading rapidly across multiple maintainers, including the Zapier and ENS ecosystems. The malicious versions embed credential-stealing payloads designed to capture developer tokens, leak secrets, and establish persistent footholds across repositories and developer environments. This page will be updated continuously as the investigation progresses and additional compromised packages are identified.
In the previous attack, the threat actor abused npm’s postinstall lifecycle script to quietly slip code into execution during installation. The current variant follows the same pattern but uses a preinstall script instead. The preinstall script triggers an initialization loader script setup_bun.js with no prompts, no warnings, and no opportunity to intervene, ensuring the infection begins the moment installation starts.
From there, the loader launches bun_environment.js—a massive bundled JavaScript file carrying the full attack chain.
.png)
.png)
In this second wave, Sha1-Hulud introduces a far more aggressive fallback mechanism: if the malware fails to authenticate or establish persistence, it attempts to destroy the victim’s entire home directory. Specifically, the malware deletes every writable file owned by the current user under their home folder. This destructive logic triggers only when all of the following conditions are met:
- It cannot authenticate to GitHub
- It cannot create a GitHub repository
- It cannot fetch a GitHub token
- It cannot find an NPM token
In other words, if Sha1-Hulud is unable to steal credentials, obtain tokens, or secure any exfiltration channel, it defaults to catastrophic data destruction. This marks a significant escalation from the first wave, shifting the actor’s tactics from purely data-theft to punitive sabotage.
.png)
This second wave also introduces abuse of GitHub’s legitimate infrastructure to gain remote code execution on the victim’s machine. Upon successful authentication, the malware deploys a GitHub Actions runner, turning GitHub workflows into the attacker’s command interface.
The malware creates a public GitHub repository in the victim's account with discussions explicitly enabled. It then installs the official GitHub Actions runner in a hidden directory ~/.dev-env/ and uploads a weaponized workflow file .github/workflows/discussion.yaml configured with two critical properties:
- Trigger: on: discussion — Activates whenever any discussion is created
- Execution Target: runs-on: self-hosted — Forces execution on the victim's machine

The workflow pulls the discussion body and executes it directly, causing each discussion post to execute as a command on the victim:
‍run: echo ${{ github.event.discussion.body }}
Because the repository is public, any GitHub user can create a discussion and trigger arbitrary command execution on the victim's machine with full user permissions. The runner polls GitHub continuously, executing commands within seconds of a discussion being posted. This technique effectively turns GitHub Actions into a stealthy, attacker-controlled RCE channel operating through the victim’s own account.
Subscribe for live updates
hubspot-form
What to Do?
Organizations should act quickly to contain the impact of the Sha1-Hulud Second Coming campaign.
- Begin by scanning across all endpoints - developer machines, build servers, and CI/CD agents - for the presence of impacted packages (Koi customers already got alerts for relevant packages)
- Any compromised versions should be removed immediately, and we recommend temporarily freezing npm package updates until the full scope of the attack is understood (Koi customers are protected via Version Cooldown and network guardrails)
- Next, perform a complete credential rotation, including GitHub, npm, AWS, GCP, and Azure tokens, since the malware is designed to harvest secrets from multiple environments
- Audit your repositories for persistence mechanisms by reviewing .github/workflows/ for suspicious files such as discussion.yaml or unexpected branches
- As part of hardening your build pipeline, ensure that all automated environments use npm ci instead of npm install when installing dependencies. Unlike npm install, which may modify the dependency tree or execute unexpected lifecycle scripts, npm ci installs strictly from the committed lockfile and avoids introducing unvetted changes during builds. This helps prevent malicious postinstall activity like that used in the Shai-Hulud campaign and ensures that CI/CD agents build from a predictable, tamper-resistant dependency set.
- Finally, reboot the affected machine to terminate the runner process, since the backdoor does not persist across restarts
These steps will help reduce risk and limit attacker footholds while the investigation and cleanup continue.
Need Help?
Concerned your organization may be affected? Reach out to us for expert guidance on detecting compromised packages and mitigating this supply-chain attack.
IOCs
bun_environment.js
62ee164b9b306250c1172583f138c9614139264f889fa99614903c12755468d0[SHA256]f099c5d9ec417d4445a0328ac0ada9cde79fc37410914103ae9c609cbc0ee068[SHA256]cbb9bc5a8496243e02f3cc080efbe3e4a1430ba0671f2e43a202bf45b05479cd[SHA256]
setup_bun.js
a3894003ad1d293ba96d77881ccd2071446dc3f65f434669b49b3da92421901a[SHA256]



