Miasma’s npm supply chain attack exposes secret governance gaps

At a glance

What this is: This is a supply chain incident analysis showing how the Miasma npm wave used build-time execution to steal GitHub, npm, and cloud credentials across dozens of packages.

Why it matters: It matters because dependency controls that inspect package contents without governing installation-time access leave secret exposure and token theft paths open in CI and developer workflows.

By the numbers:

• The Miasma wave affected 57 packages and over 118 GitHub repositories.

Context

The core security gap here is not package installation itself but the trust boundary around build-time execution. npm ecosystems often assume package review, lockfiles, and provenance checks are enough, yet malware that runs during install can still reach tokens, cloud credentials, and local environment data before defenders see a malicious binary or obvious script.

That makes this a supply chain and identity problem at the same time. GitHub tokens, npm tokens, and cloud credentials are non-human identities or identity-bound secrets, so once build systems expose them to untrusted dependency code, the compromise moves from software integrity into credential governance and blast-radius control.

This pattern is increasingly typical of modern package compromise, where attackers adapt faster than package inspection workflows. The article’s affected package list and repository spread show how quickly one malicious dependency can turn developer and CI access into a wider secret-exfiltration event.

Key questions

Q: What breaks when malicious npm packages execute during CI/CD installs?

A: The main failure is that package installation becomes code execution inside a trusted build context. That lets attacker-controlled scripts read memory, steal secrets, and potentially publish more malicious artifacts before defenders notice. The control that breaks is the assumption that dependency installation is operationally harmless. Treat install-time execution as a governed security boundary, not a routine developer convenience.

Q: Why do stolen GitHub, npm and cloud tokens increase supply chain blast radius so quickly?

A: Because those tokens are reusable machine identities with direct access to repositories, build systems and secret stores. Once stolen, they can be used to publish malicious updates, read protected resources and move the compromise into adjacent workflows without human interaction.

Q: What are the signs that dependency install controls are failing?

A: Warning signs include unexpected native build hooks, secrets present in CI environments, and repeated outbound access from package installation jobs. If dependency processing can still touch credentials or write into shared build workspaces, the control is failing because the environment is granting more trust than the package deserves.

Q: How should teams respond when a supply chain worm spreads through trusted packages?

A: Contain the publishing surface first. Revoke exposed tokens, rotate credentials, review repository creation and workflow changes, and roll back to known-clean package versions. Then scope the blast radius across developer environments, CI/CD systems, and any cloud accounts that shared the same secrets.

Technical breakdown

Why binding.gyp changes the install-time attack surface

binding.gyp is a native build configuration file used by Node.js packages to compile code during installation. In this case it substitutes for postinstall-style execution, which matters because many defenders focus on obvious lifecycle scripts while missing other legitimate-looking build hooks. The result is the same: untrusted package code executes inside a developer or CI environment with access to secrets, environment variables, and network reach. The security mistake is treating script type as the control boundary instead of treating package execution as the boundary.

Practical implication: control build-time execution paths, not just lifecycle script names.

How secret theft happens in npm supply chain compromise

Supply chain malware rarely needs to break authentication if it can read authenticated material from the runtime context. In this case, GitHub tokens, npm tokens, and cloud credentials were available to the environment that installed the package, which means the package became a collection point for identity material already trusted by downstream systems. That is a classic NHI governance failure: service credentials were present where third-party code could reach them, and the installation boundary had no meaningful secret isolation.

Practical implication: keep CI secrets out of dependency installation contexts.

Why package review does not equal credential safety

Package review is a content control, but credential theft is a runtime control problem. A clean-looking dependency can still execute during installation, harvest tokens, and then leave little visible evidence in the package contents themselves. That gap is why supply chain attackers favour installer-time execution and why security teams need runtime guardrails, secret scoping, and repo-level detection rather than relying on manual package inspection alone.

Practical implication: add runtime secret controls to dependency ingestion workflows.

Threat narrative

Attacker objective: The objective was to turn package installation into a credential-harvesting channel that exposes developer and cloud access for broader supply chain compromise.

1. Entry occurred through compromised npm packages that executed during installation via binding.gyp rather than relying only on postinstall scripts.
2. Credential harvesting followed as the malware collected GitHub tokens, npm tokens, AWS credentials, GCP credentials, Azure credentials, and local environment information.
3. Impact came from stolen credentials and over 118 infected repositories, giving attackers a wider foothold across developer and CI environments.

Breaches seen in the wild

