The ChainDrop npm worm hit over 400 packages with valid signatures

The New Stack published a history of the Shai-Hulud worm family on 31 August. One detail in it deserves separate attention: the latest variant defeated package signing without breaking any cryptography.

Note before the facts: the article is a sponsored post, paid for by env zero, a company that sells infrastructure automation. The events it describes are public record and the attribution below names its sources.

The family

It started on 15 September 2025. npm packages began publishing new versions with no maintainer running npm publish and no pull request merged. Between 14 and 18 September, more than 500 package versions were altered. Every stolen credential was uploaded to a new public GitHub repository named Shai-Hulud, after the sandworm in Frank Herbert's Dune.

On 24 November a larger variant backdoored 796 packages, moved its execution earlier in the install process so developer-side triggers no longer helped, and deleted the user's home directory when it found neither credentials to steal nor a way to spread.

By spring 2026 an offshoot called Mini Shai-Hulud had narrowed its targets. Instead of hunting generic developer secrets it went after credentials belonging to Claude, Codex, Cursor and Gemini, on the reasoning that AI coding tools sit inside the most interesting projects.

ChainDrop

The newest variant appeared on 4 August 2026. In under four hours it compromised more than 400 packages.

It did this by using a legitimate, cryptographically signed release pipeline. Each poisoned version therefore carried a valid SLSA provenance attestation, which is the mechanism built to prove a package was not tampered with. Its command infrastructure sat inside an Ethereum smart contract, so domain blocklists had nothing to block.

The New Stack's point on this is the one to keep: attestation tells you where a package came from. It says nothing about whether the commit should exist at all.

How the mechanism works

A compromised package runs a postinstall script. The script searches the machine for anything resembling a credential: npm and GitHub tokens, AWS or GCP secrets, whatever the cloud instance metadata service will provide. It downloads Trufflehog, a legitimate open-source secret scanner, and uses it to check which credentials are valid.

With a GitHub token it exfiltrates everything to a new public repository, and republishes any private repositories it can reach as public ones with a -migration suffix, so the move looks requested. With an npm token it lists every package the developer maintains, injects itself into each postinstall step, bumps the version and republishes.

No further human input is required at any point.

Palo Alto Networks' Unit 42 assessed with moderate confidence that the malicious script was partly written by a language model, based on stylistic signs in the comments and emoji in the payload.

Why this is not only an npm problem

Swap npm publish for terraform apply and the mechanics do not change. A provider pulled from a public registry is code that a publisher's account was trusted to publish, running with whatever access the requesting machine holds.

A CI runner holding a standing cloud credential with an open path to the internet is the same target as a maintainer's laptop with a valid npm token. Compromise it once, spread downstream at the speed automation allows.

The practical response is short. Postinstall scripts should not run by default. CI credentials should be short-lived and scoped. Workload access to instance metadata should be blocked. None of that is new advice, and all of it now defends against something that publishes faster than anyone reads.

Source

• Shai-Hulud: Whoever controls your package registry controls your pipeline, The New Stack, 31 August 2026, a post sponsored by env zero