Miasma Worm Poisons Red Hat npm Packages, Steals Cloud Credentials

What Happened?

Wiz Research flagged the compromise on June 1. The attacker got in through a Red Hat employee’s GitHub account, then pushed malicious orphan commits to two RedHatInsights repositories across two separate waves. Because the commits were orphaned, they skipped code review entirely.

From there, the attacker used GitHub Actions OIDC tokens to publish the tampered packages. That detail matters. The poisoned releases carried valid SLSA provenance attestations, so they looked formally verified to anyone running a standard check.

The payload itself is a reskinned version of the Mini Shai-Hulud worm, the same credential-stealing tool that the threat group TeamPCP open-sourced earlier this year. The attacker swapped out the original Dune references for Greek mythology themes and renamed it Miasma. Functionally, it does the same dirty work, plus a little more.

Each compromised package runs an obfuscated preinstall script the moment it gets installed. The script harvests GitHub Actions secrets, npm tokens, and developer credentials, then tries to republish itself through any package the victim account can access. That is how the worm spreads.

The new twist is cloud. This variant added collectors for Google Cloud and Azure that scoop up every identity an infected machine can reach. It also generates a uniquely encrypted payload for each infection, which makes detection and version tracking much harder.

The Impact

Anyone who ran npm install against these packages on June 1 may have exposed their GCP and Azure credentials, npm tokens, and CI/CD secrets. Because the malware republishes itself, one infected developer can seed the next round of compromised packages without knowing it.

The bigger problem is trust. SLSA attestations are supposed to prove a package is legitimate. Here, the attacker held a valid publishing identity, so the attestations validated tampered code. When the upstream account is compromised, provenance stops being a defense and becomes a way to make malware look clean.

Most malicious versions had been revoked within hours, but as of the initial report Red Hat had not shared a remediation timeline, and nobody has confirmed how the GitHub account was breached in the first place.

How to Avoid This

If you pulled any @redhat-cloud-services package on June 1, treat your environment as exposed. Rotate npm tokens, GitHub Actions secrets, and any GCP or Azure credentials those machines could touch.

Pin your dependencies to known-good versions and use a lockfile so a surprise publish cannot sneak in. Where you can, disable install scripts by default, since the whole attack fires from a preinstall hook.

Do not lean on provenance attestations alone. Pair them with anomalous publish detection that flags a package version no one expected. Build an SBOM for your projects so you actually know what you are shipping, and keep eyes on your build and developer environments for odd behavior.