Shai-Hulud’s multi-stage npm malware keeps evolving on GitHub

At a glance

What this is: OXSecurity analyses a rapidly evolving Shai-Hulud npm malware campaign that now uses six stages and GitHub commits to sustain malicious delivery and evade simple detection.

Why it matters: It matters because developer trust paths, repository activity, and secret-handling controls now sit inside the attack surface, so IAM and supply-chain teams need visibility beyond static malware indicators.

Context

Shai-Hulud is an npm supply-chain malware campaign that uses repository trust, staged execution, and changing payload markers to keep operating after defenders react. In this case, the security gap is not just code execution on a developer workstation, but the abuse of GitHub as a command channel and persistence layer for malicious updates.

For identity and access teams, the important issue is how quickly a trusted developer platform can become operational infrastructure once tokens, repository access, and commit activity are abused. That shifts the problem from simple malware detection to governance of non-human credentials, repository trust, and software supply-chain control boundaries.

Key questions

Q: What breaks when npm supply-chain malware uses GitHub as a live command channel?

A: Static detection breaks first, because the malicious logic can move through new commits, new accounts, and new payload markers without changing the broad trust path. Network blocking is also weak when the traffic rides on a widely allowed developer platform. Teams need behavioural detection, not just destination filtering.

Q: Why do adaptive repository updates make staged malware harder to contain?

A: They extend the attacker’s reach beyond the initial infection. Once a repository can deliver fresh payloads, blocking one sample does not stop the campaign, because later commits can restore or change the malware after cleanup efforts have started.

Q: How should security teams investigate suspected Shai-Hulud activity?

A: They should correlate repository commits, package changes, CI secret exposure, and account turnover rather than hunting for one file hash alone. The goal is to identify the update path, the delivery path, and the credentials that let the malware keep re-entering.

Q: What should teams do when trusted developer infrastructure is being abused for malware delivery?

A: They should treat the platform as compromised trust infrastructure and rapidly revoke affected tokens, review write access, and isolate build workflows that can publish or modify code. The key is to cut the attacker’s ability to refresh payloads, not just to remove one infected package.

Technical breakdown

Why multi-stage droppers evade simple detection

Multi-stage malware breaks execution into small steps so each layer can hide the next. In this campaign, the sample uses six stages rather than the one to three stages more typical of npm malware, with obfuscation and encryption between each step. That matters because scanners built around a single signature, a single string, or a fixed unpacking sequence may only see the early loader and miss the later payload paths. The changing Miasma marker described in the article also means that detection logic tied to one exact string is brittle when the attacker can vary the payload. The architectural lesson is that staged malware is a control-evasion pattern, not just a packaging style.

Practical implication: detection needs stage-aware unpacking and payload correlation, not one-string repository checks.

How GitHub becomes an adaptive command channel

The article describes GitHub as more than a storage location for stolen output. In this campaign, commits tagged with the firedalazer string act as a live update mechanism, which lets the attacker refresh malware variants and keep the campaign alive even if one account is blocked. That turns a widely trusted developer service into an adaptive command-and-control layer. Network controls often struggle here because the traffic rides on a legitimate platform that many organisations already allow. For defenders, the important distinction is between ordinary source-code activity and malicious orchestration hidden inside repository commits and account churn. The security failure is trust without behavioural validation.

Practical implication: monitor commit patterns, account turnover, and repository behaviour, not only outbound destination lists.

Why repository trust and token abuse are now the control problem

Supply-chain malware like Shai-Hulud depends on developer trust paths that are usually treated as routine. Once a malicious actor can manipulate repositories, commits, or GitHub identities, the issue expands from malware cleanup to lifecycle control over non-human credentials and software delivery access. That is where IAM and NHI governance intersect with supply-chain security: access, delegation, and token scope become part of malware containment. If those identities are not tightly scoped, revoked, and observed, the attacker can re-enter through new accounts or new payload variants. The enduring risk is not a single infected package but a reusable trust path.

Practical implication: govern GitHub tokens and repository access as production identities with revocation, scoping, and review.

Threat narrative

Attacker objective: The attacker aims to keep a self-updating supply-chain infection alive long enough to steal data, evade simple detection, and maintain repeatable delivery through trusted developer infrastructure.

1. Entry occurs through a malicious npm package or related supply-chain path that delivers the staged loader onto a target system.
2. Credential or trust abuse follows when the malware uses GitHub commits and repository activity as a live control path for updated payloads.
3. Impact is sustained reinfection and campaign persistence, because new variants and account changes let the operation continue after blocking an individual source.

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

