Miasma: The npm Supply Chain Attack That Bypassed Trusted Publishing

The npm Supply Chain Attack Nobody Saw Coming

On June 1, Aikido Security and OX Security disclosed that 32 packages in the official @redhat-cloud-services namespace on npm were backdoored with a credential-stealing worm called Miasma. The 96 affected versions were being installed roughly 117,000 times per week. The packages carried valid attestations — because the attackers didn’t crack npm’s defences. They borrowed a publishing token that was already authorized to sign and release on Red Hat’s behalf.

This is not a story about a weak security posture at a small open-source project. @redhat-cloud-services is IBM/Red Hat’s official namespace for cloud client libraries, used in production cloud-native stacks. The attack worked precisely because the namespace was trustworthy.

How Miasma Got In

Miasma is a variant of Mini Shai-Hulud, an open-source supply chain attack toolkit. The malicious versions were published through GitHub Actions using a compromised publishing token — bypassing npm’s trusted publishing mechanism, the OIDC-based attestation system that ties a package release to a verified CI/CD pipeline.

Trusted publishing was designed to close attacks where a stolen npm token alone was enough to ship a malicious release. The mechanism works by requiring proof that the build ran through the vendor’s own authorized pipeline (GitHub Actions, GitLab CI, CircleCI, and similar). The problem in this case: the attackers didn’t defeat the cryptographic handshake. They compromised the token that authorized the GitHub Actions workflow itself, then used it to push backdoored releases of 96 package versions across 32 packages. The packages went out carrying Red Hat’s own provenance attestation.

What Miasma Steals — and Why “Worm” Matters

The payload targets the full credential surface of a developer machine or build environment:

• Developer API keys and credentials from environment variables and dotfiles
• Cloud access keys: AWS, GCP, Azure service account tokens
• SSH private keys
• npm publish tokens
• GitHub Actions secrets and CI/CD pipeline tokens

Calling it a worm is not a classification detail — it changes the threat model. A static backdoor exfiltrates what it finds locally. Miasma uses the stolen credentials to propagate laterally: if the infected build environment has push access to other repositories, the worm can extend the attack across the entire project graph. One compromised CI job can become a vector into every project the pipeline touches.

Why Trusted Namespaces Are High-Value Targets

The @redhat-cloud-services namespace is the official home for Red Hat’s cloud client libraries (IBM acquired Red Hat in 2019). Developers consuming these packages have reasonable grounds to trust them — enterprise vendor, established release cadence, widely used in cloud-native stacks. That trust is what made the namespace worth targeting.

The dynamic is identical to the XZ Utils backdoor from 2024: the payload got distributed because the channel was trusted, not despite it. When a package comes from a well-known vendor’s namespace, each install gets less scrutiny. Supply chain attackers have internalized this. Compromising one credentialed token that can publish to a trusted namespace unlocks an attack surface that scales with the vendor’s download numbers.

The Trusted Publishing Lesson

The Miasma incident exposes a gap in how most teams think about trusted publishing: they assume that if the release workflow is guarded, the publishing token is protected by extension. That’s not necessarily true.

Your GitHub Actions release workflow has permissions — either via GITHUB_TOKEN or via explicit npm/PyPI/similar tokens stored as repository secrets. If those tokens are compromised — through a supply chain attack on your own CI tooling, through secret scanning failures, or through excessive token scopes — an attacker can publish releases that pass all of npm’s attestation checks. The trust chain needs to be clean end-to-end.

Concrete gaps to close:

• The GITHUB_TOKEN in a release workflow should have the minimum required permissions. Use permissions: id-token: write, contents: read and nothing broader for a publish workflow.
• Long-lived static npm tokens should be replaced with OIDC where the registry supports it.
• Repository secrets visible to workflows should be scoped by environment and only mounted on the workflows that need them.
• Audit which steps in your CI pipeline can read which secrets — a postinstall hook in a dependency runs in the build environment and has access to everything mounted there.

What to Do Right Now

If any project in your build toolchain depends on @redhat-cloud-services packages, work through this today.

Audit your dependency tree:

• Search package-lock.json and node_modules for @redhat-cloud-services/ packages
• Cross-reference installed versions against the Aikido advisory for affected version ranges
• Run npm audit and look for flagged entries
• Check transitive dependencies — affected packages may not appear in your direct dependency list

Rotate credentials from any environment that ran affected versions:

• Cloud API keys and service account tokens
• SSH private keys on CI machines or developer workstations
• npm publish tokens
• GitHub personal access tokens and Actions secrets
• Any vault or secrets manager credentials mounted in the build environment

The rotation scope should include everything the build environment could reach — not just the credentials you use directly.

What We’re Watching

Three significant npm namespace compromises in the past two weeks: Miasma against Red Hat, a fake codex-ui package exfiltrating OpenAI refresh tokens, and 14 packages mimicking OpenSearch and Elasticsearch libraries. The open-sourcing of toolkits like Mini Shai-Hulud has lowered the entry bar considerably. Anyone who can compromise a publish token can now deploy a self-propagating worm against a trusted namespace.

The trend line is toward attacking the build environment rather than production. Developer machines and CI pipelines hold a higher density of valuable credentials than most production systems do — cloud keys, deploy tokens, signing certificates — and they run third-party code constantly via package install hooks.

For every product we build and ship, the dependency graph is part of the threat surface we reason about. We treat npm audit as a build gate and scope CI/CD secrets to the minimum permissions per job. This incident is a good prompt to audit your own pipeline’s secret surface — not just what you manage directly, but everything a transitive postinstall hook could reach at build time.

Sources

1. Red Hat npm packages compromised to steal developer credentials — BleepingComputer, June 1, 2026
2. Miasma Supply Chain Attack Compromises Red Hat npm Packages with Credential-Stealing Worm — The Hacker News, June 1, 2026
3. Shai-Hulud malware worms Red Hat npm package versions downloaded 80K times a week — The Register, June 1, 2026
4. Miasma worm infests Red Hat npm packages — iTnews, June 2, 2026