Jun 02, 2026 · 6 min read
Miasma Worm Hits 32 Red Hat npm Packages on June 1
Aikido and OX Security flagged the campaign on June 1, 2026. A compromised Red Hat employee GitHub account pushed orphan commits that triggered a GitHub Actions workflow with OIDC token write permissions. Ninety six malicious package versions shipped from the @redhat-cloud-services namespace before npm yanked them.
The 2025 to 2026 npm worm season has a new entry. On June 1, 2026, security researchers at Aikido and OX Security disclosed Miasma, a credential stealing supply chain attack that compromised 32 packages and 96 versions under the official @redhat-cloud-services npm namespace. Cumulative weekly downloads across the compromised packages: roughly 117,000. Mode of distribution: a Red Hat employee's GitHub account that an attacker quietly took over and used to push orphan commits authorizing a GitHub Actions workflow with id-token: write permissions. The workflow then minted SLSA provenance attestations on its own malicious builds and published them to the npm registry through legitimate, trusted infrastructure.
Key Takeaways
- Aikido and OX Security disclosed the Miasma campaign on June 1, 2026, identifying 32 backdoored npm packages and 96 malicious versions inside the @redhat-cloud-services namespace.
- The compromise traces back to a single hijacked Red Hat employee GitHub account that pushed orphan commits triggering GitHub Actions workflows with OIDC
id-token: writepermissions. - The malicious workflow obtained valid SLSA provenance attestations for the poisoned package builds, meaning supply chain verification tools that trust npm provenance signed off on the attacker's payload.
- Miasma is a variant of the Mini Shai-Hulud framework that TeamPCP open sourced in May 2026, re themed with Greek mythology references replacing the Dune universe references in the original.
- Each install ran a Bun executed credential stealer collecting AWS, GCP, Azure, GitHub, SSH, Docker, and npm tokens, and exfiltrated them through public GitHub repositories created under the description "Miasma: The Spreading Blight."
What Got Compromised?
The compromised namespace, @redhat-cloud-services, is Red Hat's official scope for frontend tooling and API client libraries that power the Red Hat Hybrid Cloud Console and related internal services. Affected packages include @redhat-cloud-services/frontend-components, @redhat-cloud-services/rbac-client, @redhat-cloud-services/insights-client, and @redhat-cloud-services/compliance-client, among 28 others. Per Red Hat's post incident statement, the packages are "strictly limited to internal development" and the company says there is "no impact to customer or partner environments or Red Hat production systems."
The 117,000 weekly downloads figure is the wider blast radius. Any consumer that has the @redhat-cloud-services scope in their package manifest, including community projects, third party integrations, and unaffiliated forks, would have pulled a poisoned version during the publication window. npm has since removed all malicious versions, but yanking from the registry does not retroactively un install from systems that already ran the preinstall hook.
How Did the Attacker Publish Through Legitimate CI?
This is the part that makes Miasma a tier above conventional typosquats. The attacker did not register lookalike packages. They published the real packages, from the real namespace, signed with valid provenance attestations, through Red Hat's real build infrastructure.
The mechanism worked in three moves:
- Account compromise. An attacker gained access to a single Red Hat employee's GitHub account. The exact initial access vector is undisclosed; likely candidates include credential reuse, infostealer harvest, or a session token hijack.
- Orphan commits to RedHatInsights repos. The attacker pushed commits that were not connected to any branch the team was actively reviewing. These commits introduced a GitHub Actions workflow with
id-token: writepermission, designed to fire on any branch push. - OIDC token issuance and package publish. When the workflow ran, GitHub Actions minted a short lived OIDC identity token for the workflow context. The attacker's workflow used that token to publish package versions to npm with valid SLSA provenance attestations.
Any downstream consumer using npm install to pull the compromised versions would see valid signatures, valid attestations, and a familiar publisher. The provenance system was working as designed; the design assumes the publisher account itself is not compromised.
What Did the Payload Do?
Each poisoned package embedded a preinstall lifecycle hook in its package.json. When a developer ran npm install anywhere in the dependency graph that included the compromised package, the preinstall script executed before any application code, before any post install verification, before tests, before linting. The script invoked Bun to run a heavily obfuscated JavaScript loader called _index.js, which dropped a multi stage credential stealer.
Targets of the stealer:
- AWS credential files (
~/.aws/credentials,~/.aws/config) and IMDS metadata where reachable. - Google Cloud Platform application default credentials and
gcloudauth files. - Azure CLI auth caches and managed identity tokens.
- GitHub personal access tokens, including
~/.gitconfig, gh CLI tokens, and GitHub Actions OIDC tokens reachable from the running workflow. - SSH private keys in
~/.ssh/. - Docker config and registry credentials.
- npm tokens from
~/.npmrc.
Exfiltration used a "GitHub dead drop" pattern. The stealer created a public GitHub repository under the victim's own account, named with the description Miasma: The Spreading Blight, and committed the harvested secrets as JSON files. The attacker did not need to register their own exfil server; the abuse infrastructure rode on the same GitHub identity the victim was already authenticated to.
Is This Just Another Shai-Hulud?
Miasma is functionally a re branded Mini Shai-Hulud, with Greek mythology references swapped in for the Dune universe names that gave the original family its identity. TeamPCP, the group widely credited with the late 2025 Shai-Hulud surge, open sourced the toolkit in May 2026 after a series of takedowns made continued private operations less attractive. As Wiz's analysis notes, "similarities observed in this incident should be treated as evidence of TTP overlap rather than definitive attribution"; the open source release has turned a tier one supply chain weapon into something any motivated copycat can deploy.
What is new in this variant: dedicated collectors for GCP and Azure cloud identities. Earlier Shai-Hulud variants leaned heavily on AWS and GitHub harvesting; Miasma's collector set reflects a broader interest in lateral movement through multi cloud environments. Compare with the Nx Console VS Code extension credential stealer from May 20 for a parallel example of marketplace channel abuse.
What Should You Do If You Pulled an Affected Version?
If any system in your environment ran npm install against a package in the @redhat-cloud-services scope between late May and June 1, 2026, treat that system as fully credential compromised. Rotation, not investigation, is the right first move.
Order of operations:
- Rotate any cloud account credentials present on the developer host (AWS access keys, GCP service account keys, Azure tokens).
- Rotate all GitHub personal access tokens and GitHub Actions secrets reachable from the host.
- Re generate SSH keys and remove the old public keys from authorized_keys files across reachable servers.
- Invalidate npm publishing tokens and re audit any packages your team has published in the affected window.
- Search GitHub for public repositories under your team accounts with descriptions matching "Miasma: The Spreading Blight" or recent unexplained public repository creations.
For longer term hardening, the Miasma incident is a clean argument for moving npm installs into ephemeral, network restricted build environments and disabling preinstall hooks in CI where the workflow design allows. The npm CLI's --ignore-scripts flag is the lever for the second control.