Attackers compromised Red Hat’s official @redhat-cloud-services npm namespace and published 96 malicious versions across 32 packages, embedding a credential-stealing worm that security researchers at Aikido, OX Security, ReversingLabs, and Socket independently discovered and reported.
Scope of the Red Hat npm Compromise
The affected packages collectively received approximately 80,000 downloads per week before the malicious versions were identified and removed. Because these were official packages in a trusted namespace — not typosquats or impersonators — developers and automated pipelines had no routine reason to distrust them. Red Hat has since pushed clean replacement versions to the registry, but every environment that installed an affected version during the exposure window must be treated as compromised.
Researchers assess the threat group TeamPCP is likely behind the attack, based on overlapping tactics and infrastructure patterns. The group is associated with sophisticated software supply chain intrusions targeting developer toolchains.
Miasma: A Shai-Hulud Variant Built for CI/CD Environments
The malware embedded in the backdoored packages is Miasma — full name “Miasma: The Spreading Blight” — a variant of the Shai-Hulud malware family. Miasma is purpose-built to operate silently within developer environments and automated build systems, where the breadth of available secrets vastly exceeds what a typical end-user machine holds.
Miasma executes through a preinstall hook, which runs automatically when a developer or pipeline installs the package — before any human has the opportunity to inspect what the package does. At the moment of installation, the worm begins silently harvesting credentials from the host environment. Its target list includes AWS, Azure, and GCP access keys; Kubernetes service account tokens; HashiCorp Vault tokens; npm and PyPI publishing tokens; SSH private keys; Docker credentials; and .env files. Together, these represent nearly every class of secret that an active CI/CD pipeline would hold.
Lateral Propagation Through Cached Packages
What distinguishes Miasma from a standard malicious package is its worm component. After executing on initial installation, Miasma is capable of spreading laterally through locally cached packages in developer environments. A single developer machine where one backdoored package was installed can become a propagation point, extending the malware’s reach to other packages cached locally and across shared developer machines on the same network or file system.
This lateral propagation means the blast radius of the attack is not bounded by the 32 directly compromised packages. Any environment where one affected package was installed should be evaluated for secondary spread.
Responding to the Miasma Exposure
For organizations that installed any of the 32 compromised @redhat-cloud-services packages, response must address both the malware itself and any credentials or access tokens it may have exfiltrated. The necessary steps span credential rotation, persistence checks, and audit log review across every cloud environment that shared a dependency on the affected packages.
Rotating @redhat-cloud-services Credentials After Miasma Exposure
Organizations should assume that any environment — developer workstation, CI/CD runner, build container, or deployment pipeline — that installed any version of a compromised @redhat-cloud-services package during the attack window had its credentials exfiltrated. The appropriate response is immediate, comprehensive rotation: all CI/CD secrets, all cloud access keys for AWS, Azure, and GCP, all Kubernetes service account tokens, all HashiCorp Vault tokens, npm and PyPI publishing tokens, all SSH keys, and all Docker credentials that were present in those environments.
Rotation alone is not sufficient if the attacker has already used stolen credentials to establish persistence elsewhere in the cloud infrastructure. Audit logs for all cloud accounts and service accounts that existed in exposed environments should be reviewed for unauthorized access, token generation, or privilege escalation activity that may have occurred during the exposure window.
Why Supply Chain Attacks Against Trusted Namespaces Are Particularly Dangerous
Typosquatting attacks — where attackers publish packages with names similar to legitimate ones — are a known risk that organizations increasingly screen for. Compromising an official, verified namespace like @redhat-cloud-services bypasses that defensive layer entirely. Package managers, security scanners, and developer trust models do not flag packages that appear to be exactly what they claim to be. The attack surface in this case was not a misspelling; it was the legitimate package itself.
The preinstall hook execution vector compounds the problem. Security-conscious developers who review package code before use are not protected, because the malware runs during the install step — before any manual inspection is possible in a standard workflow. Build pipelines with no human review step between dependency resolution and execution have no opportunity to catch the malware at all.
