.png)
On September 15, 2025, an engineer discovered a supply chain attack against the NPM repository. Unlike previous NPM attacks, this campaign used novel, self-propagating malware (also known as a worm) to continue spreading itself. At the time of this writing, approximately 200 infected packages have been identified, including several repositories such as the popular @ctrl/tinycolor and multiple owned by CrowdStrike.
Once executed, this novel worm — dubbed Shai-Hulud — steals credentials, exfiltrates them, and attempts to find additional NPM packages in which to copy itself. The malicious code also attempts to leak data on GitHub by making private repositories public.
The Sysdig Threat Research Team (TRT) has been monitoring this worm’s progress since its discovery. Due to quick response times, the number of new packages being compromised has slowed considerably. No new packages have been seen in several hours at the time of this writing, though that is still subject to change.
Let’s explore how this novel worm works, how to detect it with open source Falco and Sysdig Secure, and what you should do next.
How does the Shai-Hulud worm work?
The worm executes during the post-install phase of the compromised NPM packages, running a huge bundle.js script.
...
"scripts": {
...
"postinstall": "node bundle.js"
}
...This code targets Linux and macOS machines, performing multiple operations in parallel to spread itself in the NPM package registry and steal sensitive information like credentials.
After the malicious NPM package is installed, Shai-Hulud conducts local system discovery. It begins searching for sensitive details on the machine, including GitHub and NPM credentials, as well as credentials for AWS and GCP. Next, the malware tries to spread itself and compromise other ecosystems.
If GitHub credentials are found, the worm uses the GitHub user and their credentials ( ghp_* and gho_* tokens), iterating over the repositories belonging to the user, to gain persistence and steal their associated secrets via a malicious GitHub action that is invoked on a “push” action. To receive the credentials, the site https://webhook[.]site is used. This site, while not inherently malicious, is free to use and often leveraged by attackers as a dropbox for collected data.
Another nefarious action the malicious code executes is to list all the repositories owned by the organization to which the user has access. If these repositories are private, a new public repository — including its contents — is created using the user’s credentials and original data. The new public repository name is identical to the original, with an added -migration suffix.
The worm part of the malware involves the NPM ecosystem. If the malware finds valid NPM credentials, it invokes the getPackagesByMaintainer() function, which retrieves a list of packages maintained by the key owner, retrieves their details, and sorts them by monthly downloads.
Next, Shai-Hulud invokes the updatePackage() function using the list of packages. This function spreads the malicious “bundle.js” code to the maintainer’s package, running that script in the postinstall phase. The original package.json is tampered with to execute “bundle.js”. This piece of code is the reason why the spread of the worm proliferated so quickly in the first 24 hours, affecting around 200 packages.
The trufflehog binary is downloaded and used to search for other sensitive credentials in the filesystem, verifying that any discovered secrets are legitimate.
Trufflehog is a popular open source security tool used to discover secrets. Below is the command used to look for sensitive data in the filesystem.
trufflehog filesystem . --json --results=verified
Shai-Hulud also contains code that looks for AWS and GCP credentials, searching both locally in the file system and any Instance Metadata Service (IMDS) endpoints.
Lastly, once all the previous data has been collected, the malicious JavaScript checks again if the GitHub user is authenticated. If so, it creates a new GitHub repository named “Shai-Hulud”, where the previously found credentials are uploaded in a base64 encoded JSON file.
Many of Shai-Hulud’s techniques look similar to the Nx attack reported at the end of August. However, despite the similarity, the most interesting aspect here is that the malware has significantly evolved, gaining the capability to reproduce itself in the NPM ecosystem.
How do you detect Shai-Hulud?
Sysdig Secure threat detection
The malware performs multiple suspicious executions at runtime.
Sysdig Secure customers can leverage the Reverse Shell Redirects STDIN/STDOUT Using UNIX Socket observation rule, belonging to the Sysdig Runtime Behavioral Analytics policy. This rule can detect suspicious executions spawned by JS applications, such as downloading the trufflehog binary, extracting it, and assigning execution permissions.
Additionally, the rule Suspicious Domain Contacted During Package Install will also trigger on the GitHub action runner when it reaches out to webhook[.]site.
For customers who are also using Sysdig Secure for GitHub threat detection, the following rule may trigger, depending on the stolen credentials:
- Create Public Github Repository
Falco
Falco customers who have adopted Falco plugins, such as the GitHub plugin, can also conduct threat detection for GitHub. This GitHub rule will detect suspicious GitHub repository names, which can help users detect new GitHub repository names matching the previously mentioned “Shai-Hulud” one, and also the “s1ngularity-repository” that was used in the previous s1ngularity/nx attack.
- rule: Create Suspicious Public Repository
desc: Detect the creation of a new public repository
condition: github.type=repository and github.action=created and github.repo.public=true and (github.repo.name="Shai-Hulud" or github.repo.name contains “s1ngularity-repository” or github.repo.name endswith “-migration” )
output: A new public repository was created (repository_name=%github.repo.name repository_url=%github.repo.url repo_owner=%github.owner org=%github.org user=%github.user)
priority: WARNING
source: github
tags: [github]Sysdig Secure Threat Intelligence feed
The Sysdig Threat Research Team has proactively added SysQL queries to the Threat Intelligence page ( Home -> Threat Intelligence ) that automatically query the inventory for any presence of the affected packages and versions. At a glance, these will tell you if these compromised packages have been installed anywhere in your environment.
Sysdig TRT’s suggested actions
- Search for any usage of the affected packages in your environment and, if detected, roll them back to a known secure version.
- Utilize version pinning whenever possible.
- Ensure all areas where third-party software packages are installed in production or moving through pipelines are monitored by runtime security controls and accounted for.
- If affected, rotate all credentials that may have been accessed.
- If you lack detection or containment controls across your developer ecosystem, the situation can be limited by blocking npm.
- Check GitHub for any unusual activity or repositories created recently.
- You might also want to check individual computers of engineers for execution of TruffelHog or outbound connections to webhook[.]site.
Conclusion
Supply chain attacks are increasing in frequency. It is more important than ever to monitor third-party packages for malicious activity. Since malicious code can be hidden in many different ways, using runtime threat detection is critical to catching these attacks. Falco and Sysdig Secure both offer runtime visibility and detections, while Sysdig Secure offers additional detections and an inventory system that can easily show if your environment is affected by malicious packages.
