← All posts

Miasma worm compromises Red Hat npm packages on June 1

A compromised GitHub account let attackers publish trojanized versions of 32 @redhat-cloud-services packages through legitimate CI. The payload stole credentials and tried to spread.

Koban Team
  • npm
  • supply-chain
  • miasma
  • red-hat

On June 1, 2026, researchers spotted malicious versions of more than thirty packages under the @redhat-cloud-services npm scope. The packages carried a credential-stealing worm researchers called Miasma.

The root cause was a compromised Red Hat employee GitHub account. Attackers pushed orphan commits into RedHatInsights repositories and let the existing GitHub Actions release workflows do the rest. Those workflows used OIDC tokens to publish the bad tarballs. The packages carried valid SLSA provenance because the build pipeline itself was the one doing the publishing.

What the payload did

The dropper was large and heavily obfuscated. On install it ran through a preinstall hook in the first wave. It harvested:

  • GitHub and npm tokens
  • Cloud credentials from AWS, GCP, and Azure
  • Kubernetes service account tokens and Vault secrets
  • CI secrets, including some masked ones pulled from runner process memory

It then tried to republish itself into any other packages the stolen tokens could reach. Exfiltration went through GitHub API calls that created throwaway repos as dead drops. Many of those repos carried names or descriptions that referenced "Miasma: The Spreading Blight" or Shai-Hulud taunts.

Red Hat moved quickly. They removed the bad versions and published advisory RHSB-2026-006. The company noted that the affected packages were internal frontend tooling for console.redhat.com and that their publication process strips install scripts before customer-facing use. They stated that no customer action was required based on their investigation. Independent researchers still recommended that anyone who pulled the versions during the window rotate the credentials that could have been exposed on that machine or in that CI job.

Why lockfiles on developer Macs matter

CI runners were an obvious target, but any laptop that ran npm install against a lockfile that resolved one of the bad versions, or that did a fresh install during the window, ended up with the payload in node_modules. The worm logic did not care whether it was running in a corporate runner or on a personal Mac.

Koban watches javascriptPackages by reading lockfiles and package metadata from the projects on each enrolled Mac. A new @redhat-cloud-services package (or one of the follow-on names) appearing in a diff shows up as a finding on the next heartbeat. You see the exact lockfile path and the resolved version without waiting for the next registry advisory or quarterly SBOM audit.

What we added to the defaults

Koban already ships a built-in rule that matches known malicious JavaScript package name patterns on the javascriptPackages surface. We expanded the list with indicators from this campaign and the immediate follow-on wave.

The rule uses triggers for added, modified, and present so it catches both fresh installs and packages that were already on disk when the rule was deployed.

If you rely on the shipped defaults, enrolled Macs will now surface these names at suspicious severity. You can still add tighter per-team rules on top.

Practical steps teams took

Teams that responded well did three things fast:

  • Searched lockfiles and node_modules for the affected package names and versions across both CI and developer machines.
  • Rotated any npm tokens, GitHub tokens, and cloud credentials that were present in environments that resolved the bad versions.
  • Turned on continuous inventory diff so the next similar event would not wait for someone to notice a strange package in a PR review.

Frozen lockfile installs and explicit pins limited the window for many projects. The worm still benefited from the fact that a single compromised account plus a trusted publish path reached a lot of downstream users quickly.

Further reading

The Miasma activity did not stop at the Red Hat scope. A fast follow-on wave a couple of days later used a different execution trick and hit additional maintainers. That is the subject of the next post.