Red Hat npm Packages Hit by Miasma Credential Worm

Our catalog is still tracking fallout from the Red Hat npm packages compromise, with the affected @redhat-cloud-services entries re-flagged as critical on 2026-07-10. The short version: on June 1, 2026 at least 32 packages published under the @redhat-cloud-services npm scope shipped a credential-stealing worm called Miasma. The malware ran automatically through a preinstall hook on every npm install, before any application code executed. It targeted CI/CD runners and developer machines, harvested cloud and registry credentials, and then republished poisoned packages on its own. The detail that should worry every team: the trojanized versions carried valid SLSA provenance, so tools that check "was this built by the right pipeline" answered yes.

What happened

Several packages in the @redhat-cloud-services npm scope were found carrying a multi-stage credential harvester that fired during installation. StepSecurity flagged the malicious releases on June 1, 2026, and Microsoft, Wiz, Orca, and Sonatype published parallel analyses the same day.

Red Hat's own advisory, RHSB-2026-006, traced the root cause. A Red Hat employee's GitHub account was compromised on May 29, 2026 through a Visual Studio Code extension that contained malware. That account was then used to inject malicious code into packages maintained in a Red Hat GitHub organization and to alter configuration files so that other developers who opened those directories were infected too. The compromised extension was contained on June 1, 2026.

From that foothold the attacker pushed malicious orphan commits into RedHatInsights repositories (including RedHatInsights/javascript-clients), bypassing code review entirely. The commits added a minimal GitHub Actions workflow that requested an OpenID Connect (OIDC) token with id-token: write, then ran an obfuscated payload that published packages through the legitimate trusted-publisher flow. Microsoft counted 32 maliciously modified packages across more than 90 versions. Wiz put the cumulative reach at roughly 80,000 weekly downloads.

Red Hat states that no release of the Hybrid Cloud Console (console.redhat.com) was published during the compromise window, and that its publication process strips installation-time scripts from packages before deployment. The exposure is on the npm side, for anyone who pulled the affected versions directly.

Timeline

• May 12, 2026: The fully weaponized Mini Shai-Hulud source code, the toolkit Miasma is derived from, is published to public GitHub repositories and then taken down (Unit 42).
• May 29, 2026: A Red Hat employee GitHub account is compromised via a malicious VS Code extension (RHSB-2026-006).
• June 1, 2026, around 10:53 UTC and again around 13:44 UTC: two short bursts of malicious publishes hit the @redhat-cloud-services scope (Orca timestamps the waves at 10:53:00 to 10:53:33 and 13:44:00 to 13:46:47 UTC).
• June 1, 2026: StepSecurity, Microsoft, Wiz, Orca, and Sonatype publish analyses; issue #492 is opened on the javascript-clients repo listing affected versions. The malicious VS Code extension is contained.
• June 3, 2026: Red Hat completes its investigation and updates RHSB-2026-006.
• July 10, 2026: our incident catalog updates the affected @redhat-cloud-services package entries.

Who is affected

Any environment that ran npm install or npm ci and resolved one of the poisoned versions between the publish times and takedown is in scope. Linux CI/CD runners were the primary target, because they install dependencies non-interactively, thousands of times a day, with broad credentials in memory. Developer workstations were hit too, where the payload also went after SSH keys, CLI credentials, and browser and wallet data.

The affected libraries are frontend JavaScript components used across the Hybrid Cloud Console interface, which means broad downstream adoption through transitive dependencies. Representative packages and their malicious versions from issue #492 include:

• @redhat-cloud-services/chrome: 2.3.1, 2.3.2, 2.3.4
• @redhat-cloud-services/compliance-client: 4.0.3, 4.0.4, 4.0.6
• @redhat-cloud-services/config-manager-client: 5.0.4, 5.0.5, 5.0.7
• @redhat-cloud-services/entitlements-client: 4.0.11, 4.0.12, 4.0.14
• @redhat-cloud-services/eslint-config-redhat-cloud-services: 3.2.1, 3.2.2, 3.2.4
• @redhat-cloud-services/frontend-components: 7.7.2, 7.7.3, 7.7.5
• @redhat-cloud-services/notifications-client: 6.1.4

That is a sample, not the full list. Our catalog tracks individual entries such as frontend-components-utilities, config-manager-client, insights-client, remediations-client, and the hcc-kessel-mcp package. Treat any of the 32 packages as suspect if the installed version was published in that window.

How the attack works

Each poisoned package declared a preinstall script that ran node index.js. The giveaway is the file size. A normal index.js for these libraries is around 200 KB. The malicious one was about 4.2 to 4.29 MB, a roughly 25x increase that is itself a reliable detection signal. The payload is buried under several obfuscation layers, including ROT-based encoding followed by AES-128-GCM decryption.

