Miasma Worm Hijacks 96 Versions of 32 Official @redhat-cloud-services npm Packages to Sweep Cloud Credentials

On June 1, 2026, between roughly 10:54 and 14:23 UTC, an attacker pushed 96 malicious versions across 32 official packages in the @redhat-cloud-services npm namespace, publishing them in three rapid waves from inside Red Hat's own GitHub Actions trust boundary before the registry caught on (Wiz, BleepingComputer). The compromised packages collectively pull around 117,000 weekly downloads and underpin the Red Hat Cloud Services console and Hybrid Cloud Console frontends, so the blast radius extended well past Red Hat's own developers and into every team that consumes those frontend components.

The mechanism is the most interesting part of the incident, and the most uncomfortable. According to the Wiz writeup, the attacker started with a compromised Red Hat employee GitHub account and used it to abuse the OpenID Connect tokens that three RedHatInsights repositories (frontend-components, javascript-clients, and platform-frontend-ai-toolkit) hand to GitHub Actions during routine CI runs (Wiz). With those short-lived OIDC tokens in hand, the attacker did not need to forge anything, because they republished the legitimate tarballs through Red Hat's own publishing pipeline with a single preinstall hook injected, which preserved package provenance and made the malicious releases look, on the surface, identical to anything the team had shipped before.

The injected preinstall payload is a new variant of the Mini Shai-Hulud npm worm that researchers have named Miasma: The Spreading Blight (JFrog, Sonatype). It runs the moment a developer or CI job executes npm install against an affected version, and the sweep it performs is deliberately wide. The harvest targets cloud identities across AWS, GCP, and Azure, SSH private keys, npm and PyPI publish tokens, the GITHUB_TOKEN and ACTIONS_RUNTIME_TOKEN that GitHub Actions injects into every job, Kubernetes kubeconfig files and service account tokens, HashiCorp Vault tokens, Docker registry credentials, and any .env files within reach (Snyk).

Miasma also tries to spread, and the propagation step is what turns a single compromised maintainer account into an ecosystem incident. Where a stolen npm token grants publish rights to other packages, the worm reuses that access to inject itself into the next set of releases the victim is authorized to ship, which is the same self-propagating pattern the original Shai-Hulud strain made famous (safedep, The Hacker News). Most malicious versions were yanked from the npm registry within hours of discovery, but anyone who built or installed during that window already paid the cost in cleartext credentials sitting in the worm's exfil stream.

Why this class of risk slips past your program

Most vulnerability programs are trained on named CVEs against named products, and an install-time credential thief with no CVE assigned to it does not fit cleanly into that workflow. The signal you actually need lives in your lockfile and CI logs rather than in NVD, because the malicious version of @redhat-cloud-services/frontend-components looks structurally identical to the clean release sitting next to it on the registry. Standard software composition analysis sees a known package and a recognizable maintainer, and the difference between safe and compromised is a handful of preinstall lines that fire before any static scanner gets a chance to evaluate the artifact at rest.

The OIDC pathway makes detection harder still, because the publishing identity in this case was Red Hat's own GitHub Actions pipeline, so the malicious releases inherited the provenance markers that defenders normally rely on to filter out impersonation attacks (Wiz). Any heuristic that asks whether the publisher looks legitimate answers yes here, which is why the only durable detection surface is the behavior of the install step itself and the network egress it triggers, not the static reputation of the package.

Prioritizing with TRIS

There is no CVE to anchor a CVSS conversation against, which is precisely the gap TRIS, the multi-layer Threat and Risk Intelligence Scoring inside CVEasy AI, was built to close. Rather than waiting for a base score that will never arrive, TRIS pulls together the three signals that decide whether an exposure deserves your first hour of attention:

• Active exploitation. The Miasma payload ran in the wild on June 1 and was confirmed end to end by Wiz, Snyk, JFrog, Sonatype, and others, so TRIS ranks it as live regardless of the missing CVE identifier.
• Blast radius. Stolen npm and cloud tokens reach far beyond the original install host because they let the attacker pivot into cloud accounts, registries, and other downstream packages, so TRIS treats a confirmed install as an organization wide credential incident.
• Real exposure. TRIS narrows the alert to repositories and pipelines that actually resolved an @redhat-cloud-services package on June 1, 2026, so rotation work targets the installs your lockfile and CI history can prove happened.

What you get is a defensible ordering for the question that matters in the first hour of a worm like this, which is which of my pipelines actually pulled a poisoned tarball and which credential do I rotate first.

Remediation steps

1. Diff your lockfiles against the per package version lists in the Wiz, Snyk, and JFrog advisories and flag any environment that resolved an affected @redhat-cloud-services version between 10:54 and 14:23 UTC on June 1, 2026.
2. Treat every credential reachable from those environments as burned, and rotate AWS, GCP, and Azure keys, SSH private keys, npm and PyPI publish tokens, GitHub Actions secrets including GITHUB_TOKEN and ACTIONS_RUNTIME_TOKEN, kubeconfig and service account tokens, HashiCorp Vault tokens, Docker registry credentials, and the contents of any .env file in scope.
3. If your organization publishes its own npm packages, audit your npm publish history for unauthorized releases that may have been pushed by the worm using one of your stolen tokens, since self propagation through stolen publish access is part of the documented behavior of this variant.
4. Pin @redhat-cloud-services dependencies to known good versions confirmed by the vendor advisories and re-run install to pull clean replacements from the registry.
5. Tighten the OIDC trust on your own GitHub Actions workflows by scoping tokens narrowly and requiring human approval on any job that releases to a public registry, so a compromised maintainer account on your side cannot reach the same primitive the attacker used here.

How CVEasy AI surfaces this

When a credential sweeping worm like Miasma breaks against the npm registry, CVEasy AI ingests the indicators and the per package version lists from the responding research teams the moment they land, then ranks the real exposure with TRIS against your actual lockfiles and CI history, entirely on your own hardware. As the number one local-first CTEM platform, CVEasy AI never ships your dependency graph, secret inventory, or build logs to a third party, which carries extra weight when the incident itself is wholesale credential theft out of developer and CI environments. The platform answers the practitioner question before anything else, which is that these specific pipelines and developer machines of yours pulled a poisoned @redhat-cloud-services release, here is the order in which to rotate their tokens, and here is the lockfile change that returns each project to a known good version.

References

• Wiz Research: Miasma supply chain attack targeting Red Hat npm packages
• Snyk: Miasma supply chain attack, malicious code in Red Hat Cloud Services npm packages
• JFrog Research: Shai-Hulud Miasma variant in Red Hat Cloud Services
• Sonatype: Red Hat Cloud Services npm packages hijacked
• BleepingComputer: Red Hat npm packages compromised to steal developer credentials
• The Hacker News: Miasma supply chain attack compromises Red Hat npm packages
• safedep: Red Hat Cloud Services hit by Mini Shai-Hulud npm worm