Mini Shai-Hulud 'Miasma' Variant Compromises 32 Red Hat Cloud Services npm Packages

The trust boundary that failed here was not npm's and not Red Hat's source code — it was one developer's GitHub login, fed to a worm engineered to convert a single account compromise into the next one automatically.

RALEIGH, N.C. — On June 1, 2026, attackers who had hijacked a Red Hat employee's GitHub account pushed malicious code into 32 npm package releases published under the company's official @redhat-cloud-services namespace — packages downloaded roughly 80,000 times a week — in a campaign that researchers at Google-owned Wiz have named 'Miasma.'

Wiz, the supply-chain security firm Socket, Orca Security and StepSecurity all independently identified the payload as a new build of Mini Shai-Hulud, the self-propagating credential-stealing worm that the cybercrime crew TeamPCP open-sourced in May. Whether TeamPCP or a copycat is behind this attack remains, for now, unconfirmed.

What Happened

Security researchers disclosed on June 1, 2026 that 32 package releases published under Red Hat's official @redhat-cloud-services npm namespace had been laced with malware. According to Google-owned Wiz, which traced the intrusion, a single Red Hat employee's GitHub account was compromised and then used to push malicious orphan commits into two RedHatInsights repositories across two waves of activity, bypassing the normal code-review process. The affected packages are downloaded around 80,000 times a week; the supply-chain firm Socket counted 95 malicious package versions as of 11:00 UTC and noted it was still updating the list as the attack remained live. How the employee's account was taken over has not been reported.

The malicious versions execute through an npm preinstall lifecycle hook, meaning the code runs automatically during npm install — before a developer ever imports or uses the package. Orca Security described the payload as a 4.2 MB obfuscated JavaScript file. Once running, Socket's analysis found, it collects GitHub Actions secrets, npm publish tokens, cloud-provider credentials, Kubernetes and HashiCorp Vault material, SSH keys and Git credentials, then exfiltrates them through encrypted channels with a GitHub-based fallback. StepSecurity flagged the detail that turns theft into spread: the payload uses npm's bypass_2fa publish parameter to push fresh backdoored versions of any package the stolen token can reach, overriding two-factor-authentication requirements so the worm keeps moving even against 2FA-protected accounts.

How One Stolen GitHub Login Became a Worm

The whole incident pivots on a single failed credential. Wiz attributes the initial access to one compromised Red Hat employee GitHub account, which the attacker used to push orphan commits — commits with no parent in the existing history — into two RedHatInsights source repositories. Orphan commits dropped straight into a repository can sidestep the review a normal pull request would attract, and that is exactly what happened here: the malicious changes bypassed code review. From there, the design of Mini Shai-Hulud took over. Because the payload fires from an npm preinstall hook, it does not wait to be called by application code; it runs the moment any developer or automated pipeline runs npm install against a poisoned version. And because it harvests npm publish tokens and then reuses them with the bypass_2fa parameter, each infected machine can seed the next wave of compromised packages without the attacker lifting a finger. That is what separates a worm from a one-off poisoning, and it is why the affected-version count climbed through the day rather than holding steady.

What 'Miasma' Changed — and Why the Cloud Is the Target

Wiz describes the changes from earlier Mini Shai-Hulud builds as 'largely cosmetic,' with the worm's Dune-universe references swapped for Greek-mythology themes such as 'spartan' while the underlying tradecraft stays substantially the same. The name 'Miasma' itself comes from the description — 'Miasma: The Spreading Blight' — that the variant stamps on the repositories it creates. But two changes are not cosmetic. First, this build adds dedicated data collectors for Google Cloud Platform and Microsoft Azure identities, and rather than only lifting secrets out of a cloud environment it enumerates every identity the infected machine can reach — a shift Wiz reads as 'an increased attacker focus on gaining and leveraging access to the cloud itself.' Second, unlike earlier self-spreading versions that simply copied themselves, Miasma generates a uniquely encrypted payload for each infection, which means hash-based indicators of compromise are only useful for one specific package version at a time. The takeaway for defenders is that the worm has moved up the stack: the prize is no longer just the credentials sitting on a build host, it is the cloud accounts those credentials unlock.

A Sub-Weekly npm Cadence Now Reaching Vendor Scopes

Miasma does not stand alone. It lands inside a sustained run of npm supply-chain incidents The CyberSignal has tracked at close to weekly cadence: Microsoft's naming of a 'Mini Shai-Hulud' wave of typosquatted npm packages stealing cloud and CI/CD secrets on May 31, the 33 malicious npm packages Microsoft documented in a dependency-confusion recon campaign the day before, and the multi-registry TrapDoor operation that hit npm, PyPI and Crates.io a week earlier. It also belongs to the longer Shai-Hulud lineage — the worm clones a copycat pushed to npm within a week of the source leaking, the variant that began generating valid Sigstore provenance badges for its malicious packages, the automated Megalodon campaign that backdoored thousands of GitHub repositories through CI/CD workflows, and the TeamPCP breach that exfiltrated GitHub internal repositories through a poisoned VS Code extension. What is new is the address: this time the worm is inside an official vendor namespace, not a typosquat or an abandoned package.

