Navigating the Shai-Hulud Worm 2.0: Elastic's updated response to npm supply chain compromise

December 1, 2025

Everyone loves a sequel, right? Since Monday, November 24th the software development community has been dealing with the news that Shai-Hulud Worm has returned and has been updated to 2.0. The community has been in response mode, and Elastic is no exception. While Elastic products do not ship with Node Package Manager (npm), our software, like many, uses npm to retrieve packages from npmjs.com package registry during builds.

In this blog, we’ll walk through the steps Elastic took to monitor and put measures in place to mitigate the threat posed from the ever-increasing number of compromised packages. We’ll also share our prevention and detection rules, hunt queries, and recommendations in line with this new iteration of Shai-Hulud.

Understanding the evolved threat: Shai-Hulud 2.0

The sheer scale of the npm ecosystem makes it a prime target for malicious activity. In November 2025, a new variant of the malicious npm worm referred to as Shai-Hulud: The Second Coming due to the campaign marker used in the GitHub repository descriptions emerged following the initial September 2025 attack and is actively leaking data. It has compromised hundreds of packages, including popular projects from AsyncAPI, Zapier, PostHog, and Postman.

The similarity to the initial variant is that npm packages are infected with self-replicating malware. However, Shai-Hulud 2.0 differs from its first iteration in that it will install bun with the file setup_bun.js and then use that to execute bun_environment.js, which contains the malicious code. It then exfiltrates stolen data by creating randomly named GitHub repositories often publishing one victim's data to a repository associated with a separate, unaffiliated victim known as “cross-victim exfiltration.” The newly created GitHub repositories have the description Sha1-Hulud: The Second Coming.

Ultimately, this means that simply searching your own repositories may not reveal data leaked from your environments. Additionally, Shai-Hulud is no longer limited to infecting 20 npm packages; it will now infect up to 100 npm packages and wipe the user's home directory if it can't authenticate using GitHub or npm credentials.

Elastic's response

Using the lessons and mechanisms implemented following the initial Shai-Hulud incident, Elastic was able to deploy immediate and comprehensive defenses.

Dependency inventory: Elastic continuously scans our products using software composition analysis (SCA) tooling which allowed us to quickly understand what packages are being used and where.
Threat intelligence: Using multiple threat intelligence feeds to check the growing list of malicious packages against our dependency inventory and trigger alerts.
Npmjs best practice and restrictions: Since Shai-Hulud 1 in September, Elastic teams have been moving to Trusted Publisher, allowing for those to continue publishing; any remaining tokens were revoked, preventing the ability to publish with a long-lived token.
Dependency minimum age: We have implemented a minimum package release age (cooldown period) in our automation, ensuring new package versions are not automatically pulled until they have been available for 14 days.
Implement endpoint scanning: Using the OSQuery integration for Elastic Agent, we implemented continuous scanning for the known compromised npm packages installed on Elastic laptops.
Run out-of-the-box (OOTB) detection rules: Elastic Security Labs already provides OOTB Elastic Security detection rules to aid in identifying systems that have installed and are running a compromised package. We’ve included more details on the protections listed below that you can use for your own threat hunting.
Notify Elastic developers: Advisories were sent to Elastic developers, notifying them of the ongoing investigation and prohibiting the update or installation of new npm packages.

The second coming strikes closer to home

Through our partner, Entro, Elastic was made aware that an Elastic continuous integration (CI) pipeline had run the Shai-Hulud 2.0 malware and published data to a public GitHub repository. This pipeline is used for GitOps, specifically an orchestrator for Elastic Cloud. There was no resulting impact on Elastic Cloud systems or Elastic customers. It was discovered that the culprit was a transitive dependency. Our rapid response and coordination with our engineering teams ensured that we contained and remediated the threat prior to potential exploitation.

Rapid containment and remediation

Removed the open-source dependency that contained the malware from all identified Elastic GitHub repos
Identified pipelines or manual processes where the malware would be run
Identified CI runs and users affected
Identified secrets available to these runs
Rotated all secrets (non-ephemeral)

Confirmed no customer impact

GitHub quickly deleted the repository that exposed Elastic extracted data, which included four files:
- cloud.json containing no data
- contents.json containing details about a CI runner as well as an unrelated GitHub user and that unrelated user’s GitHub token
- truffleSecrets.json containing false-positive secret findings
- environment.json contains environment variables associated with a CI runner, including secrets used in the build. Note: Elastic ensured these secrets were revoked.
There is no evidence Elastic secrets were ever used outside of Elastic.
There is no evidence that the worm has spread to an Elastic npm package.
The pipeline is not associated with an Elastic product.
There is no impact to Elastic customers.

Hunting queries

We also recommend Elastic Security customers hunt for potential compromises in their own environments. The following KQL queries can be used to identify behaviors associated with this supply chain compromise:

// IOC for the Github Self-Hosted Actions runner name
process.name:Runner.Listener and process.command_line:*SHA1HULUD*

// IOC - node/bun executing bun_environment.js
process.name:(node or bun) and process.args:*bun_environment.js

// credentials discovery using trufflehog from node/bun or node_modules related working directory 
process.name:("trufflehog" or "trufflehog.exe") and process.args:"filesystem" and process.args:"--json" and (process.parent.name : (node or bun or node.exe or bun.exe) or process.working_directory:*node_modules*)

// curl used to download GH actions runner to victim machine
process.name:(curl or or curl.exe or powershell.exe or wget or wget.exe) and process.command_line:*github.com/actions/runner/releases/download*

//docker escape via mounting the host file system and executing bash commands to tamper with the host file system
process.name:docker and process.args :("--privileged" and run) and process.args :"-v" and process.args :/\:/*  and  process.args :(bash or sh or cp)

Example of matches:

OOTB Elastic detections

The following out-of-the-box detection and prevention rules also provide updated coverage for the Shai-Hulud Worm 2.0 activities:

Unusual Network Connection to Suspicious Web Service (Detection Engine)
Connection to Commonly Abused Web Services (Detection Engine)
Potential Discovery of DPAPI Master Keys (Elastic Defend)
Potential Discovery of Windows Credential Manager Store (Elastic Defend)
Web Browser Credential Access via Unsigned Process (Elastic Defend)
Potential Browser Information Discovery (Elastic Defend)
Web Browser Credential Data Accessed by Unsigned or Untrusted Process (Elastic Defend)
Curl or Wget Spawned via Node.js (Detection Engine)
Credential Access via TruffleHog Execution (Detection Engine)

Commitment to security

Security is foundational to Elastic’s development lifecycle and operational processes. The new Shai-Hulud Worm underscores the persistent and rapidly evolving nature of cyber threats to global software supply chains. The incident in our environment demonstrates the efficacy of our security teams and the importance of quick response. We remain committed to:

Continuous monitoring: Maintaining 24/7 monitoring of our systems and networks for any signs of compromise.
Rapid response: Ensuring our security teams are prepared to respond swiftly and effectively to new threats.
Transparency: Communicating openly with our users and community about security incidents and our mitigation efforts.

We will continue to monitor new information. And as we learn more about this event, we will update this publication. For more information on how Elastic can help secure your environment, please visit our security solutions page.

The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.