Miasma supply-chain malware exposes NHI trust gaps in npm

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Orca Security's research: Supply-chain malware in npm involved compromised packages executing a credential-stealing worm during install and using trusted build paths to widen impact.

Why it matters: It matters because CI/CD, developer endpoints, and machine credentials are being exploited through the same dependency and build controls that identity teams often treat separately.

Context

A supply-chain compromise becomes an identity problem when package installation can execute code before application controls or human review intervene. In this case, the primary governance gap is not simply malicious code in a registry, but the trust placed in build-time execution, repository workflows, and the credentials available to them.

For NHI and IAM teams, the important issue is that installation paths often have access to cloud tokens, publish tokens, SSH keys, and CI secrets by design. Once a package can run at install time, those credentials become part of the attack surface rather than separate assets under distinct control planes.

Key questions

Q: What breaks when CI pipelines allow secrets and tokens to remain reachable during package installation?

A: If build-time secrets are exposed, malware can steal registry tokens, GitHub credentials, and cloud access before any review or scanning step runs. The failure is not just exfiltration, but automatic propagation, because stolen credentials can be used to publish new malicious versions or alter repositories. Segmentation, least privilege, and secret isolation are essential to limit blast radius.

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. Once malware executes there, it can steal short-lived tokens, abuse OIDC-backed publishing, and propagate into new releases. That turns one infected install into a supply chain foothold, expanding risk from a single endpoint to every downstream consumer of the package.

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. If teams can publish or install high-risk dependencies without verification, provenance exists only as metadata and not as an enforceable control.

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.

Technical breakdown

Preinstall hooks turn package install into code execution

npm lifecycle hooks allow package authors to run scripts during installation, before the application fully exists in runtime. That matters because the preinstall phase executes with the privileges of the build or developer environment, not the application itself. In this incident, the malicious payload ran automatically during install, which means normal dependency consumption became the entry point for credential access. This is a supply-chain pattern, but the identity dimension is the most important part: the package inherited whatever secrets and tokens were already present in the environment. When installation can execute arbitrary code, dependency trust and runtime trust collapse into the same event.

Practical implication: Treat package install as an execution boundary and block lifecycle hooks where your build process does not explicitly require them.

GitHub Actions OIDC and provenance can be abused together

The attackers used compromised GitHub access to inject workflows that published backdoored package versions with valid SLSA provenance attestations. That combination matters because provenance is only meaningful when the signing path and workflow integrity are trusted end to end. GitHub Actions OIDC tokens can provide legitimate publishing authority, but if workflow definitions are compromised, the token becomes a vehicle for authorised abuse rather than a proof of safety. The issue is not that OIDC or SLSA failed as concepts. The issue is that they can certify a malicious action when the workflow itself is the compromised control plane. Provenance, therefore, must be evaluated alongside workflow governance, not separately.

Practical implication: Review workflow permissions, token issuance paths, and publishing approvals as a single control surface before trusting provenance signals.

Credential sweep logic makes the build environment the prize

The malware harvested a wide range of credentials, including cloud access keys, service account tokens, npm and PyPI tokens, SSH keys, registry credentials, and .env files. That breadth is what makes build systems such attractive targets: they aggregate non-human identities and developer secrets in one place, often with enough privilege to publish, deploy, or pivot. A credential-stealing worm does not need to understand the target application if it can enumerate what the environment already exposes. The technical failure is not only leakage, but overexposure through ambient trust. Once a build runner or developer workstation is compromised, the attacker inherits the relationships between tools, tokens, and downstream automation.

Practical implication: Inventory which secrets exist in build and developer environments, then remove every credential that is not strictly required for that execution path.

Threat narrative

Attacker objective: The attacker’s objective was to steal reusable credentials at scale and use them to expand compromise across repositories, cloud environments, and software supply chains.

