Shai-Hulud V2 Poses Risk to NPM Supply Chain | ThreatLabz

On November 24, 2025, security researchers detected a second wave of the Shai-Hulud malware campaign targeting the npm ecosystem. Dubbed The Second Coming by its operators, Shai-Hulud V2 builds upon its predecessor, Shai-Hulud V1 , and has established itself as an aggressive software supply chain attack. Within hours of its initial detection, the campaign had compromised over 700 npm packages, created more than 27,000 malicious GitHub repositories, and exposed approximately 14,000 secrets across 487 organizations.

Compared to V1, which relied on less sophisticated tactics, Shai-Hulud V2 introduces critical advancements such as pre-install phase execution for greater impact, persistent backdoor access via self-hosted GitHub Actions runners, cross-victim credential recycling to create a botnet-like network, and a dead man's switch designed to delete user data if containment is detected.

In this blog post, Zscaler ThreatLabz provides actionable guidance for detection and remediation, a detailed comparison of Shai-Hulud V1 and V2, and a technical breakdown of how the attack operates.

The Shai-Hulud V2 campaign has temporarily compromised the following notable packages:

Table 1: List of notable compromised packages.

Shai-Hulud V2 demonstrates significant tactical evolution, suggesting threat actors learned from Shai-Hulud V1's limitations. The table below compares V1 and V2 of Shai-Hulud.

Version 1 (September 2025)

Version 2 (November 2025)

Post-install (runs after installation completes)

Pre-install (runs before installation, even if install fails)

Bun (lightweight, stealthier execution)

External webhook endpoint (quickly rate-limited)

GitHub repositories (blends in with legitimate traffic)

Self-hosted GitHub Actions runners

Cross-victim token recycling (botnet effect)

