On June 1, 2026, researchers identified malicious code embedded in at least 32 package releases published under the @redhat-cloud-services npm namespace—a suite of frontend components and API clients that power the Red Hat Hybrid Cloud Console. The compromised packages carried a preinstall script that ran an obfuscated payload automatically during npm install, harvesting developer credentials, cloud identities, and CI/CD secrets before attempting to spread itself to other packages the victim could publish. With roughly 80,000 combined weekly downloads across the affected namespace, this isn't just a Red Hat internal problem—any project pulling these dependencies has been sitting on an active incident since yesterday.

What the Payload Actually Does

The install-time trigger is straightforward but devastating: npm runs preinstall scripts before any of your own code executes, so simply having the package in your dependency tree was enough to compromise the host. The actual payload—a heavily obfuscated JavaScript file relying on eval() and ROT-based string decoding—matches the (Mini) Shai-Hulud framework that TeamPCP open-sourced earlier this year, though with Greek mythology replacing the original Dune-themed cosmetic elements. Newly created attacker repositories carry the description 'Miasma: The Spreading Blight,' which is a useful hunting signal for defenders. Once executed, the payload harvests secrets from every corner of the compromised environment: environment variables, ~/.npmrc tokens, SSH keys, GitHub PATs, and CI/CD secrets. But this variant goes further than its predecessors—the notable evolution is a pair of new collectors targeting GCP and Azure that enumerate every identity the infected host can assume, not just static credentials. This isn't just credential theft anymore; it's cloud control plane reconnaissance with worm-like propagation built in.

The Root Cause Is What Makes This Scary

Forget typosquatting or poisoned transitive dependencies—this attack got past code review. Evidence indicates a Red Hat employee's GitHub account was compromised and used to push malicious orphan commits directly into two RedHatInsights repositories, bypassing normal review workflows. Those commits added a minimal GitHub Actions workflow that triggered on any push, requested a GitHub OIDC identity token via id-token: write, and executed an obfuscated payload that published packages directly to npm. Here's the kicker: because the publish ran inside a legitimate repository's Actions context, the resulting releases shipped with valid SLSA provenance attestations. The provenance was technically correct—the package really was built by that workflow. What it couldn't tell you was that the workflow itself was unauthorized. This is the same gap TeamPCP exploited against TanStack weeks earlier, where forged-but-valid provenance let malicious packages pass naive verification. Provenance verification is necessary, and it is not sufficient on its own. Full stop.

Blast Radius and Who's at Risk

The direct download numbers undercount the real exposure. These are build-time dependencies for an enterprise console, so most installs happen on developer workstations and CI runners—exactly the environments richest in long-lived cloud credentials, registry tokens, and GitHub PATs. The worm behavior compounds this: a single developer who installed an affected version and has publish rights to other packages can seed the next wave automatically. You are potentially affected if any of these ran since June 1: an npm install or npm ci that resolved an affected @redhat-cloud-services version, or a build in a cloud environment where the runner held GCP, AWS, or Azure identities. Exploitation required no special configuration—the preinstall hook runs by default. The prerequisite was simply installing an affected version.

Detection and Remediation

First, audit your lockfiles: search package-lock.json, pnpm-lock.yaml, and yarn.lock for @redhat-cloud-services entries and cross-reference resolved versions against the Snyk advisories. Second, scan with Snyk—advisories are already live, so a standard test flags affected releases. Third, hunt for compromise artifacts even after removal: look for new GitHub repositories with the 'Miasma: The Spreading Blight' description, unrecognized workflows requesting id-token: write, and newly created tokens you didn't authorize. When remediating, order matters. Because this malware family is known to plant persistence, clean the host before revoking tokens it's watching. Pin away from affected versions (Snyk's lead advisory flags @redhat-cloud-services/frontend-components at <=7.7.2; cutoff versions differ per package), reinstall with scripts disabled via npm install --ignore-scripts, audit attacker-planted hooks in editor configs and task files, then rotate everything reachable—npm tokens, GitHub PATs, SSH keys, and cloud credentials including any roles CI runners could assume.

Hardening the Pipeline Going Forward

This attack exploited gaps that many organizations have: orphan commits bypassing review on protected branches, overly permissive OIDC trust at the repository level, and reliance on provenance alone for verification. Enforce branch protection with required reviews so orphan commits can't slip through, scope OIDC trust to specific branches and workflows rather than whole repos, require 2FA with publish protection on npm, and pair provenance verification with behavioral checks instead of trusting attestations as ground truth. Dependency allowlisting, SBOM generation, and an install-age cooldown before adopting fresh releases all reduce the window this attack relies on.

Key Takeaways

  • At least 32 @redhat-cloud-services packages were compromised in a two-wave attack on June 1, 2026, with ~80,000 weekly downloads affected
  • The payload is a credential harvester and self-propagating worm descended from TeamPCP's (Mini) Shai-Hulud framework
  • Root cause was a compromised Red Hat employee GitHub account pushing malicious orphan commits that requested OIDC tokens for npm publishing
  • Compromised packages shipped with valid SLSA provenance attestations, proving signed code can still be malicious code
  • New collectors target GCP and Azure identity enumeration, not just static secrets—cloud control plane access is the real prize here

The Bottom Line

SLSA provenance was supposed to solve supply chain trust—and it does, partially. But Miasma exposes a critical gap: provenance verifies build integrity, not authorization intent. When an attacker compromises a maintainer account and publishes from a legitimate workflow context, valid attestations become a liability rather than a safeguard. The industry needs to accept that provenance is necessary but nowhere near sufficient. Behavioral verification, allowlisting, and the principle of least privilege for publishing tokens are no longer optional hardening measures—they're baseline requirements.