Adaptive repository control is now part of the malware problem. When attackers can turn GitHub commits into a living update channel, the boundary between code hosting and command-and-control collapses. That means defenders cannot treat trusted developer platforms as passive infrastructure any longer. The operational conclusion is that repository behaviour must be governed as an attack surface, not only as collaboration tooling.

Stage fragmentation is a detection-evasion strategy, not just complexity. A six-stage loader chain is designed to defeat assumptions that malware will unpack in a predictable order or expose one stable indicator. Signature logic built around a single string or a single payload marker will miss variant-driven infections. The practical lesson is that the control failure sits in over-reliance on static indicators, especially when code can loop back into new stages.

Shai-Hulud shows the trust path problem in supply-chain security. The campaign succeeds because token scope, repository access, and commit activity are all treated as normal developer operations until abuse is visible. That is where NHI governance matters: GitHub tokens, CI secrets, and machine access behave like identities with lifecycle obligations. Teams need to treat these trust paths as governed credentials, not background plumbing.

Secret exposure and code delivery are now linked failure modes. In campaigns like this, the same infrastructure that carries source code can also carry stolen material and payload updates. That creates a compound governance gap because exfiltration, persistence, and reinfection reinforce one another. The practitioner takeaway is to look at repository trust, secret handling, and token hygiene as one control plane rather than separate issues.

Miasma-style campaign behaviour is a useful named concept for this class of threat. It describes malware that keeps changing shape through repository-driven updates, making one-off detection and one-time cleanup insufficient. Once that behaviour exists, the right model is continuous observation of developer trust paths and rapid invalidation of compromised access. The field should treat this as an identity-backed supply-chain persistence pattern, not a temporary malware variant.

What this signals

Miasma-style supply-chain persistence is becoming the more important control problem. Once attackers can keep refreshing malware through repository commits, cleanup becomes a moving target rather than a one-time response. Security teams should expect package trust, commit trust, and token trust to fail together if they are not governed as one delivery path.

GitHub activity is only useful as a control plane when defenders can separate normal collaboration from malicious orchestration. That requires operational review of commit behaviour, token scope, and account changes across the software delivery path, not just blocklists or package hashes.

For practitioners

• Hunt for stage-specific markers across repositories Search for both the 3rd-stage and 6th-stage payload markers, including spacing differences in the Miasma string, because a single signature will miss variant infections.
• Revoke and re-scope GitHub tokens used in build and package workflows Treat GitHub tokens and CI secrets as production credentials, then narrow scope and rotate anything that can write to repositories or publish packages.
• Inspect repository commit behaviour for malicious update patterns Review unusual commit sequencing, rapid account changes, and repeated firedalazer-tagged updates as indicators of live command-channel use.
• Separate package trust from repository trust Validate packages independently of the hosting platform, and do not assume a trusted developer service is safe simply because the domain is allowed.
• Add alerting for supply-chain persistence signals Track reappearance of the same payload logic from new accounts or new repositories, because blocking one source does not stop the campaign.

Key takeaways

• Shai-Hulud shows how npm supply-chain malware can evolve into a multi-stage, repository-driven persistence pattern that defeats simple signature checks.
• The article’s evidence points to GitHub commits, changing payload markers, and repeated updates as the mechanisms that keep the campaign alive.
• The limiting control is not only malware removal but tighter governance over tokens, repository access, and developer-platform trust paths.

Key terms

• Supply Chain Malware: Malware delivered through trusted software distribution paths such as packages, dependencies, or build tooling. It succeeds by inheriting trust from legitimate workflows, which makes publication-time checks insufficient if the malicious behaviour appears only after install or in a later version.
• Command And Control Channel: A command and control channel is a communication path an attacker uses to send instructions to compromised systems and receive results back. In cloud and AI workloads, that path can be built through legitimate services such as storage, APIs, or object exchange rather than direct network sockets.
• Stage-Based Loader: A stage-based loader is malware that splits execution into multiple steps so each step can hide the next. This structure reduces detection visibility and lets the attacker change one stage without rewriting the entire campaign, which makes static signatures fragile.
• Metadata Trust Boundary: A metadata trust boundary is the line between tool content that can be safely consumed and tool content that must be validated before use. For agentic systems, descriptions, examples, and schemas are security-relevant inputs because they can influence decisions and trigger actions with real-world impact.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management through a practitioner-led curriculum. It helps security and IAM teams connect identity control to the broader attack paths that shape modern supply-chain risk.