Miasma Hits Red Hat npm: Malware with Valid SLSA Provenance

On June 1, 2026, 32 npm packages in the @redhat-cloud-services namespace were compromised via a Red Hat employee's personal GitHub account. The Miasma malware abused OIDC trusted publishing and valid SLSA attestations to masquerade as legitimate software.

On June 1, 2026, the compromise of a Red Hat employee's personal GitHub account turned 32 npm packages in the @redhat-cloud-services namespace into vectors for a credential-stealing worm. The attack exploited no zero-day vulnerabilities or sophisticated injection techniques. Instead, it abused OIDC trusted publishing and perfectly valid SLSA attestations to make the malware indistinguishable from authentic software. The campaign, dubbed Miasma, demonstrates that supply chain security infrastructure can be weaponized against those who built it.

Key Takeaways

On June 1, 2026, 32 npm packages in the @redhat-cloud-services namespace were compromised through a Red Hat employee's personal GitHub account, yielding 96 malicious versions in total.
Attackers injected orphan commits into the frontend-components and javascript-clients repositories, triggering minimal GitHub Actions workflows to obtain OIDC tokens and publish packages with valid SLSA provenance attestations.
The Miasma payload, derived from the Mini Shai-Hulud framework published by TeamPCP on BreachForums on May 12, 2026, uses multi-layer obfuscation and per-infection encryption, rendering hash-based IOCs effective only for individual versions.
The malware harvests credentials from cloud environments, CI/CD pipelines, browsers, and wallets, self-propagates via the npm registry, and exfiltrates data through public GitHub repositories belonging to victims.

The Mechanism: OIDC and SLSA in Service of Malware

The attack unfolded in two waves on June 1: the first at 10:53 UTC, the second between 13:44 and 13:46 UTC, with specific commit SHAs documented by Wiz Research. Attackers compromised a Red Hat employee's personal GitHub account — not a corporate account — and injected orphan commits into the RedHatInsights/frontend-components and RedHatInsights/javascript-clients repositories.

These commits introduced minimal GitHub Actions workflows designed to request OIDC tokens for npm trusted publishing. Once the token was obtained, the compromised packages were published with perfectly valid SLSA (Supply Chain Levels for Software Artifacts) attestations. According to Microsoft Threat Intelligence, the packages "carried authentic provenance signatures"; Wiz Research confirms they were "published packages with valid SLSA provenance attestations." The result: the packages appeared authentic to standard security scanners, which verify signature and provenance without analyzing the actual payload.

The compromise produced 96 malicious versions — some sources cite "90+" per Microsoft — distributed through an estimated 80,000 weekly downloads per Wiz Research, up to 117,000 per preliminary Red Hat analysis cited by The Record. Most malicious versions were revoked within hours; two remained active at the time of Wiz's initial report.

Payload Anatomy: Obfuscation, Bun, and the Destructive Tripwire

The Miasma payload, 4.29 MB per Microsoft's analysis, activates via a preinstall script that executes automatically during npm install. The execution chain is unusual: a node process spawns a shell, which downloads and launches the Bun JavaScript runtime, which in turn executes the secondary payload.

The obfuscation is multi-layered and intentionally sophisticated. The payload employs ROT decoding, AES-128-GCM decryption, Obfuscator.io obfuscation, and a custom cipher based on PBKDF2-HMAC-SHA-256. According to Rescana and Wiz, each infection generates a uniquely encrypted payload: this mechanism renders hash-based indicators of compromise effective only for specific versions, complicating network-level detection and incident response.

Microsoft Threat Intelligence documented ten stages of the attack chain, from initial load to final exfiltration. One stage relevant to CI/CD environments: the malware scans /proc/[pid]/cmdline for 'Runner.Worker' processes, then extracts secrets via pattern matching on isSecret:true, harvesting GitHub tokens, npm credentials, and other secrets from the runner's memory space.

The payload includes a destructive tripwire mechanism: if it detects a decoy token, it executes rm -rf ~ to wipe the victim's home directory. Exfiltration occurs through three C2 channels, including public GitHub repositories with randomized names belonging to the victims themselves — a technique that abuses legitimate platform infrastructure to hide malicious traffic.