• Shai-Hulud npm worm first wave 2025: The first Shai-Hulud wave used stolen npm tokens to trojanise 500+ packages, starting with tinycolor, and leaked developer and CI secrets on GitHub.
• Bitwarden CLI npm compromise 2026: A malicious Bitwarden CLI on npm, linked to the Checkmarx campaign, targeted GitHub, npm, cloud and CI secrets from developers for 90 minutes.

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 execution has become the real trust boundary in npm supply chains. Defenders often focus on package contents, signatures, and obvious lifecycle hooks, but the article shows attackers can shift execution into other install-time mechanisms. That means the control failure is not just weak package vetting, but an incomplete model of where untrusted code is allowed to run. Practitioners need to treat dependency installation as an execution event, not a static file review exercise.

Secret governance, not package hygiene alone, determines the blast radius of dependency compromise. The compromised environment exposed GitHub tokens, npm tokens, and cloud credentials, which turns a supply chain issue into an identity governance issue. Those secrets are non-human identities in practice, and they should not be broadly reachable from third-party package execution contexts. This is the same failure mode seen whenever token scope outruns runtime isolation: compromise of one install path becomes compromise of the surrounding estate.

Package review controls are necessary but structurally insufficient against adaptive malware. The article shows the threat actor reused known tradecraft and changed execution paths to bypass inspection patterns that defenders were already watching. That is why static review, manual approval, and narrow script blocking can reduce noise without closing the root gap. The decisive variable is whether the build environment can prevent secret exposure even when untrusted code executes.

Credential blast-radius control is now the dominant supply chain design requirement. The practical question is not whether a package is trusted enough to install, but whether the installation context can survive compromise without exposing high-value tokens. That shifts governance toward ephemeral credentials, tighter environment partitioning, and stronger detection around install-time access. In identity terms, the exposure window must be smaller than the malware’s execution window.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
• Read next: AI Supply Chain Security and AI-BOM Guide

What this signals

Secret blast radius is now the control variable that matters most in supply chain incidents. If build systems can still expose reusable GitHub, npm, or cloud credentials, then package trust becomes secondary to token scope and environment isolation. Practitioners should design for compromise containment rather than rely on package inspection alone.

Supply chain security programmes need to assume attacker adaptation, not script-pattern stability. Once defenders tighten one execution path, malicious packages will shift to another install-time mechanism, so detection and containment must follow the execution context, not a named hook.

The most useful operating model is to keep dependency installation away from high-value identity material and treat every package build as a potentially hostile session. That is the practical bridge between software supply chain security and NHI governance.

For practitioners

• Restrict secrets in dependency-install environments Remove GitHub, npm, and cloud credentials from contexts that resolve or build third-party packages, especially CI runners and ephemeral developer shells.
• Separate build identity from deployment identity Use distinct, tightly scoped credentials for package installation, artifact creation, and cloud deployment so a compromised installer cannot reach production access.
• Monitor for unexpected install-time execution Alert on native build hooks, unusual package scripts, and repository patterns that indicate code executed during installation rather than at runtime.
• Rotate exposed tokens immediately after package compromise Assume any secret available to affected build systems may have been harvested, then revoke and reissue tokens with a narrower scope.
• Harden third-party dependency intake Quarantine new package versions, require provenance checks where available, and test in isolated environments that do not inherit broad environment variables.

Key takeaways

• The Miasma npm wave shows that secret exposure, not package appearance, is the decisive failure mode when third-party code can execute during installation.
• The article reports 57 affected packages and more than 118 repositories, which demonstrates how quickly one malicious dependency can spread credential risk across developer workflows.
• Isolation of build-time credentials and stricter token scoping would have limited the impact more effectively than package review alone.

Key terms

• Build-Time Code Execution: Build-time code execution occurs when a package install or build process runs commands before the software is fully installed. This is risky because dependency fetches, lifecycle scripts, and helper tools can execute with developer or root privileges. It turns ordinary package management into a potential host compromise path.
• Dependency Supply Chain: The dependency supply chain is the path packages follow from publication to installation in code, CI, or developer environments. It includes registries, mirrors, package managers, and endpoint configuration, all of which can become trust failures if they are not governed end to end.
• Credential Blast Radius: Credential blast radius is the amount of access, data, and system reach that a single compromised secret can unlock. The wider the blast radius, the more damage one leaked token or certificate can cause. Reducing it requires tighter scope, faster revocation, and better segmentation.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.