Notifications
Clear all
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.
NHIMG editorial — based on content published by OXSecurity: compromised developer account "czirker" used to spread a new Shai-Hulud, Miasma, and Hades variant
By the numbers:
- the malware affected 23 packages
- 338 repositories in GitHub contained stolen credentials
Questions worth separating out
Q: What breaks when developer accounts can publish packages and expose credentials at the same time?
A: The main failure is that one identity becomes both a delivery channel and a secret reservoir.
Q: Why do stolen npm and GitHub tokens create a wider risk than a single compromised user account?
A: Because those tokens usually authenticate systems, pipelines, and repositories rather than one person.
Q: How do security teams know if software supply chain governance is working?
A: It is working when teams can identify which software and dependencies are deployed, match them to critical environments, and prove they can act quickly on vulnerability disclosures.
Practitioner guidance
- Restrict package-install execution paths Disable or alert on install-time scripts such as binding.gyp in build systems unless the package has been explicitly approved and tested in a controlled environment.
- Separate developer tokens from high-value cloud access Issue narrowly scoped GitHub, npm, and cloud tokens with clear purpose boundaries and short lifetimes.
- Scan repositories for exfiltration indicators Search for unusual marker strings, unexpected uploads, and credential-like artefacts in GitHub repositories, especially where package maintenance activity has recently changed.
What's in the full analysis
OXSecurity's full analysis covers the operational detail this post intentionally leaves for the source:
- The exact repository strings and decoded URLs used to trace the malware spread across GitHub.
- The package-by-package affected version list for the Leo and RStreams ecosystem.
- The public encryption keys and indicators of compromise used to distinguish this variant from earlier campaigns.
- The infection chain details showing how the compromised maintainer account propagated the payload.
👉 Read OXSecurity's analysis of the new Shai-Hulud, Miasma, and Hades npm variant →
Shai-Hulud npm malware variant: what IAM teams need to act on?
Explore further
02/08/2026 12:40 pm
Compromised developer identity is now a machine identity event. This incident is not just about a malicious package, it is about a maintainer account being used as a distribution point for non-human identity abuse. When package publishing credentials and cloud tokens sit in the same workflow, one compromise can expose many downstream identities. Practitioners should stop treating developer compromise and NHI compromise as separate disciplines.
A few things that frame the scale:
- From our research: When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- Our research on The State of Secrets in AppSec found that the average estimated time to remediate a leaked secret is 27 days.
A question worth separating out:
Q: Who is accountable when a stolen maintainer account pushes malicious packages?
A: Accountability sits with both the project maintainers and the organisation operating the publishing identity. Teams should define who owns package release rights, who can revoke them, and how quickly compromised publisher access can be removed. That governance belongs in access review and offboarding processes.
👉 Read our full editorial: Shai-Hulud npm malware variant exposes NHI governance gaps
