Original reporting and technical analysis: Aikido Security. Additional analysis from Socket, OX Security, and Ars Technica.
Red Hat’s official @redhat-cloud-services npm namespace was compromised in a fresh software supply-chain incident involving a credential-stealing worm variant researchers are calling Miasma, closely related to the Mini Shai-Hulud tooling that has been moving through developer ecosystems this year.
The important lesson is not simply that a popular npm namespace was hit. The bigger issue is that the attack abused the machinery modern teams rely on to establish trust: GitHub Actions, OIDC-based npm trusted publishing, install-time package scripts, and developer/CI credentials that often have broad reach across repositories and cloud environments.
What happened
Aikido reported that multiple official Red Hat Cloud Services npm packages were compromised beginning June 1, 2026. Their analysis identified 96 affected versions across 32 packages, collectively downloaded roughly 117,000 times per week. Socket and OX Security independently tracked the same campaign and described a multi-stage payload designed to execute during package installation.
The compromised packages used an npm preinstall lifecycle script. That matters because the malware could execute during npm install before a developer ever imported the library or ran the application. In other words, the build dependency itself became the execution path.
Researchers reported that the payload searched broadly for sensitive material, including GitHub Actions secrets, npm and PyPI tokens, SSH keys, cloud credentials for AWS, Google Cloud, and Azure, Kubernetes configuration, Docker credentials, HashiCorp Vault tokens, GPG keys, and .env files. Several reports also noted propagation logic intended to use stolen access to publish additional malicious packages or inject code into reachable repositories.
Why this should worry SMBs and government contractors
For small businesses and government contractors, the risk is not limited to organizations that directly use Red Hat Cloud Services frontend packages. This incident is a warning about how quickly developer trust can become business exposure.
- Trusted publishing proves origin, not safety. If the release pipeline is compromised, a package can still appear to come from the right place while carrying malicious content.
- Developer workstations are privileged infrastructure. A laptop with repo access, cloud profiles, SSH keys, and package-manager credentials can become a launch point for broader compromise.
- CI/CD tokens are high-value targets. Short-lived OIDC tokens reduce some risks, but they do not protect a pipeline that has already been hijacked or tricked into minting tokens for the attacker.
- Install-time scripts are an execution boundary. Package lifecycle scripts can run before application security controls, code review, or runtime monitoring ever come into play.
This is especially relevant for organizations pursuing federal work because software supply-chain security is increasingly tied to contractual trust: SBOM quality, secure build practices, access control, incident response, and the ability to prove that artifacts were built from clean inputs.
Defensive takeaways
1. Treat install-time execution as risky by default
Review where your organization allows npm lifecycle scripts. For high-risk environments, consider disabling scripts during dependency installation where operationally possible, then selectively allowing trusted packages that truly require them. This is not always painless, but the default-open model is no longer defensible for sensitive build systems.
2. Separate developer convenience from production credentials
Developer machines should not hold broad, long-lived credentials for production cloud accounts, package publishing, or sensitive repositories. Use short-lived access, least privilege, device posture checks, and separate roles for development, release, and production operations.
3. Add egress visibility to CI/CD
Build runners should not have unrestricted outbound access. Monitor and restrict traffic from CI jobs to package registries, source control, artifact stores, and known cloud endpoints. Unexpected connections during dependency installation should be treated as suspicious.
4. Make credential rotation executable, not theoretical
When a dependency compromise lands, the hardest part is not reading the advisory — it is knowing exactly which systems installed the package, which credentials were present, what artifacts were built afterward, and how to rotate secrets without breaking the business. Keep an inventory of CI secrets, package publishing tokens, cloud roles, and developer SSH keys so rotation can happen fast.
5. Pair provenance with content inspection
Signatures, provenance, and trusted publishing are useful signals, but they do not replace malware scanning, package behavior analysis, secret scanning, and dependency-change review. A trusted pipeline can still produce an untrusted artifact if the pipeline itself is the thing that got compromised.
Bulwark Black assessment
Miasma is the kind of incident that should move software supply-chain defense from “developer tooling issue” to board-level operational risk. The attack path crosses identity, endpoint, CI/CD, source control, package management, and cloud access in one motion.
For SMBs and government contractors, the practical move is to assume that dependency installation is code execution and design controls around that reality. Harden developer endpoints. Minimize credential blast radius. Log CI/CD behavior. Inventory secrets. Rebuild artifacts after exposure. And do not let “official package” or “trusted publishing” become a substitute for verification.
Bottom line: the next supply-chain compromise may not look like an obviously malicious package. It may look like a normal dependency from a trusted namespace, delivered through a legitimate release workflow, with valid publishing metadata. Defense has to account for that.
