The Miasma Worm Caught Red Hat: When Your CI/CD Pipeline Becomes the Hacker’s Most Trusted Tool

The Attack at a Glance

What makes this incident different from the hundred other npm malware scares you’ve read about is the attack chain. This wasn’t a typosquatted package or a maintainer handing over their credentials. This was a sophisticated, multi-stage worm that exploited the very security infrastructure designed to prevent this exact scenario.

The numbers are sobering:

• 31+ compromised packages across the @redhat-cloud-services namespace
• 95 malicious versions pushed across two waves of activity
• ~80,000 weekly downloads cumulatively for the affected packages
• 4.2 MB obfuscated payload per compromised version
• Attack time window: Under 3 hours from first commit to takedown

Here’s the full list of compromised packages, sorted by scope:

Every one of these belongs to a legitimate Red Hat npm scope. Every version carried a preinstall hook that executed automatically. Every one of them was published through a pipeline that had more security controls than most organizations will ever implement.

The Root Cause: Orphan Commits and Empty Code Review

The Wiz research team tracked the initial compromise to a specific Red Hat employee’s GitHub account. The attacker pushed orphan commits, commits with no parent, detached from the repository’s history tree, directly to three RedHatInsights repositories:

Here’s the kicker: these were orphan commits. They didn’t show up in pull requests. They bypassed branch protection rules. And in many repositories, commits pushed directly by a trusted contributor with write access don’t trigger code review workflows.

A second wave hit three hours later:

Each commit contained two files: a GitHub Actions workflow YAML and an obfuscated _index.js payload. The workflow was the weapon.

The CI/CD Pipeline: Trusted Publishing Turned Against Its Owners

This is where the attack gets clever. The workflow file the attacker injected is worth examining in detail:

name: release
on:
  push:
    branches: ['*']
jobs:
  release:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
      - uses: oven-sh/setup-bun@0c5077e51419868618aeaa5fe8019c62421857d6
      - name: prepare
        run: bun run _index.js
        env:
          OIDC_PACKAGES: "@redhat-cloud-services/frontend-components, @redhat-cloud-services/chrome, ..."
          WORKFLOW_ID: "ci.yaml"
          REPO_ID_SUFFIX: "RedHatInsights/frontend-components"

Let’s break down what this does:

1. on: push: branches: ['*'] – Triggers on any push to any branch. Including orphan commits pushed directly to main.
2. id-token: write – Requests GitHub’s OIDC identity token. This is the same permission used for legitimate trusted publishing.
3. uses: oven-sh/setup-bun – Installs the Bun JavaScript runtime. Bun is fast, modern, and, importantly, can compile single-file executables.
4. bun run _index.js – Executes the attacker’s payload with full access to GitHub’s OIDC token.

The _index.js payload uses that OIDC token to authenticate with npm’s trusted publishing endpoint. It doesn’t need long-lived npm tokens. It doesn’t need API keys. It needs exactly one thing: the ability to request a short-lived identity assertion that npm accepts as proof that “Red Hat wants to publish this package.”

And it gets that permission because the workflow is running inside Red Hat’s GitHub organization, triggering against Red Hat’s repositories.

The Aikido research team documented this pattern in detail. This is the same fundamental technique used in the TanStack compromise: the CI/CD pipeline itself becomes the attack surface, while OIDC-based trusted publishing, designed to eliminate long-lived tokens, becomes a misleading trust signal.

The Miasma Payload: Shai-Hulud 2.0

The payload itself is a variant of the Mini Shai-Hulud malware that TeamPCP open-sourced in May 2026. But “Miasma” introduces significant upgrades:

Rebranded and Repurposed

The original Shai-Hulud drew heavily from Dune references. Miasma replaces those with Greek mythology themes. The descriptions of attacker-created GitHub repositories changed from “Shai-Hulud: The Third Coming” to “Miasma: The Spreading Blight.”

Per-Infection Encryption

This is a major operational security improvement for the attacker. Previous Shai-Hulud variants used static payloads. Miasma generates a uniquely encrypted payload for each infection, making hash-based detection effectively useless beyond identifying one specific package version.

Expanded Cloud Identity Collection

According to the Wiz analysis, “one of the main changes in this new variant is the addition of new data collectors focused on cloud identities. Specifically, collectors for GCP and Azure identities were added that collect all identities the infected machine has access to.”