Miasma and Its Lineage: From the Desert of Arrakis to Greek Mythology

The malware is a variant derived from the Mini Shai-Hulud framework, published as open-source on BreachForums on May 12, 2026, by the group TeamPCP. Wiz Research documented that modifications from the original are "largely cosmetic," with references to the Dune universe replaced by Greek mythology themes: the campaign marker is "Miasma: The Spreading Blight," while elements like "spartan" replace the original references.

Despite superficial changes, core functionality and tradecraft remain "substantially similar" per Wiz. Miasma does introduce new collectors for cloud identities: specifically, modules for GCP and Azure identity enumeration, absent in the original Shai-Hulud version. This evolution indicates a deliberate focus on multi-cloud enterprise environments.

Attribution to TeamPCP is assessed with "medium confidence" by multiple sources. The Record notes the full source code was made public, enabling copycat activity. The dossier does not establish whether the June 1 attack was conducted directly by TeamPCP or by an actor who reused the published framework.

What to Do Now

Audit lockfiles and transitively linked dependencies: check for versions in the @redhat-cloud-services namespace installed on or after June 1, 2026, paying attention to transitive dependencies that may not be visible in primary manifests.
Full rotation of potentially exposed credentials: include personal and organization GitHub tokens, npm tokens, AWS/GCP/Azure credentials, SSH keys, HashiCorp Vault tokens, Kubernetes tokens, and secrets stored in GitHub Actions runners, given the malware's access to CI/CD process memory space.
Reassess trust boundaries for OIDC trusted publishing: the compromise of a personal account bypassed corporate controls; publishing pipelines must implement additional content verification beyond provenance validation, including static code analysis before SLSA signing.
Strengthen monitoring for anomalous process chains: the node → shell → bun → payload pattern is atypical for the npm ecosystem and should be flagged as an indicator of compromise in EDR platforms and runtime logs.

The Lesson: When a Valid Signature Is No Longer Enough

The Miasma case inverts conventional supply chain security logic: the trust infrastructure became the attack infrastructure. OIDC trusted publishing and SLSA provenance were designed to guarantee software originates from a legitimate pipeline; here they guaranteed exactly that, even when the pipeline was compromised at the source. The problem is not in the attestation technology, but in the assumption that signature validation implies content validation.

For enterprise organizations, the consequence is a necessary recalibration of the threat model. Segregation between personal and corporate accounts, orphan commit controls, pre-publication content analysis, and runtime monitoring must become additional layers — not replacements — of provenance verification. Supply chain security now demands "verify after trusting," not merely "trust but verify."

Red Hat confirmed that no official product shipped with compromised versions. The company's preliminary analysis, cited by The Record, states that "based on current findings, no actions from customers are required." However, this assessment refers to Red Hat product distribution, not the direct installation of npm packages by development teams that may have acquired malicious versions before revocation.

"The payload appears to be derived from the (Mini) Shai-Hulud malware open-sourced by TeamPCP. The observed modifications are largely cosmetic, with references to the Dune universe replaced by Greek mythology themes (i.e 'spartan'), while the underlying functionality and tradecraft remain substantially similar." — Wiz Research

Frequently Asked Questions

Why didn't security scanners detect the compromised packages?: The packages had valid SLSA attestations and authentic signatures, generated via OIDC trusted publishing from a legitimate pipeline. Scanners that verify only provenance and signature do not analyze the actual payload content, which was obfuscated and uniquely encrypted per infection.
What is the difference between the June 1 Miasma/Red Hat incident and the July AsyncAPI 'miasma-train-p1' incident?: They are distinct campaigns. The June 1 incident targeted the @redhat-cloud-services namespace with initial access via a compromised personal GitHub account. The July AsyncAPI incident, documented by Unit42, uses an evolved payload but with a different initial access vector and operational context. They should not be treated as the same event.
Why is attribution to TeamPCP uncertain?: The Mini Shai-Hulud source code was published publicly on BreachForums on May 12, 2026. This availability makes it impossible to distinguish with certainty between the original actor and operators who reused the framework, which is why sources assess attribution with "medium confidence."

Information verified against cited sources and current as of publication.

Sources

Sources and references