The Miasma worm chewing through Red Hat's npm packages did not come from nowhere. It is the latest move by a crew that researchers have been chasing across the open source ecosystem since last autumn, and the most useful thing you can know about this attack is not the malware. It is the people shipping it.
That crew is TeamPCP, also tracked as Replicating Marauder, as TGR-CRI-1135 by Palo Alto's Unit 42, and as UNC6780 by Google's Mandiant. One group, several names, because different vendors fingerprinted it separately before the dots connected. Over the past ten months it has run at least seven distinct supply chain campaigns under the "Shai-Hulud" banner, named after the giant sandworms in Dune. The joke writes itself: a worm that surfaces, swallows everything in reach, and burrows back under before you can react.
Here is the part that should worry anyone who ships software. In May 2026, TeamPCP stopped hoarding its worm and published the source code, then ran a contest to get other criminals to use it. The Red Hat attack is what that decision looks like in production.
Who is TeamPCP?
TeamPCP is a financially motivated cybercrime group, not a nation-state actor and not a lone teenager. SecurityWeek flatly calls it "infamous," and the track record earns the word. The group specializes in one thing: compromising the trusted machinery that publishes open source packages, then using that trust to spread credential-stealing malware to everyone downstream.
Their signature is the Shai-Hulud worm, and the defining trait is self-propagation. A normal malicious package sits there until someone installs it. Shai-Hulud installs, harvests every secret it can find on the machine, then uses those stolen credentials to log into the victim's own npm and GitHub accounts and poison the next batch of packages automatically. The victim becomes the distributor. That is why the campaigns spread in hours, not weeks.
What they are after is consistent across every wave: cloud credentials for AWS, Google Cloud, and Azure, GitHub and npm tokens, SSH keys, API keys, cryptocurrency wallets, and CI/CD secrets. They exfiltrate the loot to throwaway public GitHub repositories that act as dead drops, each stamped with a taunt string so researchers know exactly who they are dealing with.
How did one crew end up behind so many attacks?
The lineage is short and fast, but the scale is wildly uneven, and that is the first thing worth seeing clearly. Plot the reach of each wave and Miasma is not the monster. November 2025's "Second Coming" touched 26,000 repositories. The May 2026 TanStack wave spun up around 400. Miasma sits at 309. Raw spread is not what makes the Red Hat attack dangerous. Its target and its method are.
The first Shai-Hulud worm surfaced in September 2025, when Unit 42 documented a self-replicating attack that compromised hundreds of npm packages. In November 2025 came the sequel the actors themselves branded "The Second Coming," which Microsoft tracked as it spread to more than 26,000 repositories, one of the largest coordinated npm attacks on record.
Then 2026 turned into a sprint. A "Mini Shai-Hulud" variant hit SAP-related packages in April. On May 12, the worm tore through the TanStack ecosystem and dragged in Mistral AI, UiPath, OpenSearch, and Guardrails AI. That cluster earned the CVE identifier CVE-2026-45321 and a CVSS score of 9.6, hit 42 packages across 84 versions, and set a grim first: StepSecurity's Ashish Kurmi noted the compromised packages carried valid SLSA Build Level 3 provenance, "making this the first documented npm worm that produces validly attested malicious packages." The cryptographic seal of approval said the malware was legitimate.
Across that May campaign the worm spread to more than 170 packages spanning npm and PyPI, with over 518 million cumulative downloads, and spawned at least 400 dead-drop repositories all carrying the string "Shai-Hulud: Here We Go Again."
The TanStack wave also showed how nasty the tradecraft had become. The malware planted a dead-man's switch: an npm token named, in plain text, IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner. If a victim tried to revoke it, a script ran rm -rf ~/ and wiped the home directory. Microsoft's analysis of the matching PyPI payload found country-aware logic that skips Russian-language systems and a "geofenced destructive branch that has a 1-in-6 chance of executing rm -rf /" when the machine looks like it is in Israel or Iran. This is not a smash-and-grab. It is deliberate, opinionated malware.
What changed when they open-sourced the worm?
On May 15, 2026, TeamPCP did something that reframes everything after it. The group published the Shai-Hulud source code to GitHub under several accounts, complete with deployment instructions and a manifesto titled "Shai-Hulud: Open Sourcing The Carnage." Almost immediately, a companion post on BreachForums announced a "supply chain challenge" that paid criminals monetary rewards for using the worm, proving intrusion, and causing maximum downstream damage.
Datadog's teardown of the leaked code revealed a modular framework: loaders, secrets-harvesting modules, an information collector, a dispatcher, exfiltrators, and mutators. One detail matters more than the rest. Every build seeds its string encoding with a fresh random passphrase, so two builds from identical source produce different binaries. As Datadog put it, "defenders cannot generate YARA rules from one compiled sample and expect them to match the next deployment." The worm was engineered from the start to defeat signature detection.
Black Duck's Ben Ronallo did not mince words: "TeamPCP is turning the knob up to 11 on their activities by releasing this to anyone who wants to use it," and warned of "a sustained and significant spike in supply chain compromise activity." Within 48 hours he was right. By May 17, OX Security caught the first copycats, four typosquatted npm packages including chalk-tempalte and axois-utils, one of which bundled a GoLang DDoS botnet it called a "phantom bot." TeamPCP had successfully turned its private weapon into a public platform.
So can we even blame TeamPCP for Miasma?
This is the question the open-sourcing was designed to make hard, and it is where a careful read matters.
By handing the worm to the world and bankrolling a contest, TeamPCP did two things at once. It multiplied the number of attacks, and it gave itself deniability. As SecurityWeek observed, the release ensured "its own actions could be hidden behind potential copycats' campaigns." Every future incident now arrives with a built-in alibi. Was it the original crew, or one of the contest entrants?
For the Red Hat Miasma attack, the honest answer is that nobody has publicly proven which hand was on the keyboard. But the evidence leans one way, and it is worth saying plainly. The copycats OX dissected were sloppy: near-verbatim copies of the leaked code, no obfuscation, generic typosquat names, fresh C2 servers on free tunneling domains. Miasma is the opposite. It abused Red Hat's OIDC trusted publishing with the same branch-scoping flaw the TanStack wave exploited, shipped a heavily obfuscated Bun-based stealer, repackaged 96 versions in 72 seconds, and reused the exact dead-drop pattern from the original campaigns. That is the work of someone fluent in the toolkit, not a contest entrant pasting a README.
So the defensible read is this: Miasma is either TeamPCP itself or an operator close enough to be indistinguishable from it. Either way, the practical conclusion is the same, and that is the uncomfortable lesson of open-sourcing malware. Attribution stops being the useful question. Capability has been democratized, and the next Miasma might genuinely be a stranger.
| Wave | Date | What it hit | Reach | Signature move |
|---|---|---|---|---|
| Shai-Hulud | Sep 2025 | npm packages | Hundreds of packages | First self-replicating npm worm |
| The Second Coming | Nov 2025 | npm repos | 26,000+ repositories | Mass GitHub Actions abuse |
| TanStack cluster | May 12, 2026 | TanStack, Mistral, UiPath | 170+ packages, CVSS 9.6 | Valid SLSA provenance, wiper switch |
| Source release | May 15, 2026 | Everyone | Public on GitHub | BreachForums bounty contest |
| Miasma | Jun 1, 2026 | Red Hat npm packages | 96 versions in 72 seconds | OIDC trusted-publishing hijack |
What should you actually do about it?
The shift here is structural, not incidental. Upwind's Avital Harel framed it well: this is "a broader shift in supply chain attacks from isolated package compromise to identity-driven propagation through trusted CI/CD infrastructure." Once an attacker owns your publishing identity, your own release pipeline becomes their distribution network. Provenance signatures, the thing meant to save you, get minted on the malware automatically.
If you ship anything that depends on npm, treat the build pipeline as production-grade attack surface, because it now is. Concretely:
- Scope OIDC trusted publishing tightly. The recurring root cause is trust granted at the repository level instead of being pinned to a specific protected branch and workflow file. Lock it down so a throwaway branch cannot mint a publish token.
- Pin and review GitHub Actions by commit hash, not by floating tag, and treat unexpected workflow changes in a diff as a security event.
- Do not trust provenance as authorization. A valid SLSA or Sigstore attestation proves how a package was built, not that the build was sanctioned. Verify the maintainer and the source, not just the signature.
- If you suspect infection, image the machine before you touch tokens. The dead-man's switch means revoking a malicious npm token can trigger a wipe. Isolate first, rotate after.
- Watch install-time behavior. Preinstall and prepare hooks that fetch the Bun runtime or reach out to unfamiliar domains are the tell. Static dependency scanning will not catch a worm whose binary changes every build.
Pathlock's Jonathan Stross summed up the remediation playbook: isolate and rebuild affected developer and CI systems, rotate exposed credentials, restrict OIDC publishing to scoped workflows and protected branches, pin Actions, and monitor package install behavior. None of it is exotic. All of it is now mandatory.
TeamPCP's whole strategy is to make trust expensive. The crew bet that an ecosystem built on automatic updates, signed provenance, and one-click publishing would keep extending trust faster than anyone could verify it. So far that bet is paying off, and they have handed the playbook to everyone who wants a turn.
Sources
- Unit 42, "Shai-Hulud" Worm Compromises npm Ecosystem in Supply Chain Attack
- Microsoft Security, Shai-Hulud 2.0: Guidance for detecting and investigating
- The Hacker News, Mini Shai-Hulud Worm Compromises TanStack, Mistral AI, Guardrails AI
- SecurityWeek, TeamPCP Ups the Game, Releases Shai-Hulud Worm's Source Code
- Datadog Security Labs, Shai-Hulud open source framework static analysis
- OX Security, New Actors Deploy Shai-Hulud Clones: TeamPCP Copycats Are Here
- The Hacker News, Miasma Supply Chain Attack Compromises Red Hat npm Packages
- SafeDep, redhat-cloud-services hit by Mini Shai-Hulud npm worm
