Notifications
Clear all
Topic starter
09/06/2026 11:19 pm
TL;DR: A supply-chain worm compromised 32 @redhat-cloud-services npm packages, used a preinstall hook to steal cloud and developer credentials, and spread through GitHub Actions workflows with valid SLSA attestations, according to Orca Security. The incident shows that build-time trust, dependency provenance, and secret hygiene now need to be treated as one control surface, not separate problems.
NHIMG editorial — based on content published by Orca Security: Miasma supply-chain malware compromise affecting @redhat-cloud-services npm packages
By the numbers:
- A critical supply-chain attack has compromised 32 official npm packages under the @redhat-cloud-services scope.
- The attack occurred in two waves: 10:53 to 10:53:33 UTC and 13:44 to 13:46:47 UTC.
Questions worth separating out
Q: How should security teams handle a supply-chain malware event that runs during npm install?
A: They should treat the install path as an execution path and assume any secrets present in that environment may be exposed.
Q: Why do build pipelines create such a large NHI compromise risk?
A: Build pipelines often hold multiple high-value credentials in one place, including cloud keys, publishing tokens, SSH material, and CI secrets.
Q: What breaks when provenance attestation is treated as a complete trust signal?
A: Provenance can show where a package came from, but it does not guarantee the publishing identity was uncompromised at release time.
Practitioner guidance
- Isolate build-time secrets from package installation paths Run dependency installs in environments that do not contain cloud credentials, signing keys, or registry tokens.
- Review GitHub workflow identity and publishing rights Audit who can modify release workflows, who can mint OIDC-backed tokens, and which repositories can publish to package registries.
- Treat all exposed secrets as compromised until rotated Rotate CI secrets, cloud access keys, SSH material, registry tokens, and any signing-related credentials that were reachable from infected build or developer environments.
What's in the full article
Orca Security's full report covers the operational detail this post intentionally leaves for the source:
- The complete affected package list and compromised version ranges for each npm module
- The infection timeline across the two attack waves and how the malicious workflow changes were introduced
- The credential categories targeted by the preinstall payload, including cloud, registry, SSH, and signing secrets
- The asset-scanning and prioritisation details behind Orca's SCA detection and exposure analysis
👉 Read Orca Security's analysis of the Miasma npm supply-chain compromise →
Miasma npm compromise: what IAM teams need to review now?
Explore further
10/06/2026 1:36 am
Build pipelines have become non-human identity concentrations, not just software delivery systems. This incident worked because package publishing, workflow execution, cloud access, and secret storage were collocated inside the same trust zone. Once a single GitHub account or workflow identity is compromised, the attacker inherits a dense cluster of NHIs that were never meant to share a failure domain. The practitioner implication is that build systems must be governed as identity infrastructure, not only as DevOps tooling.
A few things that frame the scale:
- A critical supply-chain attack has compromised 32 official npm packages under the @redhat-cloud-services scope, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- Our research on the 2024 Non-Human Identity Security Report found that only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities.
A question worth separating out:
Q: Who should be accountable when compromised npm packages spread through CI and developer systems?
A: Accountability should sit with the teams that own workflow identity, dependency governance, and secret management together, because the failure spans all three. Security, platform engineering, and application owners need a shared response model for package poisoning, credential rotation, and publishing control. That shared ownership is what prevents a supply-chain issue from becoming an open-ended identity incident.
👉 Read our full editorial: Miasma supply-chain malware exposes NHI trust gaps in npm
