Red Hat npm Packages Hit by Miasma Credential-Stealing Worm

A Miasma supply-chain attack compromised @redhat-cloud-services npm packages with a credential-stealing worm. Developers should check lockfiles, CI runners, and rotate exposed secrets.

Red Hat npm packages under the @redhat-cloud-services namespace were compromised on June 1, 2026, after attackers used a compromised GitHub account to push unauthorized changes into Red Hat-maintained repositories and publish malicious package versions to npm. Red Hat’s own bulletin says the affected packages are frontend libraries used during product build processes, that compromised versions were removed from npm, and that its investigation was still ongoing at publication time.[1]

The campaign matters because the payload, called Miasma, was not a simple typo-squat or fake package. Researchers found it inside legitimate-looking releases from the official Red Hat Cloud Services scope. Aikido reported more than 30 affected packages, while BleepingComputer cited 32 packages and 96 package versions; examples include @redhat-cloud-services/frontend-components 7.7.2, patch-client 4.0.4, rbac-client 9.0.3, types 3.6.1, and vulnerabilities-client 2.1.8.[2][4]

Editorial cartoon showing the Miasma npm supply-chain worm being caught during a build pipeline check
The package looked official; the fog still wanted the keys.

The malicious packages used an npm preinstall hook, which means the payload could run during dependency installation before an application ever started. Aikido said the embedded index.js payload was roughly 4.2 MB and targeted GitHub Actions secrets, cloud credentials, HashiCorp Vault tokens, Kubernetes service tokens, npm and PyPI publishing tokens, SSH keys, Docker credentials, GPG keys, and .env files.[2]

OX Security’s analysis describes Miasma as a Shai-Hulud variant with heavier obfuscation and multi-stage loading logic. The researchers said it steals GitHub, npm, AWS, GCP, Azure, SSH, Kubernetes, wallet, and local environment data, then uses GitHub repositories as part of its exfiltration and propagation pattern.[3] That connects this incident to the broader developer supply-chain wave we recently covered in the Mini Shai-Hulud npm and PyPI compromise and the poisoned Nx Console extension attack.

What developers should check now

Red Hat’s public guidance is carefully scoped: based on current findings, it says no customer action is required and that Product Security is still checking whether any product builds contained compromised package versions.[1] That statement is important for Red Hat customers, but it does not remove the risk for developers or CI systems that installed the affected npm releases directly during the exposure window.

If your project uses @redhat-cloud-services packages, inspect package-lock.json, npm-shrinkwrap.json, pnpm/yarn lockfiles, CI build logs, container build history, and developer workstation install history for affected versions from June 1. Do not rely only on top-level dependencies: generated API clients and frontend component packages may arrive through transitive dependency paths.

Where there is a match, treat the affected machine or runner as exposed. Reinstall dependencies from clean, pinned versions, rotate GitHub, npm, cloud, SSH, registry, Kubernetes, Vault, and CI/CD tokens that were reachable from that environment, and look for unexpected public repositories or commits containing Miasma-related strings. The lesson is similar to the recent Laravel-Lang Composer package compromise: a trusted package name is not enough if install-time scripts can touch broad secrets.

About the author

Emma Davis

Content editor and security writer focused on making malware-removal and scam-prevention guides easier to understand. Emma reviews structure, clarity, and source consistency before articles are published.

Leave a Comment