NPM-REDHAT-MIASMA-2026

How it happened

The compromise surfaced around 1 June 2026, disclosed not by Red Hat but by a StepSecurity researcher who opened a public security issue on the RedHatInsights/javascript-clients repository. The entry point was a compromised GitHub account inside the RedHatInsights organisation. Researchers describe it as a Red Hat employee account; Red Hat's own advisory says only that "a compromised GitHub account was used." That account pushed malicious orphan commits, which sit outside the normal branch history and so slip past code review entirely.

Those commits then rode the project's own GitHub Actions release workflow, which requests a short-lived OIDC token to publish to npm through trusted publishing. Because the genuine, authorised pipeline did the publishing, the trojanised packages carried valid SLSA Build Level 3 provenance. Unit 42 called it the first documented case of a worm shipping malicious npm packages with valid build provenance. Each package declared a preinstall hook that executed an obfuscated dropper, swelling a normal index.js of roughly 200 KB into a payload of about 4.29 MB. The malware was Miasma, a cosmetic re-theme of Mini Shai-Hulud with the Dune references swapped for Greek mythology and attacker repositories stamped "Miasma: The Spreading Blight."

The damage

The campaign hit 31 packages across 96 malicious versions, frontend libraries and API clients for the Red Hat Hybrid Cloud Console, drawing roughly 80,000 weekly downloads cumulatively (some counts put the figure higher, near 117,000). The dropper swept developer and CI secrets: GitHub Actions tokens, npm tokens, and cloud credentials for AWS, Azure, and Google Cloud, plus Kubernetes, HashiCorp Vault, and SSH keys. This variant added fresh collectors for GCP and Azure cloud identities, a deliberate shift from harvesting secrets toward seizing standing cloud access. Like its Shai-Hulud ancestors it behaved as a worm, using stolen npm tokens to republish itself into other packages and actively trying to evade runtime defences such as StepSecurity's Harden-Runner.

The one piece of good news was containment. No compromised version reached production: Red Hat's publication process strips install-time scripts before deployment to console.redhat.com, and no console release was published during the compromise window. Worth noting for any reader sizing the impact: every quantitative figure here came from outside researchers, not from Red Hat, which published no package, version, or download count of its own.

Who was behind it

The tradecraft matches TeamPCP, the group behind the 2026 Mini Shai-Hulud waves that, on 12 May 2026, open-sourced the worm publicly under the banner "Shai-Hulud: Open Sourcing The Carnage" and even ran a contest for the largest attack built with it. But both Wiz and Unit 42 refuse to call the link definitive. Once the worm was public, any competent actor could reproduce the same attack, so the overlap is evidence of a shared technique, not proof of who pulled the trigger. Microsoft documented Miasma without attributing it to TeamPCP at all. The collapse of clean attribution is itself the consequence of open-sourcing the malware. The full arc, from the first self-propagating worm to publicly released attack code, lives in the Shai-Hulud lineage.

Why it matters

This is the incident where "signed and attested" stopped meaning "safe." Build provenance and SLSA attestations prove that a particular pipeline built a particular package. They are a statement about integrity, not trustworthiness. Subvert the identity that drives the pipeline and the attestation will faithfully sign malware. That moves the defensive centre of gravity onto CI identity: who can trigger a publishing workflow, what an OIDC token is scoped to, and whether a human approves a release before it ships. It is also the first major real-world incident built from open-sourced worm code, the moment the Shai-Hulud technique became a commodity that any actor can pick up and run.