Once decoded, the dropper downloads the Bun JavaScript runtime for the current platform and launches a second-stage stealer. That stealer sweeps GitHub Actions secrets, npm and CircleCI tokens, and credentials for AWS, GCP, Azure, HashiCorp Vault, and Kubernetes. On CI runners it scrapes secrets directly from GitHub Actions runner process memory and installs a passwordless sudo rule to escalate. Stolen data leaves through three separate command-and-control channels, one of which abuses GitHub infrastructure.

Then it spreads. Using stolen npm tokens and npm's bypass_2fa parameter, the worm republishes backdoored versions of other packages the victim can publish, even against accounts protected by two-factor authentication. It forges SLSA provenance attestations through Sigstore (Fulcio and Rekor), so the reinfected packages look legitimate to provenance checks. The attacker-created repositories carry the description "Miasma: The Spreading Blight," which is where the payload gets its name. There is also a destructive tripwire: a decoy honeytoken named IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner whose revocation can trigger a wiper routine that deletes the user's home directory.

How to check if you are affected

Search your lockfiles, SBOMs, and package caches for the scope and the specific versions. Run these from the repository root:

grep -R "@redhat-cloud-services" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null
npm ls --all 2>/dev/null | grep "@redhat-cloud-services"

Check whether a resolved version matches the compromised list above, and pull CI logs for the same:

grep -Rin "@redhat-cloud-services" .github/workflows/ ci/ 2>/dev/null

Look for the install-time fingerprints on any runner or workstation that built during the window. An oversized index.js in the package directory and a preinstall invocation of node index.js are the two clearest signals:

find ~/.npm/_cacache node_modules -path "*redhat-cloud-services*" -name "index.js" -size +1M 2>/dev/null

On GitHub, audit for repositories you did not create that carry the description "Miasma: The Spreading Blight," and review npm and cloud audit logs for unexpected token use or package publishes during the exposure window.

Remediation

Assume credential exposure first, dependency cleanup second. If an affected version touched a build runner or a developer machine, the local secrets present at install time should be treated as compromised.

Rotate everything the payload targets, and do it from a clean host: GitHub personal access tokens, npm tokens, AWS, GCP, and Azure keys, Vault tokens, Kubernetes credentials, SSH keys, Docker registry credentials, and GPG keys. Rebuild CI runners, containers, and workstations where you cannot rule out execution rather than trusting a cleanup in place.

Pin your dependencies to known-good versions and reinstall with scripts disabled while you triage:

npm ci --ignore-scripts

To make this the default across a project or an agent, set the config explicitly:

npm config set ignore-scripts true

Add a cooldown so freshly published versions are not served immediately. Most of these compromises are taken down within hours, so a hold of even one to three days blocks the window entirely. If your tooling supports it, set a minimum release age in .npmrc, or enforce the same policy in Artifactory or Nexus:

# .npmrc
minimumReleaseAge=1440

Finally, check any runner where the payload may have run for a lingering passwordless sudo rule and remove it, and confirm the wiper tripwire did not fire before you revoke unfamiliar tokens.

FAQ

Are the @redhat-cloud-services npm packages safe to use now?

The clean, current releases are fine. The specific compromised versions have been removed and npm added protections on the namespace to prevent unauthorized publishing. The risk is historical: if you installed one of the affected versions between the June 1, 2026 publish times and their takedown, that build environment and its credentials should be treated as exposed.

How do I know if I was affected by the Miasma npm worm?

Check lockfiles and CI logs for @redhat-cloud-services at one of the listed malicious versions. On any host that installed one, look for an index.js over 1 MB inside the package directory and a preinstall step that ran node index.js. If either is present, rotate the credentials that were reachable during that install and rebuild the host.

Did the compromise affect the Red Hat Hybrid Cloud Console?

According to Red Hat's RHSB-2026-006 advisory, no Hybrid Cloud Console release was published during the compromise window, and its publication process strips installation-time scripts before deployment to console.redhat.com. The impact was on the npm packages themselves, affecting developers and CI pipelines that consumed the poisoned versions directly.

What is the difference between Miasma and Shai-Hulud?

Shai-Hulud is the original self-replicating npm worm from September 2025 that compromised more than 500 packages. Miasma is a later variant derived from Mini Shai-Hulud, whose source TeamPCP published on May 12, 2026. The Red Hat campaign added a new twist: it abused a legitimate GitHub Actions OIDC publishing workflow to produce trojanized packages with valid SLSA provenance, which the earlier waves did not do.