Checkmarx Zero began tracking an NPM supply chain attack early in the morning (Europe time) of 16. Sep 2025. The community has since named this attack “Shai-Hulud”, a reference to the desert spice worm’s in Frank Herbert’s Dune novels. This attack is, we believe, the first self-replicating supply chain attack, which uses GitHub Actions to infect repositories that consume any previously-infected package.
Update 2025-09-18: with no new tracked infections in 24 hours, it appears the attack is significantly contained. Most organizations can remove any temporary defenses that disrupt development, but must continue to monitor closely. As always, the particulars of your threat model, risk tolerance, and control posture will affect individual decisions. This post has received several updates to reflect current knowledge and provide clarification based on reader feedback.
Checkmarx Zero took action to track this campaign and began verifying infections, adding affected packages to our malicious package database, and informing Checkmarx customers
- We identified what appears to be the first user compromised: User “techsupportrxnt” shows evidence of Shai-Hulud compromise within NPM packages published by this user on 14. Sep 2025.
- The malware steals and exfiltrates a wide variety of credentials, and sets public any impacted private GitHub repos to which the user has access. It also uses identified credentials to attempt self-replication and further attacks on cloud infrastructure.
- As of this writing, approximately 600 package versions have been impacted, covering nearly 200 unique packages names. Propagation appears to have been halted or materially slowed as of 18. Sep 2025.
We’re providing a list of recommended defenses below, as well as Indicators of Compromise which can be added to relevant detection systems (such as endpoint [EDR, etc.] and network [IDP, etc.] protection tools). However, the nature of the malware means that while these IoCs indicate likely presence of the malware, their absence does not necessarily indicate safety
Zero Research Updates. Subscribe today!
Affected Packages and Indicators of Compromise (IoC)
A comprehensive list of packages is far too long for a blog post; they are available to our customers via our Malicious Package Identification API. As a service to the community, we are occasionally updating this GitHub Gist with identified packages
Also be aware of the following Indicators of Compromise (IoC).
- Connections to “
webhook[.]site“ with ID “bb8ca5f6-4175-45d2-b042-fc9ebb8170b7“ ; for URL matching:https://webhook[.]site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7 - Presence of a file typically named
bundle.jswith one of the file hashes listed below - Presence or loading of a GitHub Actions workflow named like “
shai-hulud-workflow.yml“ - Presence of a repository branch “
shai-hulud“ - Private GitHub repos suddenly becoming public
Files matching the hashes below should be considered signs of infection. Note that the absence of such files is not a guarantee of safety, as the contents of payload files are attacker-controlled.
46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09
b74caeaa75e077c99f7d44f46daaf9796a3be43ecf24f2a1fd381844669da777
dc67467a39b70d1cd4c1f7f7a459b35058163592f4a9e8fb4dffcbba98ef210c
4b2399646573bb737c4969563303d8ee2e9ddbd1b271f1ca9e35ea78062538dbResponse recommendations
-
Disable access to NPM– prevent your workflows from publishing potentially infected packages to NPM, and prevent them from pulling updates to your NPM dependencies.(Update 2025-09-18: this is no longer required for most organizations) - Continually scan – if you have an SCA with Malicious Package Protection capability (such as Checkmarx customers), scan your entire Javascript/NPM footprint routinely to ensure that you get up-to-date information. Continue to ensure frequent SCA scanning of NPM-based software projects to maintain an accurate package inventory
- Monitor your repos and network activity for indicators of compromise – these are changing rapidly, and are available for any impacted package via our API. Common ones are provided here.
- Configure your EDR/IDP and similar systems to monitor for known indicators of compromise
- Rotate any access keys and similar secrets if you suspect any compromise
- If you have not already, consider implementing a package repo cache to avoid direct access to NPM and provide a control point for responses to future attacks
How does Shai-Halud work?
Infected repositories include a JavaScript payload that performs many actions, including downloading an open-source secrets scanner to identify possible credentials, probing AWS and Google Cloud environments to determine if there are defenses in place (and attempting to steal further credentials from the control planes), and staging the next step of the attack.
A shell script embedded in the JavaScript receives any GitHub access tokens the first stage discovered, and then checks for other repositories that the token has access to. These repositories are then given the third stage of attack: a new GitHub Actions workflow file called “shai-hulud-workflow.yml“, then triggers that action. The infected github action exfiltrates data via calls to a web service at “ https://webhook[.]site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7“ with available secrets as the payload. The infected repositories are also made public – not just the impacted user’s own private repositories, but any repository they had access tokens for.
Exfiltrated NPM and repository credentials then seem to be leveraged by the attackers to further the infection, likely in an automated “worm-like” fashion.
What now?
Until infrastructure providers like GitHub and NPM are able to develop an effective counter-measure, organizations must act defensively. This will likely cause disruption to developer workflows and major losses of productivity, but the potential for credential exfiltration likely has a much larger impact. (Update 2025-09-18: this is no longer required for most organizations, revised advice follows)
While the initial attack appears to be contained as of 18. Sep 2025, the fundamental weaknesses it exploits continue to exist. Organizations must review their controls against malicious open-source libraries and ensure that there are clear response plans in place to address future attacks.
Keep following threat feeds and malicious package database updates, and continuously scan your code, CI runners, developer workstations, and GitHub Actions for indicators of compromise.
Zero Research Updates. Subscribe today!