Shai-Hulud 2.0: A Signed Worm Is Still a Worm

The npm ecosystem spent 2025 building trust primitives around package provenance — attestations, GitHub Actions integration, signed release metadata — so that a downstream consumer could ask "did this package come out of the source repo it claims to?" and get a real answer. On Aug 4, 2026, a worm shipped that answered yes.

keyv@6.0.0 and thirteen sibling packages from the same maintainer went live on the registry with a malicious preinstall hook, valid provenance signatures, and a payload that harvested cloud and CI credentials, republished trojanized versions of everything the stolen tokens could reach, and moved. By 13:37 CEST, Aikido counted 868 unique packages / 1,381 malicious versions. By end-of-day, Wiz and Datadog had the count past 2,200 packages representing roughly 2 billion monthly downloads. Aikido identified the malware as a Shai-Hulud variant, and Datadog and Wiz tracked it specifically as Shai-Hulud 2.0 — the sequel to the first self-replicating npm worm from late 2025.

The interesting thing here is not that a worm returned. It is where it entered the supply chain.

Provenance verified. Payload malicious.

Per Socket's and Snyk's writeups, the compromise path started with an account takeover: the attacker got into the GitHub account of Jaredwray, the maintainer behind the keyv and cacheable package families. From there, they did something specifically calibrated against the ecosystem's current trust story. They pushed the malicious files directly to the main branch of the source repository, then let the project's own GitHub Actions release workflow do what it always does — cut a release, sign the provenance attestation, publish to npm.

Snyk called out the mechanic: the poisoned releases arrived with valid, verifiable, npm-attested provenance. Any consumer whose supply-chain policy was "reject packages without provenance signatures" accepted them. Provenance answered the question it was designed to answer — did this artifact come from the source repo it claims to? — correctly. It said yes, and it was right. The source repo had just been backdoored an hour earlier.

Provenance signatures verify who published. They do not verify what the code does at install time. That gap is the entire opening.

What the payload actually does

Once installed, the chain per Socket, Wiz, and Datadog is:

• The preinstall hook setup.mjs runs.
• It downloads a standalone Bun runtime binary. Not Node — a separate JavaScript runtime. That defeats any preinstall-hook heuristic that keys on Node version, and it defeats any static analysis expecting the payload to be interpretable by the host runtime.
• Under Bun, an obfuscated second stage reads every credential the caller has visibility into: AWS, GCP, Azure, Vault, Kubernetes, GitHub Actions OIDC tokens, npm auth tokens, Slack, Stripe, SSH keys, VPN configs, Datadog API keys.
• Stolen data is AES-256-GCM encrypted and exfiltrated to attacker-controlled GitHub repositories, then forwarded on.
• Any npm token the worm finds is used to republish trojanized versions of every additional package that token can reach.
• A watcher installs as a macOS LaunchAgent or a Linux systemd user service and polls the GitHub API with the stolen token every 60 seconds. When the token starts returning 4xx — meaning the victim rotated it — the watcher evaluates an attacker-supplied handler.

Wiz added a specifically new piece: the malware retrieves its exfiltration domain list from an Ethereum smart contract. Rotating C2 no longer requires registering hostnames — it requires updating on-chain state. Network-blocklist defenses that key on domain reputation now have to move at on-chain state-change tempo.

The propagation numbers are worth pausing on. Aikido tracked the worm reaching nine unrelated organizations in the first thirty minutes, moving between orgs every 2-7 minutes, republishing each victim's namespace at roughly one package per second. This is not a phishing campaign someone is driving. It is a self-propagating loop.

Why this is the same shape we wrote about a year ago

We opened the first post on this blog — When a Worm Can't Rob You, It Burns the House Down — with a description of the original Shai-Hulud, and made a specific claim: this attack is not one malicious file you can blocklist, it is a sequence. Install a package. Read a config file. Make a network call. Push to a repo. Every single step, taken alone, looks like something a developer's machine does a hundred times a day. The malice is in the order.

Shai-Hulud 2.0 is that argument, restated with new primitives. The provenance-signature bypass is a new front-of-chain evasion. The Ethereum smart-contract C2 is a new middle-of-chain evasion. The persistence-via-systemd-user-service is a new tail-of-chain evasion. What has not changed is the shape of the chain, or the fact that no individual event in it is malicious in isolation.

Signature-based defenses look for known-bad files. Provenance-based defenses look for unsigned publishers. Neither can see the shape.

The takeaway

If you use keyv, cacheable, flat-cache, file-entry-cache, or any of the affected packages, Aikido, Wiz, and Socket have posted the specific version ranges — pin below the poisoned releases, rotate every credential that touched a CI runner or dev machine that ran npm install since Aug 4, and audit repositories for injected malicious commits pushed under the maintainer's account. That is the necessary short-term move.

The longer lesson is where the trust primitive ended up sitting. Provenance was designed to close the "did this come from a legit publisher" gap, and it does. It was never going to close the "does the code do something legit at install time" gap, because those are different questions. Watch the behavior at install time. That is the boundary that stayed open here.

SPR{K3 is a security research operation that pairs offensive vulnerability research with runtime behavioral defense. Defend is our runtime agent. To talk about a deployment, reach us at support@sprk3.com.