Previous versions focused on extracting secrets from these environments. Miasma wants access, the ability to assume those identities itself.

The Preinstall Hook

Each compromised package declares this in its package.json:

"scripts": {
  "preinstall": "node index.js"
}

The index.js file is a 4.2 MB payload hidden behind multiple layers of obfuscation. It executes the moment a developer runs npm install, before any application code imports the package. Before the developer even knows something is wrong.

What It Steals

The credential sweep is comprehensive:

• AWS: EC2 Instance Metadata Service v2, ECS task metadata, environment credentials, STS GetCallerIdentity/AssumeRole, Secrets Manager enumeration across 16+ regions
• GCP: Application default credentials, service account key files
• Azure: Service principal credentials, managed identity tokens
• HashiCorp Vault: VAULT_TOKEN and VAULT_AUTH_TOKEN environment variables
• npm: Token validation via /-/whoami, publish token enumeration
• GitHub Actions: GITHUB_TOKEN, ACTIONS_RUNTIME_TOKEN, repository context
• General: SSH private keys, Docker registry credentials, GPG keys, .env files

Exfiltration and Propagation

Stolen data is encrypted and exfiltrated through two channels:
1. Primary: Web request to api.anthropic[.]com:443/v1/api
2. Fallback: Committed to attacker-created public GitHub repositories via the GitHub API

The propagation mechanism is where this gets truly dangerous. The malware uses stolen npm publish tokens to repackage and publish backdoored versions of packages the victim account has access to. It calls the OIDC token exchange and whoami endpoints, repackages a tarball, and signs the artifact through Sigstore.

One infected developer workstation can lead to dozens more compromised packages.

Why This Attack Was Inevitable

The Miasma attack exploits a fundamental tension in modern software delivery: We built trust mechanisms that trust the wrong things.

The OIDC Paradox

OIDC trusted publishing was designed to eliminate long-lived credentials. The theory was sound: short-lived tokens reduce the blast radius of credential theft. But the implementation assumes that a request coming from a trusted CI/CD pipeline is a legitimate request.

When an attacker can inject workflow files into that pipeline, through a compromised developer account, a leaked token, or a supply chain attack on a CI dependency, the entire trust model collapses. The pipeline becomes a weapon, not a guardian.

As the Ars Technica coverage notes, “The malware devotes considerable attention to CI/CD systems, which allow for faster and more reliable software releases by automating the building, testing, and deploying of code changes.”

The attacker’s workflow requested exactly two permissions: id-token: write and contents: read. That’s it. No write access to secrets. No repository administration. Just the ability to request a token and read repository contents. And that was enough to publish malicious packages with valid SLSA provenance.

The Orphan Commit Problem

Most organizations have branch protection rules, required pull request reviews, and status checks. But these protections typically apply to pull requests, not to direct pushes by users with write access. An orphan commit bypasses all of this because it has no relationship to the existing branch, it creates a new root in the commit graph.

The question every organization needs to answer: Does your code review system catch a commit that has no parent, pushed by a trusted maintainer, to a branch that doesn’t exist in any pull request?

The Package Registry Trust Gap

When an npm package arrives with valid SLSA provenance attestations, most developers and automated systems treat it as verified and trustworthy. But SLSA provenance proves that a specific CI/CD pipeline built and published the package. It doesn’t prove the CI/CD pipeline wasn’t compromised.

The Attribution Problem

The Wiz team was careful to note that “because TeamPCP publicly released details and code related to the Mini Shai-Hulud operation, other threat actors may be able to replicate or adapt the same techniques. As a result, the similarities observed in this incident should be treated as evidence of TTP overlap rather than definitive attribution to TeamPCP.”

This is the new reality: open-source supply chain attack tooling. TeamPCP published their source code on GitHub in May 2026. They posted on BreachForums encouraging others to run their own campaigns. The barrier to entry for conducting a sophisticated supply chain attack has dropped from “elite APT group” to “anyone who can follow a README.”

The broader pattern of npm registry compromises shows this isn’t isolated. The Miasma attack follows the same playbook as the TanStack, Bitwarden, and SAP compromises, all within the past two months.

Defensive Architecture: Surviving Compromised CI/CD

