On Monday morning, somewhere a build server pulled the newest version of a Red Hat package it had pulled a hundred times before. Before a single line of the developer's own code ran, a script unpacked itself and started copying everything it could reach: AWS access keys, the GCP service account file, Azure tokens, SSH private keys, and the contents of every .env file on disk.
The package was real. It came from the official @redhat-cloud-services namespace on npm, the same one millions of installs trust every week. It carried a valid cryptographic signature proving it had been built by Red Hat's own pipeline.
That signature is exactly why this attack matters.
On June 1, 2026, researchers at Wiz and Aikido independently flagged a supply chain compromise across the @redhat-cloud-services scope on npm. Aikido counted 96 malicious versions across 32 packages. The poisoned releases were not snuck in through a stolen password and a quiet upload. They were published through the exact mechanism npm built to make supply chain attacks harder, and they came out the other side looking more trustworthy than a normal release, not less.
The Attack Came Through a Door That Was Supposed to Be Locked
For years, the weak point in npm publishing was the long-lived access token. Maintainers stored these tokens in their CI pipelines so automated builds could push new versions. Steal the token, and you can publish malware under a trusted name. Most of 2026's supply chain attacks worked this way.
npm's answer was trusted publishing: instead of a permanent token sitting in a config file, a build pipeline requests a short-lived identity token from GitHub at publish time, proves it is the legitimate repository, and gets a one-time pass to publish. The package then ships with SLSA provenance, a signed record showing which repository and which workflow produced it. The whole point is to let a developer verify that a package really was built by the project it claims to come from.
The Miasma attackers did not steal a token. They stole the thing trusted publishing relies on: a trusted account.
According to Wiz, a specific Red Hat employee's GitHub account was compromised and used to push malicious orphan commits straight into Red Hat repositories, bypassing code review entirely. The activity came in two waves, one starting at 10:53 UTC and a second at 13:44 UTC, hitting repositories including frontend-components, javascript-clients, and platform-frontend-ai-toolkit. Each commit added a tiny release workflow that ran on a push to any branch, requested GitHub's identity token, and used it to publish backdoored versions of every package in a target list.
The result is the dark joke at the center of this incident. Each malicious package shipped with a valid provenance attestation. The signature did its job perfectly. It correctly certified that the malware had been built by Red Hat's pipeline, because it had.
Miasma Was Built to Steal Everything That Unlocks the Cloud
The payload itself is not original. Both Wiz and Aikido traced it to Mini Shai-Hulud, a self-spreading credential stealer built by a threat group called TeamPCP, the same actors behind March's LiteLLM backdoor. This variant swaps the malware's old Dune references for Greek mythology and creates repositories described as Miasma: The Spreading Blight, which is where its name comes from.
Each compromised package declared a preinstall script, so the malware ran automatically on every npm install, before any application code and before a developer saw anything wrong. The script was a 4.2 MB file buried under several layers of obfuscation. Once running, it performed a broad sweep for anything that could unlock a cloud account or a code repository:
- GitHub Actions secrets, including
GITHUB_TOKENandACTIONS_RUNTIME_TOKEN - AWS access keys and session tokens
- GCP application default credentials and service account key files
- Azure service principal credentials and managed identity tokens
- HashiCorp Vault tokens, Kubernetes service account tokens, and kubeconfig files
- npm and PyPI publish tokens, SSH private keys, Docker registry credentials, and GPG keys
- Every
.envfile it could find across the filesystem
Wiz noted one meaningful upgrade in this version: new collectors built specifically to enumerate GCP and Azure cloud identities, gathering every identity the infected machine could reach. Earlier variants mostly grabbed secrets and moved on. This one is built to map and take over the cloud account itself.
This Is the Same Playbook, Now Available to Everyone
The reason a Red Hat compromise feels less like a one-off and more like a pattern is that the tooling is now public. On May 12, 2026, TeamPCP published the full Mini Shai-Hulud source code to GitHub and, according to Aikido, posted on BreachForums encouraging others to run their own campaigns. The barrier to launching one of these attacks dropped to roughly zero.
The throughline is uncomfortable for anyone who builds software. Bitwarden, PyTorch Lightning, Mistral, Microsoft, and now Red Hat are not careless hobby projects. They are some of the most security-conscious organizations in the open-source world, and the attack walked into all of them through the same door: a compromised developer account with the keys to a CI pipeline.
The Trust Signal Became the Attack
The hard part of this story is that trusted publishing is genuinely a good idea. Removing long-lived tokens from CI pipelines closes off a huge class of attacks, and most of the time it works. The flaw is not in the cryptography. It is in the assumption underneath it.
Provenance proves where a package was built. It does not prove that what was built is safe, or that the person who triggered the build was supposed to. When an attacker controls a maintainer's account, every guarantee the system offers becomes a guarantee about the attacker's malware. As Aikido put it, OIDC-based trusted publishing, designed to eliminate long-lived tokens, becomes a misleading trust signal.
There is also a real question about who did this. Wiz was careful to say the tradecraft overlaps with TeamPCP but that attribution is no longer clean. Once the group open-sourced its toolkit and invited copycats, any number of actors could be running the same playbook. The technique is now a commodity, which makes the next Red Hat harder to predict and harder to pin on anyone.
Wiz and Aikido both say the same thing: assume exposure and rotate. Treat every CI secret, cloud credential, SSH key, npm token, and `.env` value on any affected machine as compromised, and rotate it immediately. Audit GitHub for unfamiliar repositories, new access tokens, and workflow runs you did not trigger. Then pin dependencies, generate an SBOM, and add install-time package allowlisting so the next poisoned `preinstall` script never runs in the first place.
The Bottom Line
A worm got into 32 of Red Hat's official npm packages by stealing one developer's account, and it shipped out the other side wearing a valid signature that said, correctly, that Red Hat had built it. The download numbers were modest, roughly 80,000 a week by Wiz's count and close to 117,000 by Aikido's, but the lesson scales far past Red Hat. Every defense the ecosystem has built in the last two years assumes the account behind the build is honest. Miasma is the latest reminder that the account is the soft target, and that the tooling to attack it is now sitting in a public GitHub repository for anyone to fork.
The same pattern has now breached PyTorch Lightning, GitHub itself through a poisoned VS Code extension, and the npm registry at scale in the space of two months. The signature on your dependencies tells you where they were built. It was never going to tell you whether the person who built them was really them.
Sources
- Miasma: Supply Chain Attack Targeting RedHat npm Packages — Wiz (Jun 1, 2026)
- Red Hat npm Packages Compromised to Spread a Credential-Stealing Worm — Aikido Security (Jun 1, 2026)
- Miasma Supply Chain Attack Compromises Red Hat npm Packages with Credential-Stealing Worm — The Hacker News (Jun 1, 2026)
- Multiple redhat-cloud-services npm Packages compromised — StepSecurity (Jun 1, 2026)
- Red Hat Cloud Services npm Packages Hijacked — Sonatype (Jun 1, 2026)
- Dozens of Red Hat npm packages targeted in supply chain attack — Cybersecurity Dive (Jun 1, 2026)
- 'Miasma' worm infests Red Hat npm packages — iTnews (Jun 1, 2026)