TL;DR: 96 compromised package versions across 32 @redhat-cloud-services npm packages were published through GitHub Actions OIDC, with 116,991 weekly downloads and payloads that stole CI secrets, cloud credentials, SSH keys, and npm tokens, according to Aikido. The pattern shows that trusted publishing can still fail when pipeline identity is compromised and standing secrets remain reachable.
NHIMG editorial — based on content published by Aikido covering the Red Hat npm package compromise: Red Hat npm Packages Compromised to Spread a Credential-Stealing Worm
By the numbers:
- 96 versions across 32 packages have been compromised, cumulatively downloaded 116,991 times per week.
Questions worth separating out
Q: What breaks when a CI pipeline can publish packages with the same trust as a maintainer account?
A: The organisation loses the separation between source code approval and release authority.
Q: Why do short-lived OIDC tokens still leave organisations exposed?
A: Short-lived tokens reduce static secret reuse, but they do not fix over-trusted workflows.
Q: What do security teams get wrong about package install scripts?
A: They treat install scripts as minor convenience features instead of execution points.
Practitioner guidance
- Separate publish identity from build identity Use distinct credentials, repositories, and approval gates for code build, package signing, and package publication so a compromised workflow cannot directly publish to registries.
- Block install-time execution in trusted build paths Disable or tightly review package lifecycle scripts such as preinstall in CI and golden image pipelines, especially for packages that have not been explicitly approved.
- Inventory machine credentials reachable from CI jobs Map every secret exposed to build runners, including cloud keys, registry tokens, SSH keys, and service account tokens, then reduce each job to the minimum set required.
What's in the full analysis
Aikido's full blog covers the operational detail this post intentionally leaves for the source:
- The full list of compromised package names and affected versions for incident response and inventory work.
- The malware execution path inside the workflow and package payload for teams validating detections.
- The indicators of compromise and rotation guidance for CI secrets, cloud credentials, SSH keys, and npm tokens.
- The Aikido detection workflow and rescan process for teams using its package monitoring feed.
👉 Read Aikido's analysis of the Red Hat npm package compromise and credential-stealing worm →
npm supply chain compromise in CI/CD: what security teams should do?
Explore further
Pipeline identity is now part of NHI governance. The compromise shows that publish automation, repository access, and package release permissions function as non-human identities with real blast radius. When those identities are not lifecycle-managed, the organisation inherits a hidden control plane for software distribution. Practitioners should stop treating CI/CD permissions as engineering convenience and govern them as privileged machine access.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- Only 23.5% of security professionals are unsure about the biggest threat to their non-human identities, indicating a significant awareness gap, according to The 2024 Non-Human Identity Security Report.
A question worth separating out:
Q: How should teams respond when CI or developer secrets are exposed?
A: Teams should identify the affected identities, revoke or rotate exposed credentials, review ownership and scope, and verify whether the compromised material reached any production-adjacent systems. The operational challenge is to close exposure quickly without breaking dependent services.
👉 Read our full editorial: Red Hat npm package compromise shows CI secrets remain exposed