Shai-Hulud Hit 25,000 GitHub Repos. Your `npm install` Is No Longer the Only Risk.

The Shai-Hulud npm worm compromised over 500 packages in its first September 2025 wave and eventually spread to more than 25,000 GitHub repositories by late November.

The latest Mini Shai-Hulud resurgence on May 11, 2026, hit 373 malicious versions across 169 packages. And Microsoft's follow-up analysis confirmed 170+ npm packages and 2 PyPI packages compromised across 404 malicious versions. For small teams and solo operators, this matters because the attack no longer waits for you to run `npm install`. Recent reporting shows the worm has evolved its propagation methods well beyond traditional package installation. So opening a cloned repository can trigger the payload before any package manager runs.

I run a one-person AI automation agency.

My client work lives in Node repositories.

I do not have a security team or a SOC. So when an attack turns the editor I live inside into a propagation vector, I treat it as a production incident, not a news item. This post is what I am doing about it and what you should do before your next dependency update.

The Worm's Evolution: From Post-Install Scripts to Editor Hooks

The original Shai-Hulud campaign in September 2025 used malicious npm versions with post-install scripts that harvested credentials and uploaded them to attacker-controlled public GitHub repositories named "Shai-Hulud."

The worm scanned environments for GitHub Personal Access Tokens, CI/CD tokens. And multi-cloud API keys for AWS, GCP, and Azure. Once it found an npm token, it authenticated to the registry as the compromised developer, injected code into other packages. And published new compromised versions. It spread without a centralized command-and-control server.

Checkmarx described it as "the first self-replicating supply chain attack, which uses GitHub Actions to infect repositories that consume any previously-infected package." That turned CI pipelines into propagation vectors.

By late November, Invicti reported the second wave, Shai-Hulud 2.0, had compromised roughly 600–800 npm packages and more than 25,000 GitHub repositories, including libraries from Zapier, ENS Domains, PostHog, Postman, and AsyncAPI.

Then in late April 2026, Mini Shai-Hulud appeared, initially targeting the SAP developer community.

By May 2026, Picus Security reported 373 malicious package versions across 169 npm package names. Snyk's timeline notes this was the first npm worm with valid SLSA Build Level 3 attestations and a session-based peer-to-peer C2 mechanism.

Microsoft's May 20, 2026 analysis stated the campaign compromised 170+ npm packages and 2 PyPI packages across 404 malicious versions, marking the first known supply-chain attack to span both npm and PyPI in a single operation.

The payload, per Microsoft, includes multi-platform credential theft from GitHub, AWS, HashiCorp Vault, npm, Kubernetes.

And 1Password, GitHub Action Runner process memory scraping, privilege escalation, dual-channel data exfiltration, and SLSA provenance forgery.

That is not a credential-stealing script. A toolset built to live inside your development environment for a long time.

Why This Changes the Threat Model for Small Teams

Most supply-chain advice assumes the danger is `npm install`.

Pin your versions, audit your lockfile, use a dependency scanner, done. The Shai-Hulud lineage breaks that assumption since it can compromise you before you install anything. If a cloned repository contains malicious VS Code `folderOpen` tasks or Claude Code SessionStart hooks, opening the project in your editor can execute the payload. The editor becomes the entry point, not the package manager.

For a solo operator or small business, this is worse than a typical breach given that the attack surface is also your productivity stack. I cannot stop using VS Code or Claude Code. I can only harden how I interact with repositories. The research as well shows that the worm abuses SLSA attestations, which means the integrity signals many teams trusted are now part of the forgery toolkit.

You cannot trust a package just as it has a valid attestation.

What I Am Actually Doing Now

I do not run a red team.

I run scripts and checklists. Here is the operational plan I am using for every client and personal repository going forward.

First, isolate the workspace before opening it.

I clone unknown or recently updated repositories into a disposable container or VM with no access to my main dotfiles, credentials, or SSH keys.

If the payload triggers on folder open, it hits a stripped environment. Second, inspect the repository before opening it in an editor. I check for `.vscode/tasks.json`, `.claude/`, `.github/hooks`. And any post-install or lifecycle scripts in `package.json` before the editor sees the directory. Third, rotate aggressively. If a project or any transitive dependency has touched a known Shai-Hulud package, I assume all local secrets are exposed and rotate GitHub PATs, npm tokens, cloud API keys. And any vault credentials stored in the environment. Fourth, scan the local environment after exposure. I look for unauthorized git remotes, modified hooks, and unexpected processes. The worm persists by installing hooks. So removing the malicious dependency is not enough if the hook is already in the project.

Fifth, I treat the lockfile as a living audit document.

Before every update, I check the diff for version jumps in packages I did not install directly. Most of the packages affected by these worms sit deep in the dependency tree. I do not know what `cacheable` or `keyv` does in my stack, but something I installed does.

The Uncomfortable Take: Attestations Are Not a Shortcut

Here is the contrarian angle: SLSA Build Level 3 attestations were supposed to make this kind of attack harder.

Mini Shai-Hulud showed they can be forged and used as cover.

That means the compliance checkbox approach to supply-chain security just got less useful. If you are a small business owner being told to "just use SLSA Level 3 artifacts," you should now ask what else is in the chain. Attestation verification is one control. It is not the whole control.

I too think the AI agent angle is under-discussed. Tools like Claude Code are designed to act on your behalf. A SessionStart hook that runs when the agent initializes is a natural target since it happens automatically, is hard to distinguish from normal setup. And gives the attacker access to the same context window you are using to debug. If your agent can read your environment, so can the worm. The fix is not to stop using AI agents. Fix: to run them in environments that contain fewer secrets and more logging.

What You Should Do Today

If you maintain any JavaScript or TypeScript project, run a dependency audit this week. Check whether any of your direct or transitive dependencies had suspicious version bumps in the relevant windows: September 2025, November 2025, and May 2026. If you use GitHub Actions, review your workflow secrets, enable branch protection rules that require reviews for workflows.

And rotate any long-lived tokens.

If you use VS Code or Claude Code, review the hooks and tasks in any repository you clone before opening it.

The best single action is to assume any freshly cloned public repo is hostile until proven otherwise.

That assumption will slow you down by five minutes per project.

The alternative is spending days rotating credentials and explaining to a client why your machine uploaded their API keys to a public GitHub repo named after a sandworm.

Sources: CISA alert on the npm supply-chain compromise (cisa.gov); Checkmarx write-up on the first Shai-Hulud wave (checkmarx.com); Trend Micro analysis of the npm supply-chain incident (trendmicro.com); Invicti report on Shai-Hulud 2.0 (invicti.com); Microsoft guidance on Shai-Hulud 2.0 and Mini Shai-Hulud (microsoft.com); Picus Security analysis of Mini Shai-Hulud (picussecurity.com); Snyk incident timeline on the May 2026 resurgence (snyk.io).