Topic starter
02/08/2026 11:29 am
TL;DR: Secret exposure, not package appearance, drove the Miasma npm wave that infected 57 packages and reached more than 118 GitHub repositories, according to OXSecurity. Build-time installs can turn dependency processing into a credential-harvesting path unless secrets and tokens are isolated.
Editorial analysis by NHI Mgmt Group, based on content published by OXSecurity: “600,000 Monthly Downloads Affected: Miasma Supply Chain Attack Is Back on npm”.
By the numbers:
- The Miasma wave affected 57 packages and over 118 GitHub repositories.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: The Miasma npm wave shows that secret exposure, not package appearance, is the decisive failure mode when third-party code can execute during installation.
Glossary terms: Build-Time Code Execution, Dependency Supply Chain, Credential Blast Radius
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
02/08/2026 12:45 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Miasma’s npm supply chain attack exposes secret governance gaps