On Sunday morning, June 1, researchers at Wiz and Aikido independently spotted something ugly: multiple official packages under Red Hat’s @redhat-cloud-services npm namespace had been hijacked. The packages — the kind that get pulled into enterprise CI/CD pipelines by the thousand — were quietly exfiltrating cloud credentials, SSH keys, and npm tokens.
The malware had a familiar signature. It was derived from Mini Shai-Hulud, a credential-stealing worm that the group TeamPCP had published as open source weeks earlier. Not leaked. Not reverse-engineered. Published. Complete with documentation, modular data collectors, and a propagation engine that spreads by republishing backdoored versions of whatever packages the victim has access to.
The predictable response, already forming in the Hacker News thread that lit up this morning, is a call for more tooling — better scanners, tighter registry controls, mandatory two-factor on every maintainer account. These are fine ideas. They will also miss the point entirely.
TeamPCP Didn’t Discover a Vulnerability. They Wrote a Weapon and Handed It Out.
There is a long and genuinely valuable tradition in security research of publishing proof-of-concept exploit code. It forces vendors to patch. It gives defenders something concrete to test against. The norm makes sense when the target is a buffer overflow in a closed-source router firmware or a cryptographic flaw in a messaging protocol.
A self-replicating worm that targets the npm registry is not that.
The npm ecosystem has no centralized patch mechanism. There is no vendor who can ship a fix on Patch Tuesday. The “vulnerability” isn’t a bug in specific software — it’s the architectural reality that any maintainer’s compromised token can poison thousands of downstream projects, and the registry’s design makes that poisoning near-instantaneous and extremely hard to unwind.
Publishing fully functional worm code into that environment is less like disclosing a vulnerability and more like publishing the blueprints for a pathogen and dropping them into a population with no immune system. The worm doesn’t exploit a flaw that can be fixed. It exploits the normal, intended operation of the platform.
“We handed every script kiddie a loaded gun and a map of where to point it,” said one incident responder at a cloud security firm, who asked not to be named because their employer hadn’t authorized them to speak. “The only question was when someone would pull the trigger.”
Open-Source Malware Is Still Malware
The security community has spent two decades building a norm that publishing offensive tools is a public good. Metasploit modules, exploit-db entries, Cobalt Strike — these are dual-use, sure, but the argument goes that defenders need them to simulate attacks and that sunshine is the best disinfectant.
Mini Shai-Hulud breaks that calculus. It is not a tool for red teams running authorized engagements. It is a fire-and-forget worm that, once released, propagates autonomously through a trust graph no single organization controls. Defenders cannot patch against it because the attack surface is social — it’s about whose npm token gets phished next, whose CI secret sits in an environment variable, whose maintainer reused a password.
By the time Wiz published its analysis at 1 PM UTC today, most of the malicious package versions had been revoked — but two remained live. Two. Hours after discovery, in one of the most-watched package namespaces in the ecosystem, the cleanup was still incomplete.
That is the pace of response in a world where anyone can fork a worm off GitHub.
The Right Conversation Nobody Wants to Have
There will be a thousand postmortems about what Red Hat should have done. More MFA. More token scoping. Better audit logging. These are sensible and necessary and also a way of avoiding the harder question: whether the security-research norm of full-disclosure-by-default needs a boundary when the “disclosure” is a fully weaponized worm aimed at infrastructure that cannot be patched.
No one wants to be the person who argues for less transparency. The instincts that drive publication — reproduceability, peer review, forcing action — are the right instincts in most cases. But the npm registry is not most cases. It is a commons maintained almost entirely by volunteer labor, running on trust, with no central authority capable of inoculating it against a worm whose source code is a README away.
If the convention is that anyone can publish anything and call it research, we should not be surprised when what they publish gets used. The only surprise is that it took until June 1, 2026.
Published the same morning Red Hat’s security team was still yanking poisoned packages off the registry, the Mini Shai-Hulud repository remains public. The genie is out. The question now isn’t whether we’ll see more of these attacks — it’s what the security community owes the commons when the next researcher decides to open-source the lamp.
Sources
- Miasma: Supply Chain Attack Targeting RedHat npm Packages - Wiz
- Red Hat npm Packages Compromised to Spread a Credential …
- The npm Threat Landscape: Attack Surface and Mitigations …
- Multiple supply chain compromises of open source projects
- Supply Chain Attack Affecting Numerous npm and PyPI Packages - NHS England Digital
- npm & PyPI Supply Chain Attack April 2026: Detection & Prevention | IT Cares