← Tools I Use

The npm Supply-Chain Worm Is Self-Propagating Now: What Mini Shai-Hulud Means If You Run a Coding Agent

2026-06-03 · ~7 min read · Conor Dobbs

A couple of days ago I wrote up the Red Hat npm compromise, where the @redhat-cloud-services namespace got hijacked through a maintainer's GitHub account. That one was bad, but it was a single namespace. The wave it belongs to is the part that should actually change how you work, and it has a name: Mini Shai-Hulud, tracked as CVE-2026-45321 with a CVSS of 9.6.

The reason this one is different from "a bad package got published" is in the propagation. Mini Shai-Hulud is a real worm. It does not wait for a human to push the next malicious version. It steals the credentials it needs to push the next version itself, and it specifically goes looking for the tokens that sit on the machines of people like us: developers running coding agents that npm install all day. I run those agents, so this is the postmortem I actually read line by line.

How a registry worm spreads

On May 11, 2026, between 19:20 and 19:26 UTC, 84 malicious package artifacts went out across 42 packages in the @tanstack namespace. They were published by TanStack's own legitimate release pipeline, using its trusted OIDC identity, after attacker-controlled code hijacked the CI runner mid-workflow. Six minutes, dozens of poisoned versions, all signed by the real publisher.

Here is the self-propagation that makes it a worm rather than an incident. Once the payload steals credentials from one CI/CD pipeline, it enumerates every package that maintainer controls and publishes an infected version of each one. From there it spread within hours to Mistral AI, UiPath, and other maintainers, eventually touching more than 160 packages across npm and PyPI. Every compromised pipeline becomes a new launch point, and the registry itself does the distribution.

StepSecurity attributes the campaign to a group it calls TeamPCP, the same crew tied to the Aqua Security Trivy scanner compromise in March 2026 and the Bitwarden CLI npm package in April. This is not a one-off. It is an operator that keeps coming back to the same well.

The GitHub Actions chain that let it in

The interesting part for anyone who maintains a CI pipeline is exactly how the runner got hijacked. The compromise chained three things:

No leaked npm token, no stolen password in the classic sense. The pipeline was tricked into minting its own legitimate publish credential and handing it over. That is the same trust-boundary problem I called out in the Red Hat writeup: provenance and OIDC move the soft spot from the registry to your CI identity, and most teams have spent far less effort hardening a GitHub Actions config than a production database.

Why this one targets coding agents specifically

This is the detail that the earlier incidents did not really have, and the reason I am writing a second post instead of letting the Red Hat one stand. The Mini Shai-Hulud payload is about 2.3 MB of obfuscated code, and once it runs it does two things that matter for anyone with an AI coding tool installed.

First, it harvests aggressively. It reads the Actions runner's process memory to pull every secret in scope, then sweeps more than 100 file paths on the host: cloud provider credentials, cryptocurrency wallets, messaging app tokens, and the configuration files for AI developer tools, including Claude Code. If you have read my note on the stolen Codex auth tokens, you already know why this stings: those agent config files hold long-lived bearer tokens in plaintext, with no expiry and no second factor. A worm that grabs them gets quiet, indefinite impersonation.

Second, it persists. The payload installs persistence hooks in Claude Code, in VS Code, and at the OS level, and those hooks are designed to survive a reboot. So the usual reflex of "I removed the bad dependency, I am fine" does not hold. You can npm uninstall the poisoned version, reboot, and still have a payload re-establishing itself from a hook you never looked at.

So "the bad versions are gone" is not the all-clear

For the affected namespaces, the malicious releases have largely been pulled. That fixes the spread. It does nothing for a machine that already ran an install during the window. If you installed from any of the affected scopes in the relevant period, especially in CI, the correct posture is assume-breach, not assume-clean, because the worm's entire design is to outlast the obvious cleanup.

What to actually do

Some of this overlaps the generic supply-chain advice, but the coding-agent and CI-hardening pieces are what I would prioritize given how this specific worm behaves:

The bigger pattern

Supply-chain attacks used to be "someone published a bad package." Mini Shai-Hulud is the next thing: self-replicating malware that uses the registry as its transport, targets the tools we build with, and digs in deep enough to survive the cleanup most people would do. AI coding agents are now first-class targets in that story, not because the agents are uniquely insecure, but because they sit on a pile of long-lived tokens and run on machines that install untrusted code constantly.

The takeaway I keep landing on is the same one from the Red Hat post, just louder: your dependency graph is exactly as trustworthy as the least-protected identity that can publish to anything you install, and that now includes the identity your coding agent carries. The teams that come through this fine are the ones who already decided their CI tokens and their agent config files were as sensitive as a production password, because in an attack built like this, they are.

Sources

← More tools I actually use

Related reading