On 1 June 2026, Aikido and OX Security reported that packages in the @redhat-cloud-services npm namespace had been backdoored with a credential-stealing worm called Miasma, a variant of Shai-Hulud. BleepingComputer, citing Aikido, put the damage at 32 packages and 96 versions, with roughly 117,000 weekly downloads. Red Hat removed the packages from the registry.
What's affected
- Namespace:
@redhat-cloud-serviceson npm, described as numerous client libraries. The reports we read do not list individual package versions, so check your lockfiles against Red Hat's and Aikido's published lists. - Delivery: a
preinstallscript that runsnode index.js, a heavily obfuscated file of about 4.2 MB. - Targets, per Aikido: GitHub Actions secrets, AWS, Google Cloud and Azure credentials, HashiCorp Vault and Kubernetes tokens, npm and PyPI publishing tokens, SSH keys, Docker credentials, GPG keys and
.envfiles. This is embedded malicious code, the pattern behind CWE-506. - Red Hat's statement: "we have not identified any impact to customer or partner environments or Red Hat production systems." Red Hat did not say how the account was compromised.
BleepingComputer reports that attackers allegedly took over a Red Hat employee's GitHub account, pushed commits that added a GitHub Actions workflow and a script, and used that workflow to request a short-lived OIDC token from npm's trusted publishing. They then published backdoored versions of every package listed. Whether TeamPCP or another actor ran the campaign was unclear at the time.
What to do now
- Search lockfiles and caches for the namespace:
grep -rn "@redhat-cloud-services" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null
npm ls --all 2>/dev/null | grep "@redhat-cloud-services"
- If any version was installed on or after 1 June 2026, treat that machine or runner as exposed. Aikido's advice is to rotate every credential, secret and token that code on the device could reach.
- Remove the packages from lockfiles, internal mirrors and build caches before you rotate, so a rebuild does not pull them back.
- Review recent workflow files and publishes in repositories those credentials could write to.
How this could have been avoided
- Protect the workflow directory. Require code owner review for changes under
.github/workflowsso one pushed commit cannot add a publishing workflow. - Scope trusted publishing tightly. Pin the npm trusted publisher to one named workflow file and a protected environment that needs a human approval, so a new workflow cannot mint a publish token.
- Lock down employee accounts. Phishing-resistant MFA and short session lifetimes on the GitHub accounts that can push to release repositories.
- Delay new versions on the consumer side. A dependency cooldown of a few days would have kept a same-day malicious release out of most builds.
- Install without secrets. The payload ran in
preinstall, so installing in a step that has no cloud or publishing credentials limits what it can read.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why did a valid trusted-publishing token not prove the release was safe?
Because the token proves which workflow ran, not that the workflow was legitimate. Per the reports, the attacker added the workflow to the repositories first.