Destructive wiper (i.e. dead man's switch)

CI/CD environment-aware execution (i.e. sync vs async)

700+ packages, 27,000+ repositories, and

~7k repositories still active on GitHub as of publishing this blog.

Table 2: A comparison of the features and functionalities of Shai-Hulud V1 and V2.

The attack begins when a developer or a CI/CD pipeline installs a compromised npm package. Unlike the first campaign , which relied on postinstall hooks, Shai-Hulud V2 exploits the preinstall lifecycle script. This critical change increases the impact of the attack, as the malicious code executes before the package installation completes, allowing even failed installations to trigger the payload.

A key advancement in Shai-Hulud V2 is the adoption of Bun , a high-performance JavaScript runtime, instead of Node.js. The setup_bun.js dropper script performs several functions, such as:

This approach provides multiple evasion layers, such as:

The malware’s behavior adapts depending on the execution environment.

Detected via environment variables such as GITHUB_ACTIONS , BUILDKITE , CIRCLE_SHA1 , CODEBUILD_BUILD_NUMBER , and PROJECT_ID . The malware operates as follows:

Developer environments

The following code demonstrates how the malware dynamically detects its execution environment.

The malware deploys a strategy to discover and exploit credentials across different sources:

The following code shows how the malware performs token validation.

The malware bundles official software development kits (SDKs) for Amazon Web Services (AWS), Google Cloud Platform (GCP), and Azure, enabling it to operate independently of host tools:

Identifies credentials from multiple sources, including environment variables, single sign-on (SSO), token files, container metadata, instance metadata, and configuration profiles, while scanning across 17 regions for secrets stored in AWS Secrets Manager.

Leverages Application Default Credentials (ADC) to authenticate and extract secrets from Google Secret Manager.

Utilizes DefaultAzureCredential to authenticate and retrieve secrets from Azure Key Vault.

The malware incorporates TruffleHog , a legitimate open-source secret scanning tool, to scan the user's entire directory. This process looks for:

The TruffleHog binary is cached in ~/.truffler-cache/ for subsequent executions.

In Shai-Hulud V2, stolen data is exfiltrated to GitHub repositories that are created using compromised tokens, rather than relying on external command-and-control (C2) servers, which in V1 were vulnerable to rate-limiting. By leveraging GitHub's API traffic, this method masks malicious activity as legitimate and makes detection more challenging.

The malware creates repositories with:

Each repository contains files, all uploaded in double Base64 encoding to evade detection. The table below summarizes the content of these exfiltrated files:

System information, GitHub token used for exfiltration, and account metadata.

Complete dump of process.env , containing all environment variables.

Secrets from AWS, GCP, and Azure secret secret managers.

GitHub Actions repository secrets extracted via API.

TruffleHog scan results from the user's directory.

Table 2: Details the files exfiltrated by Shai-Hulud V2.

Shai-Hulud V2 can leverage stolen credentials from other victims. If the malware fails to extract a valid GitHub token from the current environment, it searches for repositories created during infections.

The following code demonstrates how the malware locates and retrieves these stolen tokens.

Shai-Hulud V2 creates a network effect , where each compromised account can potentially expose credentials belonging to other victims. This approach significantly extends the malware's operational lifespan, even as individual tokens are revoked or accounts are secured.

The malware exploits valid npm tokens to automate its spread across the npm ecosystem without direct threat actor intervention. Once a token is discovered, the malware performs the following steps:

The code below demonstrates how the malware automates these steps.

Shai-Hulud V2 features self-hosted GitHub Actions runners. This capability provides threat actors with persistent, authenticated remote code execution (RCE) that survives system reboots and can be triggered anytime, giving them long-term control over compromised environments.

With a stolen GitHub token that includes the Workflow OAuth scope, the malware initiates the following sequence:

Cross-platform compatibility

The malware is capable of deploying self-hosted runners across Windows, macOS, and Linux, using tailored installation steps for each operating system.

Below is the code that automates the runner installation process for Linux systems.

After installing the runner, the malware creates a malicious workflow file ( .github/workflows/discussion.yaml) that contains an intentional command injection vulnerability. This vulnerability allows threat actors to execute arbitrary commands on the victim’s system by inserting them into the body of a GitHub Discussion.

The vulnerability resides in the following line of the workflow: run: echo ${{ github.event.discussion.body }}

The malicious workflow runs on the compromised self-hosted runner, meaning any threat actor with access to the repository can trigger the execution of arbitrary commands by opening a discussion.

The GitHub Actions backdoor significantly elevates the capabilities of Shai-Hulud V2 in the following ways:

The malware also deploys a secondary workflow ( .github/workflows/formatter_123456789.yml ) to steal GitHub Actions secrets. The workflow collects sensitive information stored in repository secrets and packages it into a JSON artifact ( actionsSecrets.json ) that can be retrieved by the threat actor.

The malicious workflow does the following:

The actual workflow is shown below.

Shai-Hulud V2 includes a failsafe mechanism, often referred to as a dead man's switch. This functionality is triggered when the malware detects containment; specifically, if the infected system loses access to both GitHub (used for exfiltration) and npm (used for propagation). Once activated, the dead man’s switch initiates data destruction across the compromised system using cipher and shred , respectively, which can make forensic recovery virtually impossible.

If platforms like GitHub or npm take sweeping actions, such as mass-deleting malicious repositories or revoking compromised tokens, the failsafe could activate across thousands of infected systems and destroy user data.

The malware includes specialized logic for detecting and exploiting Azure DevOps build agents running on Linux systems.

Exploitation sequence

1. The malware first checks for the presence of an Azure DevOps build agent by searching for specific processes. This is achieved via a script that scans the running commands for the path / /agent/agent , as shown in the code below.

2. Upon detecting an agent, the malware uses a Docker container breakout technique to escalate its privileges, as shown in the code below.

3. The malware disables iptables firewall rules, as shown in the code below.

4. The malware modifies DNS resolution settings, allowing it to reroute traffic and evade network-based security measures.

The Shai-Hulud V2 campaign poses a significant supply chain threat to the npm ecosystem. Shai-Hulud V2 has impacted many repositories and organizations in a short period of time. This blog post provides essential steps to detect and defend against this growing threat.

Zscaler has enhanced its security measures to cover this threat, ensuring that any attempts to download a malicious npm package will be detected under the following threat classifications:

Advanced Threat Protection

Files and directories

Malicious dropper script.

Obfuscated payload (~480,000 lines)

.github/workflows/discussion.yaml

cloud.json, contents.json, environment.json, truffleSecrets.json

Exfiltrated data files.

a3894003ad1d293ba96d77881ccd2071446dc3f65f434669b49b3da92421901a

62ee164b9b306250c1172583f138c9614139264f889fa99614903c12755468d0

9d59fd0bcc14b671079824c704575f201b74276238dc07a9c12a93a84195648a

Repository description

"Sha1-Hulud: The Second Coming." or "Sha1-Hulud: The Continued Coming"

Random 18-character strings.

Self-hosted runner name

.github/workflows/discussion.yaml with command injection.

Disclaimer: This blog post has been created by Zscaler for informational purposes only and is provided "as is" without any guarantees of accuracy, completeness or reliability. Zscaler assumes no responsibility for any errors or omissions or for any actions taken based on the information provided. Any third-party websites or resources linked in this blog post are provided for convenience only, and Zscaler is not responsible for their content or practices. All content is subject to change without notice. By accessing this blog, you agree to these terms and acknowledge your sole responsibility to verify and use the information as appropriate for your needs.