1. Entry occurred through compromise of a Red Hat employee GitHub account, which gave the attacker a trusted path into repository workflows.
2. The attacker used injected GitHub Actions workflows and OIDC-based publishing to place malicious npm package versions into the distribution chain with valid provenance.
3. During npm install, the preinstall hook executed an obfuscated payload that stole cloud, CI/CD, registry, SSH, and developer credentials from the environment.
4. Stolen tokens and credentials could then be reused to compromise additional repositories and packages, creating a self-propagating supply-chain expansion path.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Valid provenance can still accompany malicious change when the publishing workflow is the compromised asset. SLSA attestations do not protect an organisation if the workflow that generates them has been subverted through GitHub identity compromise. That is why provenance cannot be assessed in isolation from repository governance, token scope, and workflow change control. The practitioner conclusion is simple: trust signals are only as good as the identity controls behind them.

Ephemeral build trust debt: the environment assumes install-time access is temporary, but stolen credentials make it persistent. The control assumption here is that credentials available during CI or developer work are scoped tightly enough to disappear with the job. That assumption fails when a worm can exfiltrate reusable tokens and keys before the first build finishes. The implication is that issuance-time controls matter more than post-event review when install-time execution is itself the attack path.

Secret concentration inside build systems creates an identity blast radius that most programmes still underestimate. The article shows how a single compromised package can reach cloud credentials, registry tokens, SSH keys, and service account material in one pass. That makes build runners and developer workstations the densest non-human identity zones in many organisations. Practitioners should map where those secrets co-locate and reduce the number of places where one infection can become many compromises.

OWASP-NHI and supply-chain controls now overlap operationally, even when teams still own them separately. This incident sits at the intersection of secret leakage, overprivileged NHI use, and third-party package trust. OWASP-NHI, MITRE ATT&CK, and SLSA all describe parts of the problem, but the operational reality is unified: one compromised install path can expose multiple identity classes at once. Security teams need a cross-domain control model because attackers already operate across those seams.

From our research library:

• 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.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Ephemeral credential trust debt: Build pipelines still assume that secrets exposed during installation are too transient to matter, yet this incident shows how quickly install-time execution can turn that assumption into a breach path. Once a package can run before application logic, the only safe question is which credentials were reachable at that moment.

For practitioners, the important shift is to manage dependency trust as part of identity governance rather than as a separate software hygiene task. That means tightening package execution rights, reducing secret residency in build environments, and treating workflow identity as production-grade access.

GitHub Actions, artifact provenance, and package publishing now need joint review because attackers can abuse legitimate automation to generate apparently valid release evidence. The operational signal to watch is not just malicious code in a registry, but any place where a trusted automation path can mint authority for untrusted change.

For practitioners

• 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. Where hooks are unavoidable, run them in isolated sandboxes with no access to cloud tokens, publish tokens, or developer credentials.
• 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. Rotate them in priority order by privilege and reissue only after confirming the affected pipelines are clean.
• Review workflow publishing permissions Audit GitHub Actions token generation, repository workflow changes, and package publication rights as one control set. Separate who can change workflows from who can publish artifacts, and remove standing write access wherever it is not required.
• Pin and verify dependency provenance Block unapproved package versions, pin known-good releases, and verify SBOM and provenance evidence before installation or deployment. Make the allowlist a deployment gate so compromised transitive dependencies cannot enter production through routine updates.

Key takeaways

• The incident shows that package installation can become an identity event when build environments expose reusable credentials at install time.
• A single compromised repository workflow can turn legitimate provenance into a delivery mechanism for malicious package versions.
• Containment depends on isolating install-time execution, rotating exposed secrets, and reducing the number of credentials available to build systems.

Key terms

• Preinstall Hook: A preinstall hook is package code that runs before an application installs or starts. In supply-chain attacks, it becomes a hidden execution point that can steal secrets, alter environments, or drop further payloads before normal controls see the package's behaviour.
• Provenance Attestation: A provenance attestation is evidence that software was produced through a known pipeline or workflow. It helps verify origin, but it does not guarantee that the workflow was free of compromise, poisoned caches, or attacker-controlled inputs.
• Build Secret Exposure: The loss of credentials, tokens, or API keys during software build or delivery activity. These secrets often sit in automation with broad scope, so a compromise in one workflow can produce access far beyond the original system that was attacked.
• Supply Chain Worm: A supply chain worm is malware that uses one compromise to propagate into adjacent packages, repositories, or automation systems. In identity terms, it becomes far more dangerous when it can harvest and replay secrets that let it publish, move, or persist without further exploitation.

Deepen your knowledge

NHI governance, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.