Microsoft’s security teams have issued an urgent, unambiguous warning: treat the recent Shai‑Hulud 2.0 supply‑chain worm as an active, high‑risk incident and rotate any exposed credentials immediately — including GitHub personal access tokens (PATs), npm tokens, and cloud API keys — because the worm steals secrets and uses them to propagate automatically across developer accounts, CI runners and repositories.
Shai‑Hulud began as a September 2025 npm compromise and has resurfaced in a much more aggressive second wave labeled Shai‑Hulud 2.0 (also reported as Sha1‑Hulud). The campaign trojanizes npm packages by inserting a preinstall/postinstall payload that executes on package installation, harvests credentials and CI secrets from developer machines and build agents, and then uses those credentials to republish malicious package versions or create GitHub repositories that publicly expose stolen secrets. The result is worm‑like propagation within the open‑source and developer ecosystem. Security vendors and incident investigators (Koi Security, Kroll, ReversingLabs and others) have documented hundreds of compromised packages and tens of thousands of GitHub repositories created by the campaign’s exfiltration routines, but telemetry counts vary across vendors; defenders should assume broad exposure rather than rely on any single number.
Vendors and researchers will refine counts and provide additional IOCs in the coming days. Until then, treat every developer token, CI secret and repo publish capability as potentially compromised and act quickly. The cost and effort of proactive rotation, isolation, and hardened publish controls are far lower than the cost of prolonged, automated exfiltration and cloud compromise.
Act now: rotate, isolate, hunt, and harden — the clock favors the team that moves first.
Source: Forbes Microsoft Worm Attack Warning — Act Rapidly And Change Passwords Now
Background / Overview
Shai‑Hulud began as a September 2025 npm compromise and has resurfaced in a much more aggressive second wave labeled Shai‑Hulud 2.0 (also reported as Sha1‑Hulud). The campaign trojanizes npm packages by inserting a preinstall/postinstall payload that executes on package installation, harvests credentials and CI secrets from developer machines and build agents, and then uses those credentials to republish malicious package versions or create GitHub repositories that publicly expose stolen secrets. The result is worm‑like propagation within the open‑source and developer ecosystem. Security vendors and incident investigators (Koi Security, Kroll, ReversingLabs and others) have documented hundreds of compromised packages and tens of thousands of GitHub repositories created by the campaign’s exfiltration routines, but telemetry counts vary across vendors; defenders should assume broad exposure rather than rely on any single number. How the worm works — a technical breakdown
Microsoft’s technical write‑up and independent analyses converge on a consistent attack chain that explains why this is particularly dangerous for developers, CI/CD pipelines and cloud workloads.1. Trojanized package installs execute before typical checks
Compromised npm packages include a malicious preinstall script (commonly named setup_bun.js or set_bun.js) that either locates an existing Bun runtime or installs a bundled runtime to execute a large obfuscated payload (bundle.js / bun_environment.js). This code runs during the install lifecycle — before many CI security checks, static scans or human review steps.2. Local credential harvesting
The payload executes TruffleHog and other scanning routines to search local filesystems, environment variables and configured credential stores for tokens — including npm tokens, GitHub PATs, AWS/GCP/Azure keys, and CI service secrets. Found secrets are exfiltrated and (in many observed cases) written to attacker‑controlled or newly created GitHub repositories.3. Persistence via GitHub Actions and runner installs
The worm installs or configures GitHub Actions workflows and sometimes registers a GitHub Actions runner under attacker control (or using stolen tokens). This creates an automated, persistent exfiltration channel inside CI/CD that can re‑run during builds and persist beyond the initial host compromise.4. Automated republishing (worm propagation)
Where the attacker obtains publish rights (via stolen npm tokens or account access), the malware repackages and republishes new versions of packages maintained by the compromised account. That behavior converts each compromised maintainer into a distribution node, causing exponential spread through transitive dependency graphs.5. Public exposure and destructive fallback
In multiple incidents, the worm created public repositories that contained exfiltrated secrets and in some variants includes destructive logic (attempting to wipe user files when certain conditions aren’t met). These aggressive behaviors amplify operational impact and the pressure to act quickly. Vendor telemetry shows different counts for packages and repos, but the consensus is: scale is large and growing.What Microsoft and major responders are telling organizations to do — immediate checklist
Microsoft Defender researchers, CISA, and multiple industry responders have issued overlapping emergency guidance. The list below distills the highest‑urgency actions defenders must prioritize immediately (hours to 72 hours):- Rotate and revoke all exposed tokens: Revoke GitHub PATs, npm tokens, cloud provider keys (AWS, Azure, GCP), and any CI/CD service tokens that could have been present in developer or runner environments. Treat all tokens as compromised until proven otherwise.
- Isolate and rebuild CI runners: Take self‑hosted runners offline, delete unknown runners, and recreate build agents from hardened, clean images with rotated credentials.
- Audit Key Vaults / secret stores: Review Azure Key Vault and equivalent secret manager access logs and rotate keys/secrets for any identity that shows anomalous or unexpected access. Prioritize vaults and identities exposed via developer or CI paths.
- Remove high‑risk permissions: Remove unnecessary roles and publish rights from identities tied to pipelines and developer accounts; enforce least privilege and credential scoping.
- Hunt with vendor queries: Run the hunting queries published by Microsoft Defender and other vendors in EDR/XDR and SIEM to locate preinstall activity, runner installs, exfiltration flows, and postinstall persistence artifacts.
- Take infected packages out of build pipelines and replace with pinned SHAs: Where possible, pin dependencies to known good SHAs and rebuild artifacts from vetted sources rather than relying on latest tags.
Why this campaign is qualitatively worse than many past supply‑chain incidents
- Executes before security checks: Because payloads run during preinstall, they evade many supply‑chain defenses that inspect package content only after installation.
- Targets secrets, not just code: The worm focuses on credentials — tokens and keys that allow lateral movement into cloud and CI — rather than purely pushing malicious application code to end users. That gives attackers direct access to infrastructure.
- Automated propagation using legitimate tooling: By abusing npm publish flows and GitHub Actions, it blends malicious traffic into normal developer workflows and creates many legitimate‑looking commits and artifacts that complicate detection and takedown.
- Rapid, automated exfiltration to public services: Publishing stolen secrets to GitHub makes exfiltration obvious but also durable — copies may be forked, mirrored or cached before takedowns succeed. Different vendors report wildly differing counts, but the operational reality is “large and ongoing.”
Conflicting telemetry and what defenders should assume
Vendor reports for infected packages and leaked repositories are inconsistent: some reports list hundreds of compromised packages; others suggest several hundred to over a thousand; GitHub‑search counts and vendor sampling differ widely. Rather than rely on a precise tally, teams should assume broad exposure, hunt for artifacts aggressively, and prioritize rotation of any credentials that might be reachable from developer machines or CI environments. Expect counts to remain inconsistent as takedowns and mirror removals continue.Attribution and caution — what we do and don’t know
Some vendor narratives and commentators have tentatively linked Shai‑Hulud activity to known groups and previous campaigns, but attribution in supply‑chain incidents remains difficult and often speculative. Microsoft’s advisories focus on technical detection and mitigation rather than definitive public attribution; defenders should prioritize response over chasing early attribution narratives. Flag any unverified attributions as provisional and pursue authoritative confirmation before acting on those claims.Practical, prioritized remediation playbook (operational timeline)
Within 0–24 hours — triage and stop the bleeding
- Revoke and re‑issue all high‑value tokens and keys (GitHub PATs, npm tokens, cloud API keys). Do not assume an old token is safe after partial mitigation.
- Hold or freeze automated publish pipelines until you can validate all maintainers and tokens. Disable automatic dependency updates where practical.
- Take self‑hosted CI runners offline; rebuild from known clean images and rotate any credentials they used.
24–72 hours — hunt and remediate
- Use vendor‑published hunting queries in Defender XDR, your EDR and SIEM to locate installer artifacts, runner installs, or instances where bundle.js or setup_bun.js executed.
- Audit Key Vault / secret manager access logs, focusing on service principals and identities tied to developer workflows. Rotate any secrets that show suspicious sign‑ins.
- Pin dependencies to verified SHAs, and remove suspect package versions from builds. Rebuild production images from clean sources.
1–4 weeks — restore and harden
- Enforce trusted publishing: require 2FA / WebAuthn for package publishes, use scoped tokens and minimum privileges, and implement publishing policies that prevent arbitrary publishes from unverified accounts.
- Harden CI: disable postinstall scripts in CI where feasible or run installs inside tightly controlled sandboxes; require GitHub Actions approvals and signed commits for publish actions.
- Adopt attack‑path analysis and continuous exposure scanning to spot cross‑domain linkages from dev endpoints into key vaults and production resources.
Developer and organizational hardening — concrete recommendations
- Rotate frequently and scope tokens: Avoid long‑lived tokens. Use service principals and short‑lived credentials where possible. Scope tokens narrowly (publish only, not full admin).
- Require strong publish controls: Use npm and GitHub capabilities to require WebAuthn 2FA for publishing, restrict who can publish, and prefer organization‑managed publish flows.
- Treat developer endpoints as sensitive infrastructure: Apply endpoint protections, attack surface reduction rules, and block execution of obfuscated scripts unless they meet a trusted list criterion.
- Disable auto‑update chains in production and CI: Avoid late‑stage runtime installs of dependencies in production images; rebuild from locked artifacts.
- Use commit signing and provenance checks: Enforce commit signature verification for critical repos, prefer SBOMs and reproducible builds, and pin package SHAs in manifest files.
Why incident speed matters — the automation problem
This worm weaponizes automation: it finds a token, uses it to republish or configure runners, and then extends its reach without human intervention. That automation compresses the window defenders have. The faster teams rotate secrets and isolate runners, the more likely they are to break the worm’s feedback loop. Delay prolongs the attacker’s ability to harvest new tokens and republish across maintainers.Risks, tradeoffs and residual questions
- False negatives and visibility gaps: Non‑interactive installs and CI runs can be invisible to monitoring that focuses on interactive user sessions, so defenders must broaden log coverage and alerting.
- Token sprawl and third‑party exposures: Tokens often exist in developer machines, third‑party services and ephemeral runner environments. Locating and rotating all variants is operationally difficult and time‑consuming.
- Counts vs. impact: Different telemetry sets give different package and repository counts. That variance should not lull teams into complacency; assume worse‑case exposure and act accordingly.
- Attribution uncertainty: Public attribution remains tentative in many vendor write‑ups. Defenders should prioritize containment and recovery over attribution until law enforcement or multi‑vendor evidence proves otherwise.
What Windows and Microsoft 365 administrators specifically should check now
- Audit developer workstations and build servers for signs of Bun runtime installs, setup_bun.js or bundle.js artifacts, and any unusual GitHub repository creations tied to internal accounts.
- For organizations using Defender for Cloud / Defender XDR, enable cloud‑resource mapping to link images and build pipelines to the code repositories used to build them; this accelerates identification of affected workloads.
- Review WSUS, Intune and Windows Update distribution pipelines for unexpected processes or downloads that could indicate laterally repurposed infrastructure; although WSUS is not the primary vector here, update infrastructure is a crown jewel and must be monitored.
Conclusion — the right posture to stop a wormed supply chain
Shai‑Hulud 2.0 is a watershed supply‑chain incident because it weaponizes developer automation and secrets into a self‑propagating attack that outruns many standard defenses. The core defensive moves are straightforward but operationally heavy: rotate and revoke credentials immediately, isolate and rebuild CI runners, hunt for persistence, and harden publishing and CI policies to remove the attacker’s ability to automate propagation.Vendors and researchers will refine counts and provide additional IOCs in the coming days. Until then, treat every developer token, CI secret and repo publish capability as potentially compromised and act quickly. The cost and effort of proactive rotation, isolation, and hardened publish controls are far lower than the cost of prolonged, automated exfiltration and cloud compromise.
Act now: rotate, isolate, hunt, and harden — the clock favors the team that moves first.
Source: Forbes Microsoft Worm Attack Warning — Act Rapidly And Change Passwords Now
