Last week the TeamPCP group did something the open source security community has been quietly dreading: they published the source code for the Shai-Hulud worm on GitHub and ran what amounted to a public attack challenge on BreachForums, inviting other actors to take the code and run with it. Days later, the first clones appeared on npm. A single threat actor uploaded four malicious packages from one account: a near-verbatim copy of Shai-Hulud with its own command-and-control infrastructure, three Axios typosquats, and a DDoS botnet payload that conscripts infected machines into a flooding network. All of them are aimed at developers who happen to fat-finger a dependency name.
Combined weekly downloads on those packages currently sit just above 2,600. That number is small. The number is not the story. The story is the speed.
The acceleration we predicted
In our December analysis, Beyond Shai-Hulud, we argued that Shai-Hulud was not an incident. It was a prototype. A proof of concept for a new paradigm of automated supply chain attack that weaponizes developer identity and the implicit trust baked into modern CI/CD pipelines. We said the JavaScript ecosystem was the first proving ground, not the final destination, and that the next phase would involve faster iteration, broader adoption, and a wider pool of less sophisticated actors armed with techniques they did not have to invent themselves.
The Glassworm campaign validated three of those predictions in March: multi-ecosystem coordination across npm, GitHub, the VS Code Marketplace, and Open VSX; AI-assisted evasion at a scale that human attackers cannot manually sustain; and invisible persistence using Unicode payloads that defeat human code review. We wrote at the time that the era of the supply chain worm was no longer a forecast. It was the operating environment.
The clones arriving on npm this week are the next predictable step. When you put a working worm in the public domain and explicitly encourage other actors to use it, you do not get one attacker. You get an arms race. And every copycat with a GitHub account is now a credible supply chain attacker.
Why a non-obfuscated copy still works
The most uncomfortable detail in this week's reporting is technical, not strategic. The headline clone, published as chalk-tempalte (a typosquat of the popular chalk-template package), is an almost direct copy of the leaked Shai-Hulud source. The attacker swapped in their own C2 endpoint and their own signing key, did not bother with obfuscation, and shipped it. And it worked.
That is the part developers and security teams need to sit with. The defenses that exist today do not require the attacker to be clever. They require the attacker to be present. The package manager will execute a preinstall script regardless of who wrote it or why. The CI runner will install whatever the lockfile points at. The developer workstation will hand over its credentials the moment the script asks for them. None of those behaviors changed between the original Shai-Hulud wave in November and this week.
What changed is the cost of entry. Six months ago, mounting a Shai-Hulud-style attack required either being TeamPCP or rebuilding their toolchain from scratch. Today it requires forking a public repository, swapping a domain name, and hitting publish.
One actor, multiple payloads, machine-assembled
The four packages flagged this week share a single npm account, but the malware inside them is heterogeneous. One is the Shai-Hulud clone. One is a straightforward infostealer that exfiltrates SSH keys, environment variables, and AWS, GCP, and Azure cloud credentials to a hardcoded IP. One implements a so-called "phantom bot" with persistence logic that survives package removal and a multi-protocol DDoS engine. One is a low-effort credential and crypto wallet stealer with no obfuscation at all.
This pattern matters. It is the operational signature we predicted in December: a single attacker running multiple payload types in parallel, generated and shipped fast enough to look machine-assembled, each variant collecting a different slice of value from the victim. The attacker does not need to pick a single business model (credential theft, cloud abuse, crypto draining, botnet recruitment) because the cost of running all four simultaneously has collapsed. This is what an arms race looks like in the AI-assisted era. It is not more sophisticated; it is more numerous, more varied, and faster.
The publisher side is not the problem you can solve here
npm has made real progress over the past year on the publisher side of the supply chain. Trusted publishing, provenance attestations, granular access tokens, and mandatory 2FA for high-impact packages are all meaningful improvements that raise the cost of publishing malicious code from stolen developer credentials. We covered the full landscape of those wins, and where they end, in our May post on npm supply chain security in 2026.
None of those controls help you here. The chalk-tempalte clone is not a hijacked legitimate package. It is a brand new package, uploaded under a fresh account, designed to be installed by mistake. Provenance attestations do not stop someone from creating a typosquat with a brand-new identity. Trusted publishing only matters when there is a previous trusted version to compare against. The publisher-side controls protect you from a compromised maintainer; they do not protect you from a malicious one with a clean account and a typo-friendly package name.
The consumer side is where this attack lives. And the consumer side is where the npm CLI still lags behind every major alternative.
What to turn on this week
If your team is running a modern package manager, three controls (most of them on by default) would neutralize the propagation mechanism behind the original Shai-Hulud worm and the chalk-tempalte clone alike.
- Block lifecycle scripts by default. pnpm v11 ships
strictDepBuilds: trueout of the box. Yarn Berry and Bun do the equivalent. Every package not on your explicit allowlist is prevented from executing code during installation. In the vast majority of codebases, the list of dependencies that genuinely need to run code at install time is surprisingly short. - Enforce a release cooldown. pnpm v11 defaults
minimumReleaseAgeto 24 hours; Yarn Berry'snpmMinimalAgeGatedefaults to three days. Most malicious packages are detected and removed within hours. A cooldown trades bleeding-edge freshness for the option to let the broader community find the malware before you install it. - Detect trust downgrades. pnpm's
trustPolicy: no-downgradeblocks installation of any version where the publishing authentication is weaker than previous versions, which is a strong signal of credential compromise. This is opt-in today; turn it on.
Beyond the package manager, treat your CI/CD pipeline as an attack surface, not a deployment mechanism. Audit which dependencies actually need install-time code execution and document why. Rotate any credentials that have been on developer workstations or CI runners that touched the affected packages. And do not assume that because the four packages flagged this week have low download counts, your environment is unaffected. The same techniques are being applied right now by actors who have not been caught yet.
The trajectory holds
Every prediction we made in December has held up over the subsequent six months. Glassworm proved the multi-ecosystem and AI-assisted variants were not hypothetical. The TeamPCP source code release proved that the supply of attackers was not the bottleneck. The supply of techniques was, and now that bottleneck is gone. The clones arriving on npm this week prove that the underlying defensive gap (package managers blindly trusting the code in every dependency) has not closed.
We do not expect this to be the last copycat wave. The economics are too good and the cost of entry is now too low. The teams that come out of 2026 in the strongest position will be the ones that stop treating implicit trust in every dependency, every maintainer, and every developer workstation as a defensible posture, and start treating it as the liability it has become.
How Mondoo helps
Mondoo's Agentic Vulnerability Management goes beyond scanning for known CVEs. It analyzes repositories, container images, CI/CD pipelines, cloud infrastructure, and developer workstations to detect compromised packages, unauthorized lifecycle scripts, suspicious dependency changes, and exposed credentials. These are the exact attack mechanics behind Shai-Hulud, Glassworm, and the clones arriving this week. We also publish ongoing advisories as new variants surface, so your team is not depending on a CVE feed alone.
Ready to see Mondoo in action? Schedule a demo today.
