In September, a new breed of malware distributed via compromised Node Package Manager (npm) packages made headlines. It was dubbed “Shai-Hulud”, and we published an in-depth analysis of it in another post. Recently, a new version was discovered.
Shai Hulud 2.0 is a type of two-stage worm-like malware that spreads by compromising npm tokens to republish trusted packages with a malicious payload. More than 800 npm packages have been infected by this version of the worm.
According to our telemetry, the victims of this campaign include individuals and organizations worldwide, with most infections observed in Russia, India, Vietnam, Brazil, China, Türkiye, and France.
Technical analysis
When a developer installs an infected npm package, the setup_bun.js script runs during the preinstall stage, as specified in the modified package.json file.
Bootstrap script
The initial-stage script setup_bun.js is left intentionally unobfuscated and well documented to masquerade as a harmless tool for installing the legitimate Bun JavaScript runtime. It checks common installation paths for Bun and, if the runtime is missing, installs it from an official source in a platform-specific manner. This seemingly routine behavior conceals its true purpose: preparing the execution environment for later stages of the malware.
The installed Bun runtime then executes the second-stage payload, bun_environment.js, a 10MB malware script obfuscated with an obfuscate.io-like tool. This script is responsible for the main malicious activity.
Stealing credentials
Shai Hulud 2.0 is built to harvest secrets from various environments. Upon execution, it immediately searches several sources for sensitive data, such as:
GitHub secrets: the malware searches environment variables and the GitHub CLI configuration for values starting with ghp_ or gho_. It also creates a malicious workflow yml in victim repositories, which is then used to obtain GitHub Actions secrets.
Cloud credentials: the malware searches for cloud credentials across AWS, Azure, and Google Cloud by querying cloud instance metadata services and using official SDKs to enumerate credentials from environment variables and local configuration files.
Local files: it downloads and runs the TruffleHog tool to aggressively scan the entire filesystem for credentials.
Then all the exfiltrated data is sent through the established communication channel, which we describe in more detail in the next section.
Data exfiltration through GitHub
To exfiltrate the stolen data, the malware sets up a communication channel via a public GitHub repository. For this purpose, it uses the victim’s GitHub access token if found in environment variables and the GitHub CLI configuration.
After that, the malware creates a repository with a randomly generated 18-character name and a marker in its description. This repository then serves as a data storage to which all stolen credentials and system information are uploaded.
If the token is not found, the script attempts to obtain a previously stolen token from another victim by searching through GitHub repositories for those containing the text, “Sha1-Hulud: The Second Coming.” in the description.
Worm spreading across packages
For subsequent self-replication via embedding into npm packages, the script scans .npmrc configuration files in the home directory and the current directory in an attempt to find an npm registry authorization token.
If this is successful, it validates the token by sending a probe request to the npm /-/whoami API endpoint, after which the script retrieves a list of up to 100 packages maintained by the victim.
For each package, it injects the malicious files setup_bun.js and bun_environment.js via bundleAssets and updates the package configuration by setting setup_bun.js as a pre-installation script and incrementing the package version. The modified package is then published to the npm registry.
Destructive responses to failure
If the malware fails to obtain a valid npm token and is also unable to get a valid GitHub token, making data exfiltration impossible, it triggers a destructive payload that wipes user files, primarily those in the home directory.
Our solutions detect the family described here as HEUR:Worm.Script.Shulud.gen.
Since September of this year, Kaspersky has blocked over 1700 Shai Hulud 2.0 attacks on user machines. Of these, 18.5% affected users in Russia, 10.7% occurred in India, and 9.7% in Brazil.
TOP 10 countries and territories affected by Shai Hulud 2.0 attacks (download)
We continue tracking this malicious activity and provide up-to-date information to our customers via the Kaspersky Open Source Software Threats Data Feed. The feed includes all packages affected by Shai-Hulud, as well as information on other open-source components that exhibit malicious behaviour, contain backdoors, or include undeclared capabilities.
If you need some motivation to keep from eating too much this Thanksgiving, here it is: Doctors in Romania pulled an 11 cm (4.3 inch) living, writhing round worm from a woman’s left eyelid.
According to a report in the New England Journal of Medicine, the worm likely hatched from a hard lump in her right temple, which the woman recalled first spotting a month beforehand. She also noticed that the nodule had vanished just a day before the worm apparently made a squiggly run for her eye.
When she went to an ophthalmologist the next day, doctors immediately noted the “mobile lesion” on her eyelid, which was in the suspicious shape of a bunched-up worm just under her skin with a little redness and swelling.
A new iteration of the Shai-Hulud malware that ran through npm repositories in September is faster, more dangerous, and more destructive, creating huge numbers of malicious repositories, compromised scripts, and GitHub users attacked, creating one of the most significant supply chain attacks this year.
GlassWorm, a self-propagating malware, infects VS Code extensions through the OpenVSX marketplace, stealing credentials and using blockchain for control.
The modern development world is almost entirely dependent on third-party modules. While this certainly speeds up development, it also creates a massive attack surface for end users, since anyone can create these components. It is no surprise that malicious modules are becoming more common. When a single maintainer account for popular modules or a single popular dependency is compromised, it can quickly turn into a supply chain attack. Such compromises are now a frequent attack vector trending among threat actors. In the last month alone, there have been two major incidents that confirm this interest in creating malicious modules, dependencies, and packages. We have already discussed the recent compromise of popular npm packages. September 16, 2025 saw reports of a new wave of npm package infections, caused by the self-propagating malware known as Shai-Hulud.
Shai-Hulud is designed to steal sensitive data, expose private repositories of organizations, and hijack victim credentials to infect other packages and spread on. Over 500 packages were infected in this incident, including one with more than two million weekly downloads. As a result, developers who integrated these malicious packages into their projects risk losing sensitive data, and their own libraries could become infected with Shai-Hulud. This self-propagating malware takes over accounts and steals secrets to create new infected modules, spreading the threat along the dependency chain.
Technical details
The worm’s malicious code executes when an infected package is installed. It then publishes infected releases to all packages the victim has update permissions for.
Once the infected package is installed from the npm registry on the victim’s system, a special command is automatically executed. This command launches a malicious script over 3 MB in size named bundle.js, which contains several legitimate, open-source work modules.
Key modules within bundle.js include:
Library for interacting with AWS cloud services
GCP module that retrieves metadata from the Google Cloud Platform environment
Functions for TruffleHog, a tool for scanning various data sources to find sensitive information, specifically secrets
Tool for interacting with the GitHub API
The JavaScript file also contains network utilities for data transfer and the main operational module, Shai-Hulud.
The worm begins its malicious activity by collecting information about the victim’s operating system and checking for an npm token and authenticated GitHub user token in the environment. If a valid GitHub token is not present, bundle.js will terminate. A distinctive feature of Shai-Hulud is that most of its functionality is geared toward Linux and macOS systems: almost all malicious actions are performed exclusively on these systems, with the exception of using TruffleHog to find secrets.
Exfiltrating secrets
After passing the checks, the malware uses the token mentioned earlier to get information about the current GitHub user. It then runs the extraction function, which creates a temporary executable bash script at /tmp/processor.sh and runs it as a separate process, passing the token as an argument. Below is the extraction function, with strings and variable names modified for readability since the original source code was illegible.
The extraction function, formatted for readability
The bash script is designed to communicate with the GitHub API and collect secrets from the victim’s repository in an unconventional way. First, the script checks if the token has the necessary permissions to create branches and work with GitHub Actions. If it does, the script gets a list of all the repositories the user can access from 2025. In each of these, it creates a new branch named shai-hulud and uploads a shai-hulud-workflow.ymlworkflow, which is a configuration file for describing GitHub Actions workflows. These files are automation scripts that are triggered in GitHub Actions whenever changes are made to a repository. The Shai-Hulud workflow activates on every push.
The malicious workflow configuration
This file collects secrets from the victim’s repositories and forwards them to the attackers’ server. Before being sent, the confidential data is encoded twice with Base64.
This unusual method for data collection is designed for a one-time extraction of secrets from a user’s repositories. However, it poses a threat not only to Shai-Hulud victims but also to ordinary researchers. If you search for “shai-hulud” on GitHub, you will find numerous repositories that have been compromised by the worm.
Open GitHub repositories compromised by Shai-Hulud
The main bundle.js script then requests a list of all organizations associated with the victim and runs the migration function for each one. This function also runs a bash script, but in this case, it saves it to /tmp/migrate-repos.sh, passing the organization name, username, and token as parameters for further malicious activity.
The bash script automates the migration of all private and internal repositories from the specified GitHub organization to the user’s account, making them public. The script also uses the GitHub API to copy the contents of the private repositories as mirrors.
We believe these actions are intended for the automated theft of source code from the private repositories of popular communities and organizations. For example, the well-known company CrowdStrike was caught in this wave of infections.
The worm’s self-replication
After running operations on the victim’s GitHub, the main bundle.js script moves on to its next crucial stage: self-replication. First, the script gets a list of the victim’s 20 most downloaded packages. To do this, it performs a search query with the username from the previously obtained npm token:
Next, for each of the packages it finds, it calls the updatePackage function. This function first attempts to download the tarball version of the package (a .TAR archive). If it exists, a temporary directory named npm-update-{target_package_name} is created. The tarball version of the package is saved there as package.tgz, then unpacked and modified as follows:
The malicious bundle.js is added to the original package.
A postinstall command is added to the package.json file (which is used in Node.js projects to manage dependencies and project metadata). This command is configured to execute the malicious script via node bundle.js.
The package version number is incremented by 1.
The modified package is then re-packed and published to npm as a new version with the npm publish command. After this, the temporary directory for the package is cleared.
The updatePackage function, formatted for readability
Uploading secrets to GitHub
Next, the worm uses the previously mentioned TruffleHog utility to harvest secrets from the target system. It downloads the latest version of the utility from the original repository for the specific operating system type using the following link:
The worm also uses modules for AWS and Google Cloud Platform (GCP) to scan for secrets. The script then aggregates the collected data into a single object and creates a repository named “Shai-Hulud” in the victim’s profile. It then uploads the collected information to this repository as a data.json file.
Below is a list of data formats collected from the victim’s system and uploaded to GitHub:
A distinctive characteristic of the modified packages is that they contain an archive named package.tar. This is worth noting because packages usually contain an archive with a name that matches the package itself.
Through our research, we were able to identify the first package from which Shai-Hulud began to spread, thanks to a key difference. As we mentioned earlier, after infection, a postinstall command to execute the malicious script, node bundle.js, is written to the package.json file. This command typically runs immediately after installation. However, we discovered that one of the infected packages listed the same command as a preinstall command, meaning it ran before the installation. This package was ngx-bootstrap version 18.1.4. We believe this was the starting point for the spread of this infection. This hypothesis is further supported by the fact that the archive name in the first infected version of this package differed from the name characteristic of later infected packages (package.tar).
While investigating different packages, we noticed that in some cases, a single package contained multiple versions with malicious code. This was likely possible because the infection spread to all maintainers and contributors of packages, and the malicious code was then introduced from each of their accounts.
Infected libraries and CrowdStrike
The rapidly spreading Shai-Hulud worm has infected many popular libraries that organizations and developers use daily. Shai-Hulud has infected over 500 popular packages in recent days, including libraries from the well-known company CrowdStrike.
Among the infected libraries were the following:
But the event that has drawn significant attention to this spreading threat was the infection of the @ctrl/tinycolor library, which is downloaded by over two million users every week.
As mentioned above, the malicious script exposes an organization’s private repositories, posing a serious threat to their owners, as this creates a risk of exposing the source code of their libraries and products, among other things, and leading to an even greater loss of data.
Prevention and protection
To protect against this type of infection, we recommend using a specialized solution for monitoring open-source components. Kaspersky maintains a continuous feed of compromised packages and libraries, which can be used to secure your supply chain and protect development from similar threats.
For personal devices, we recommend Kaspersky Premium, which provides multi-layered protection to prevent and neutralize infection threats. Our solution can also restore the device’s functionality if it’s infected with malware.
For corporate devices, we advise implementing a comprehensive solution like Kaspersky Next, which allows you to build a flexible and effective security system. This product line provides threat visibility and real-time protection, as well as EDR and XDR capabilities for investigation and response. It is suitable for organizations of any scale or industry.
Kaspersky products detect the Shai-Hulud threat as HEUR:Worm.Script.Shulud.gen.
In the event of a Shai-Hulud infection, and as a proactive response to the spreading threat, we recommend taking the following measures across your systems and infrastructure:
Use a reliable security solution to conduct a full system scan.
Audit your GitHub repositories:
Check for repositories named shai-hulud.
Look for non-trivial or unknown branches, pull requests, and files.
Audit GitHub Actions logs for strings containing shai-hulud.
Reissue npm and GitHub tokens, cloud keys (specifically for AWS and Google Cloud Platform), and rotate other secrets.
Clear the cache and inventory your npm modules: check for malicious ones and roll back versions to clean ones.
Check for indicators of compromise, such as files in the system or network artifacts.
In Q2 2025, the percentage of ICS computers on which malicious objects were blocked decreased by 1.4 pp from the previous quarter to 20.5%.
Percentage of ICS computers on which malicious objects were blocked, Q2 2022–Q2 2025
Compared to Q2 2024, the rate decreased by 3.0 pp.
Regionally, the percentage of ICS computers on which malicious objects were blocked ranged from 11.2% in Northern Europe to 27.8% in Africa.
Regions ranked by percentage of ICS computers on which malicious objects were blocked
In most of the regions surveyed in this report, the figures decreased from the previous quarter. They increased only in Australia and New Zealand, as well as Northern Europe.
Changes in percentage of ICS computers on which malicious objects were blocked, Q2 2025
Selected industries
The biometrics sector led the ranking of the industries and OT infrastructures surveyed in this report in terms of the percentage of ICS computers on which malicious objects were blocked.
Ranking of industries and OT infrastructures by percentage of ICS computers on which malicious objects were blocked
In Q2 2025, the percentage of ICS computers on which malicious objects were blocked decreased across all industries.
Percentage of ICS computers on which malicious objects were blocked in selected industries
Diversity of detected malicious objects
In Q2 2025, Kaspersky security solutions blocked malware from 10,408 different malware families from various categories on industrial automation systems.
Percentage of ICS computers on which the activity of malicious objects from various categories was blocked
The only increases were in the percentages of ICS computers on which denylisted internet resources (1.2 times more than in the previous quarter) and malicious documents (1.1 times more) were blocked.
Main threat sources
Depending on the threat detection and blocking scenario, it is not always possible to reliably identify the source. The circumstantial evidence for a specific source can be the blocked threat’s type (category).
The internet (visiting malicious or compromised internet resources; malicious content distributed via messengers; cloud data storage and processing services and CDNs), email clients (phishing emails), and removable storage devices remain the primary sources of threats to computers in an organization’s technology infrastructure.
In Q2 2025, the percentage of ICS computers on which threats from email clients were blocked continued to increase. The main categories of threats from email clients blocked on ICS computers are malicious documents, spyware, malicious scripts and phishing pages. The indicator increased in all regions except Russia. By contrast, the global average for other threat sources decreased. Moreover, the rates reached their lowest levels since Q2 2022.
Percentage of ICS computers on which malicious objects from various sources were blocked
The same computer can be attacked by several categories of malware from the same source during a quarter. That computer is counted when calculating the percentage of attacked computers for each threat category, but is only counted once for the threat source (we count unique attacked computers). In addition, it is not always possible to accurately determine the initial infection attempt. Therefore, the total percentage of ICS computers on which various categories of threats from a certain source were blocked exceeds the percentage of threats from the source itself.
The rates for all threat sources varied across the monitored regions.
The percentage of ICS computers on which threats from the internet were blocked ranged from 6.35% in East Asia to 11.88% in Africa
The percentage of ICS computers on which threats from email clients were blocked ranged from 0.80% in Russia to 7.23% in Southern Europe
The percentage of ICS computers on which threats from removable media were blocked ranged from 0.04% in Australia and New Zealand to 1.77% in Africa
The percentage of ICS computers on which threats from network folders were blocked ranged from 0.01% in Northern Europe to 0.25% in East Asia
Threat categories
A typical attack blocked within an OT network is a multi-stage process, where each subsequent step by the attackers is aimed at increasing privileges and gaining access to other systems by exploiting the security problems of industrial enterprises, including technological infrastructures.
It is worth noting that during the attack, intruders often repeat the same steps (TTPs), especially when they use malicious scripts and established communication channels with the management and control infrastructure (C2) to move laterally within the network and advance the attack.
Malicious objects used for initial infection
In Q2 2025, the percentage of ICS computers on which denylisted internet resources were blocked increased to 5.91%.
Percentage of ICS computers on which denylisted internet resources were blocked, Q2 2022–Q2 2025
The percentage of ICS computers on which denylisted internet resources were blocked ranged from 3.28% in East Asia to 6.98% in Africa. Russia and Eastern Europe were also among the top three regions for this indicator. It increased in all regions and this growth is associated with the addition of direct links to malicious code hosted on popular public websites and file-sharing services.
The percentage of ICS computers on which malicious documents were blocked has grown for two consecutive quarters. The rate reached 1.97% (up 0.12 pp) and returned to the level seen in Q3 2024. The percentage increased in all regions except Latin America.
The percentage of ICS computers on which malicious scripts and phishing pages were blocked decreased to 6.49% (down 0.67 pp).
Next-stage malware
Malicious objects used to initially infect computers deliver next-stage malware (spyware, ransomware, and miners) to victims’ computers. As a rule, the higher the percentage of ICS computers on which the initial infection malware is blocked, the higher the percentage for next-stage malware.
In Q2 2025, the percentage of ICS computers on which malicious objects from all categories were blocked decreased. The rates are:
Spyware: 3.84% (down 0.36 pp);
Ransomware: 0.14% (down 0.02 pp);
Miners in the form of executable files for Windows: 0.63% (down 0.15 pp);
Web miners: 0.30% (down 0.23 pp), its lowest level since Q2 2022.
Self-propagating malware
Self-propagating malware (worms and viruses) is a category unto itself. Worms and virus-infected files were originally used for initial infection, but as botnet functionality evolved, they took on next-stage characteristics.
To spread across ICS networks, viruses and worms rely on removable media, network folders, infected files including backups, and network attacks on outdated software such as Radmin2.
In Q2 2025, the percentage of ICS computers on which worms and viruses were blocked decreased to 1.22% (down 0.09 pp) and 1.29% (down 0.24 pp). Both are the lowest values since Q2 2022.
AutoCAD malware
This category of malware can spread in a variety of ways, so it does not belong to a specific group.
In Q2 2025, the percentage of ICS computers on which AutoCAD malware was blocked continued to decrease to 0.29% (down 0.05 pp) and reached its lowest level since Q2 2022.