Given that the attack vector was CI/CD pipeline compromise, not npm token theft, organizations need to fundamentally rethink their defense posture. Here’s what an architecture designed to survive compromised dependencies looks like:

1. Disable Preinstall Scripts in CI

This is the single most impactful change. Run npm install --ignore-scripts in every CI pipeline. If you need postinstall scripts for legitimate reasons, run them explicitly after audit checks.

# In every CI/CD pipeline
npm install --ignore-scripts
# Or set globally
npm config set ignore-scripts true

2. Implement Dependency Pinning with Lockfile Verification

Lockfiles prevent surprise version upgrades. But verify them against known-good hashes using tools like npm audit with continuous monitoring.

3. Monitor for Forced OIDC Token Requests

The attacker’s workflow requested id-token: write permission. Organizations should audit all workflows requesting this permission and alert on any unexpected usage.

4. Branch Protection for Trusted Committers

Implement repository rules that require pull request reviews for all commits, including those from administrators and organization owners. The orphan commit vector can be mitigated by requiring that all commits go through PR review.

5. CI/CD Workflow Integrity Verification

Treat workflow YAML files as code. Scan them with the same rigor as application code. Monitor for workflows that:
– Execute arbitrary code with id-token: write permission
– Have suspicious package names in environment variables
– Trigger on pushes to ['*'] (all branches)

The Regulatory Implications

The Miasma attack has implications beyond technical architecture. The parallel PyPI supply chain incidents with credential theft and this npm attack suggest a coordinated campaign targeting the infrastructure that delivers open source software.

The European Cyber Resilience Act and similar regulations will likely push toward:
– Mandatory attestation of CI/CD pipeline integrity
– Audit trails for all package publication events
– Requirements for package signing with hardware-backed keys
– Liability for package registries that fail to detect malicious activity

Organizations that can demonstrate proactive supply chain security measures will have a compliance advantage.

The Human Cost

Behind the technical analysis is the reality that someone lost their credentials. A Red Hat employee’s GitHub account was compromised, possibly through a previous supply chain attack, a phishing campaign, or credential reuse.

The Ars Technica coverage notes the devastating cycle: “The Checkmarx credentials used in the first attack came from a supply chain attack on the Trivy software developer. The pivot to Checkmarx and its failure to fully remediate the initial breach demonstrates the difficulty of completely recovering from such security lapses.”

This is how supply chain attacks compound. One compromise leads to another. Each breach expands the attacker’s reach. No single organization is safe unless the entire ecosystem improves its security posture.

Immediate Actions

If your organization uses any @redhat-cloud-services packages:

1. Check your lockfiles for any of the affected versions. Run npm ls @redhat-cloud-services/* across all projects.
2. Assume credentials are compromised. Rotate all CI/CD secrets, cloud provider credentials, npm tokens, and SSH keys.
3. Audit CI/CD pipelines for unexpected workflow files, especially those requesting id-token: write permission.
4. Review GitHub activity for repositories created with description “Miasma: The Spreading Blight.”
5. Scan for persistence artifacts: changes to ~/.claude/settings.json, .vscode/tasks.json, .github/workflows/codeql.yml, and .github/setup.js.
6. Disable preinstall scripts globally until you’ve verified your dependency tree.

As the Socket research team noted: “Because the malware includes background execution and potential developer-tool persistence mechanisms, uninstalling the npm package or deleting node_modules should not be considered sufficient cleanup.”

The Bottom Line

The Miasma attack on Red Hat’s npm packages is a watershed moment for cloud native security. It demonstrates that our trust models, OIDC, trusted publishing, SLSA provenance, CI/CD pipeline integrity, can all be subverted if the initial breach occurs at the right point in the chain.

The human factors and maintenance risks in critical open source dependencies combined with the automated tooling as an attack vector in package distribution create a threat landscape where no company, not even Red Hat, is immune.

The solution isn’t more signatures, more attestations, or more blockchain provenance tracking. Those mechanisms trust the issuer, and the issuer can be compromised. The solution is defense in depth that assumes the issuer is compromised.

Lock your lockfiles. Disable preinstall scripts in CI. Monitor your OIDC token usage. And never assume that a signed artifact is a safe artifact.

The Miasma worm proved that trust is a liability. Time to architect accordingly.