Scope and Impact

The most important qualifier comes from Red Hat itself. A company spokesperson told reporters that Red Hat 'immediately initiated an investigation and removed the packages from the npm registry,' and stated that the packages 'are strictly limited to internal development, and the malicious code was never published for customer consumption via the console.redhat.com system.' The investigation is ongoing, the spokesperson added, but Red Hat has 'not identified any impact to customer or partner environments or Red Hat production systems.' That hedge matters and should not be flattened: this is not, on Red Hat's account, malware that shipped to paying customers in a production product.

What it is, however, is malware that sat in an official vendor scope downloaded on the order of 80,000 times a week — and exposure is not the same thing as compromise. The 32-package, 95-version figures count what was published, not how many developer workstations or CI/CD pipelines actually ran npm install against a poisoned version during the window. Any environment that did should assume the credentials reachable from it are burned. Because Miasma generates a unique encrypted payload per infection, hash-based indicators are only good for a specific version, so the practical detection surface is the install itself: an @redhat-cloud-services install logged on or after June 1, a preinstall hook executing during a build, or a 4.2 MB obfuscated JavaScript file in a package's install path.

Response and Attribution

For any team that consumes @redhat-cloud-services packages, the immediate work is an audit against Socket's continuously updated list of affected versions: search npm install logs across developer and CI/CD environments for any install of one of those versions dated June 1 onward, and treat any match as a credential-compromised host. From there, rotate every secret reachable from that environment — AWS, GCP and Azure credentials, GitHub Actions secrets, npm and PyPI publish tokens, Vault tokens, Kubernetes config, and SSH and Git keys — and review GitHub activity for unauthorized repositories, newly created access tokens, or suspicious workflow runs, which are the artifacts Wiz and StepSecurity flag as signs the worm has used a stolen token to spread. Structurally, the defenses are the familiar ones that this cadence keeps validating: dependency allowlisting, SBOM generation, package verification, pinning to known-good versions, and tighter monitoring of developer and build environments.

On attribution, the honest answer is that there is not one yet. Both Wiz and Socket identify the payload as Mini Shai-Hulud, but because TeamPCP open-sourced that worm in May, anyone can now run it — and researchers are explicit that they cannot say whether TeamPCP or a copycat operator is responsible for the Red Hat campaign. The cosmetic Dune-to-Greek-mythology rebrand is consistent with either a TeamPCP refresh or a derivative crew putting its own stamp on borrowed code. The responsible position is to treat the tradecraft as known and the operator as unknown, and to resist the pull to assume a single author just because the campaign rhymes with TeamPCP's earlier work.

The CyberSignal Analysis

Signal 01 — Official Vendor Scope Is Not a Trust Boundary

For years, the implicit rule of dependency hygiene was that packages from a real vendor's official namespace were the safe ones and the risk lived in typosquats and abandoned packages. Miasma is the counterexample, and it is not the first this cycle — it follows Microsoft's own naming of Mini Shai-Hulud typosquats and a dependency-confusion campaign within the same fortnight. The mechanism here did not require breaking npm or breaking Red Hat's code; it required one employee's GitHub account. Once an attacker holds a credential that can publish to a scope your build consumes, the scope's reputation is worthless as a security control. The practical consequence is uncomfortable but clear: in an active-attack window, an install from an official vendor scope deserves the same untrusted-until-validated treatment as anything else, and the phishing-resistant authentication and least-privilege publish tokens protecting those accounts are now load-bearing infrastructure, not best-practice nice-to-haves.

Signal 02 — The Worm Now Wants the Cloud, Not Just the Secrets

The most consequential change in the Miasma build is easy to miss under the cosmetic rename. Earlier Mini Shai-Hulud builds stole secrets; this one adds collectors for Google Cloud and Azure identities and enumerates every identity the infected machine can reach. Wiz reads that as a deliberate move toward 'access to the cloud itself' — and that reframes the blast radius. A stolen static API key is a problem you can rotate; a harvested cloud identity that an attacker can assume to walk laterally through a cloud estate is a different order of incident. For defenders, the implication is that build hosts and CI runners should be treated as cloud-identity-bearing assets with the same scrutiny as production workloads: short-lived, tightly scoped credentials, aggressive review of post-incident cloud audit logs for identity-assumption activity, and an assumption that anything a compromised runner could reach in the cloud is now in scope.

Signal 03 — 'Open-Sourced' Malware Breaks Attribution

When TeamPCP open-sourced Mini Shai-Hulud in May, it did more than share a tool — it severed the link between a piece of malware and a single author. The Red Hat campaign is the immediate cost of that: four research teams can agree on exactly what the payload is and still be unable to say who ran it, because the code is now common property. That is a structural problem for threat intelligence, which has long leaned on tooling as an attribution signal. As capable malware frameworks get published, defenders will increasingly face campaigns where the tradecraft is fully known and the operator is genuinely unknowable from the artifacts alone. The discipline this demands is the one The CyberSignal applies throughout this coverage: report what the code does with confidence, and refuse to manufacture an attribution the evidence does not support.

Sources