Miasma: @redhat-cloud-services npm Attack
32 legitimate Red Hat npm packages turned into credential-stealing weapons. Valid SLSA attestations. Bypassed code review. 80,000+ weekly downloads.
What happened?
On June 1, 2026, attackers compromised a Red Hat employee's GitHub account and used it to inject credential-stealing malware into 32 packages under the @redhat-cloud-services npm scope. The attack, dubbed "Miasma," weaponized packages downloaded approximately 80,000 times per week.
The attack came in two waves—10:53 AM and again between 1:44-1:46 PM UTC. Malicious orphan commits bypassed code review entirely. Worse: the attacker used GitHub Actions OIDC tokens to publish packages with valid SLSA provenance attestations, making poisoned releases appear formally verified.
What data was actually inside?
The malware targeted everything a developer or CI/CD system would have access to: GitHub tokens, SSH keys, npm publish tokens, and cloud credentials. New data collectors specifically harvested GCP and Azure identities—the keys to cloud kingdoms.
The attack also established persistence by injecting hooks into AI developer tools including Claude Code, VS Code, Copilot, and others. A destructive component watched stolen GitHub tokens—if a token was revoked before persistence was removed, it could execute destructive commands including wiping the user's home directory.
Who gets hurt and how?
Every developer and CI/CD pipeline that installed an affected package version. At reporting time, 309 GitHub repositories had been compromised by the spreading malware. Each infected machine becomes a launchpad for further compromise—stolen cloud credentials enable lateral movement into production infrastructure.
The remediation guidance is brutal: treat all CI secrets, cloud credentials, SSH keys, and npm tokens as compromised. Uninstalling the package isn't enough—the malware establishes persistent monitoring services on Linux and macOS. Incident responders must isolate machines and remove persistence before revoking any tokens, or risk triggering the destructive payload.
What did they think they were doing right?
Using official @redhat-cloud-services packages from npm. Trusting SLSA provenance attestations that cryptographically verified package origin. Following the supply chain security guidance that said "verify your dependencies."
But when an attacker compromises a maintainer account and uses legitimate CI/CD infrastructure to publish, the attestations verify the wrong thing. They prove the package came from the expected pipeline—not that the pipeline inputs were clean.
What did they not know about their own data?
Developers don't inventory what credentials their machines hold. CI/CD systems accumulate secrets over time: GitHub tokens for multiple repos, cloud credentials for various environments, SSH keys to production servers. When malware runs during npm install, it harvests everything the host has access to.
The attack exploited this blind spot. A single compromised developer machine—or CI runner—might hold credentials to dozens of systems. Without knowing what secrets exist where, there's no way to scope the blast radius when one gets popped.
If a single credential in your environment was compromised today, could you say within 24 hours exactly what data was accessed?
What does attribution look like the morning after?
The payload derives from the Mini Shai-Hulud malware that TeamPCP open-sourced on May 12, 2026, specifically to enable copycats. Dune references were swapped for Greek mythology themes. Whether TeamPCP ran this campaign or inspired it doesn't matter much for the victims—the credential theft is identical.
Red Hat immediately removed affected packages and stated the compromise was limited to internal development tooling. But the ripple effects spread through every organization that pulled those packages into their own systems—a supply chain attack by definition.
What would have changed the outcome?
Knowing what credentials exist on developer machines and CI runners—before an attacker does the inventory for you.
When malware runs during package install, it harvests whatever the host can access. The question isn't whether supply chain attacks will happen—they will. The question is whether you know what's at risk when one hits your environment. Cloud credentials, SSH keys, tokens to production systems—if you can't enumerate them, you can't rotate them, and you can't scope the damage when they're stolen.
Your Development Environment found out the hard way.
Your team could spend the next 6 months rebuilding systems, notifying customers, and answering legal questions. Or you could spend 24 hours finding out what's actually at risk.