Notifications
Clear all
Topic starter
02/08/2026 11:30 am
TL;DR: The Shai-Hulud npm malware behind the Red Hat compromise now uses six execution stages, GitHub commits as an adaptive command channel, and changing payload markers that can defeat simple signature checks, according to OXSecurity. The lesson for identity and security teams is that trusted developer platforms can become living delivery infrastructure when secrets, tokens, and repository trust are abused.
NHIMG editorial — based on content published by OXSecurity covering the Shai-Hulud npm malware campaign: The campaign that compromised Red Hat is still running, and it’s getting complicated
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility.
Questions worth separating out
Q: What breaks when supply chain malware can use trusted platforms as command channels?
A: Traditional network filtering and signature scanning lose much of their value because the malicious traffic looks like normal developer activity.
Q: Why do compromised tokens and API keys make npm supply chain attacks harder to contain?
A: Because a leaked token is not just a credential, it is a reusable non-human identity with its own privileges and lifetime.
Q: How can security teams tell if a repository is being used for malicious update activity?
A: Look for repeated commit patterns, unexpected payload changes, abnormal account behaviour, and package activity that does not match the team’s normal release process.
Practitioner guidance
- Hunt for stage-specific indicators in build and repo telemetry Search for multi-stage dropper markers, unusual commit strings, and repeated payload-loading patterns across package and repository logs.
- Treat exposed secrets as active non-human identities When an API key, token, or cloud credential is found in public code or logs, revoke it immediately and inspect where that identity was used.
- Monitor trusted developer platforms as security channels Log repository commits, account changes, and outbound fetches from GitHub and similar services, then correlate those events with package installs and runtime behaviour.
What's in the full article
OXSecurity's full analysis covers the operational detail this post intentionally leaves for the source:
- Stage-by-stage breakdown of the six-layer dropper logic and how each branch behaves in execution.
- Indicator lists for the Miasma and firedalazer markers used to track variant activity across GitHub.
- Repository-level behavioural clues that distinguish the 3rd stage and 6th stage payload paths.
- Malware artefacts and string patterns that can be fed into your detection and hunting workflows.
👉 Read OXSecurity's analysis of the ongoing Shai-Hulud npm malware campaign →
Shai-Hulud on GitHub: what this supply chain campaign means now?
Explore further
02/08/2026 12:45 pm
Multi-stage supply chain malware is now a control-plane problem, not just a malware problem. The article shows how Shai-Hulud uses layered execution to change behaviour without changing intent, which weakens signature-only defence. That pattern is relevant to IAM because the attack depends on stolen non-human identities, not just malicious code. Practitioners should treat package execution lineage, token use, and repository actions as one governance surface.
A question worth separating out:
Q: What should teams do after a secret is found in a public package?
A: They should contain the exposure by revoking or rotating the credential, tracing its downstream permissions, and reviewing every related repository, cloud account, and automation path. The correct response is lifecycle action on the identity, not just removal of the file that contained it.
👉 Read our full editorial: Shai-Hulud’s multi-stage npm malware keeps evolving on GitHub
