Topic starter
02/08/2026 11:23 am
TL;DR: A new Shai-Hulud and Miasma malware variant spread through a compromised npm developer account, affecting 23 packages, 52,640 monthly downloads, and 338 GitHub repositories with stolen credentials, according to OXSecurity. The incident shows how developer accounts, tokens, and package-install execution paths can turn supply chain compromise into NHI exposure faster than conventional review cycles can respond.
Editorial analysis by NHI Mgmt Group, based on content published by OXSecurity: ““Alright Lets See If This Works”: Shai-Hulud / Miasma / Hades Variant Spreads on npm”.
By the numbers:
- Total affected packages were 23 in the Shai-Hulud / Miasma / Hades variant reported by OXSecurity.
- OXSecurity found 338 repositories in GitHub with stolen credentials during the spread of the malware variant.
Key questions
Q: What breaks when a trusted npm package can execute post-install code?
A: The boundary between dependency installation and code execution breaks down, which means a trusted package can inspect files, environment variables, and cached credentials during a normal install.
Q: Why do leaked developer tokens create such a large blast radius in supply chain attacks?
A: Developer tokens often bridge source control, package registries and cloud access, so one leaked credential can unlock several trust domains at once.
Q: How can security teams tell whether NHI secrets are being reused across repositories?
A: Look for the same token patterns, identical secret material, repeated infection strings and matching access artefacts across multiple repositories and CI logs.
Practitioner guidance
- Rotate exposed developer and CI secrets Revoke GitHub, npm and cloud credentials that may have been present in affected development or build environments, then reissue them under tighter scope and shorter lifetime.
- Audit package-install execution paths Review where package installation can execute code during build or local setup, and restrict that behaviour for untrusted or newly introduced dependencies.
- Separate publishing and runtime identities Use distinct identities for package publication, source control and cloud access so a compromise in one environment does not automatically unlock the others.
Bottom line: The incident shows how a compromised npm publishing account can become a credential-harvesting and distribution channel across development and cloud environments.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:40 pm
This is an NHI governance failure disguised as malware. The article is not only about malicious code in npm, but about the trust placed in developer accounts, tokens and install-time execution. Once those identities are used to publish or run code, the boundary between software supply chain security and machine identity governance disappears. Practitioners should treat package publishers, CI runners and cloud tokens as a single governed trust surface.
A few things that frame the scale:
- 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.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Should organisations separate package publishing identity from CI runtime identity?
A: Yes. Publishing, build execution and deployment should use distinct identities with narrow scopes, because a compromise in one should not automatically expose the others. Separation limits how far an attacker can move when a maintainer account, workflow file or CI secret is abused.
👉 Read our full editorial: Shai-Hulud npm malware variant exposes NHI governance gaps