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.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “Red Hat npm Packages Compromised in Supply-Chain Attack Spreading Credential-Stealing Worm”.
Key questions
A: If build-time secrets are exposed, malware can steal registry tokens, GitHub credentials, and cloud access before any review or scanning step runs.
Q: Why do compromised packages in build systems create broader risk than a single developer machine?
A: Compromised packages matter more in build systems because they can reach CI/CD secrets, publishing tokens, cloud credentials, and trusted release paths.
Q: How do security teams know if provenance controls are actually working?
A: Look for two signals: packages are rejected when provenance is absent or mismatched, and release workflows only succeed from approved source commits and runners.
Practitioner guidance
- Restrict package lifecycle execution Disable or tightly control preinstall and other lifecycle hooks in build environments unless a package is explicitly approved for that behaviour.
- Rotate exposed non-human credentials immediately Treat every CI secret, cloud credential, SSH key, registry token, and environment file reachable from an infected install path as compromised.
- Review workflow publishing permissions Audit GitHub Actions token generation, repository workflow changes, and package publication rights as one control set.
Bottom line: The incident shows that package installation can become an identity event when build environments expose reusable credentials at install time.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 23 hours ago by NHI Mgmt Group
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
11/06/2026 12:41 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
12/06/2026 2:15 am
Build-time trust has become an identity governance problem, not just a software supply-chain problem. This incident shows that package installation can execute code with access to non-human identities already present in the environment. When secrets, tokens, and publish permissions are all reachable during install, the control boundary has failed before the application even starts. Practitioners need to treat dependency consumption, workflow execution, and credential exposure as a single governance domain.
A few things that frame the scale:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What breaks when supply-chain poisoning reaches developer workstations and CI runners?
A: The main failure is assuming a compromised package only affects one project. In practice, developer hosts and CI runners often hold cloud tokens, source access, and signing credentials, so a poisoned dependency can become a broader trust-breach across repositories and deployment paths. Once that happens, traditional package scanning is no longer enough on its own.
👉 Read our full editorial: Miasma supply-chain malware exposes NHI trust gaps in npm
This post was modified 23 hours ago by NHI Mgmt Group