AI Has Redefined Software Risk - Learn How Security Teams Can Update Their PlaybookRegister Now

New Shai-hulud worm spreads: What to know

A wave of malware has spread to 795 npm packages — and been downloaded more than 100 million times.

Tomislav Pericin headshot
Tomislav Peričin, Chief Software Architect & Co-Founder at ReversingLabsTomislav Peričin
Another npm worm is spreading. Here’s what you need to know.

In September, ReversingLabs (RL) threat researchers were among the first to discover a first-of-its-kind self-propagating worm on the npm package repository dubbed “Shai-hulud.” That first wave impacted hundreds of popular npm packages accounting for millions of downloads, as well as a large number of affected parties. 

Now, a new wave of infections linked to the Shai-hulud malware has hit the npm open-source repository, marking the second major outbreak of the self propagating worm. At the time of this writing, 795 npm packages have been compromised, many of them widely used by developers of open source and commercial applications. The list of compromised packages includes AsyncAPI related packages, including@asyncapi/specs, with more than 100 million lifetime-  and an average of 1.4 million weekly downloads. This package in particular is also believed to be the “patient-zero” package for this wave of attack, meaning it is the first known infected package.

This new set of packages was compromised via a package version update that was released with two new javascript files added: setup_bun.js and bun_environment.js. Execution of the malicious loader in setup_bun.js is triggered through the preinstall script added to package.json file. The loader then executes the obfuscated payload from the bun_environment.js file.

Preinstall script triggering malware execution

Figure 1: Preinstall script triggering malware execution

The malware copies most of the functionalities observed in the first wave, including stealing cloud service secrets and exfiltrating them to public GitHub repositories — this time with randomly generated names. However, the malware featured in this new wave comes with a specific description: “Sha1-Hulud: The Second Coming.”  

The same worm capabilities used in the first wave are also present in the malware of this second wave, in that, once a package is infected, it spawns attacks of its own by allowing the worm to propagate through other open source packages the author maintains. The Sha1-Hulud: Second Coming-variant also adds wiper functionality to the malware, where in specific cases the worm deletes user data folders.

New wiper functionality

Figure 2: New wiper functionality

Detecting Sha1-Hulud: The Second Coming

RL has identified more than 27,000 GitHub repositories created by the Sha1-Hulud: Second Coming malware in the latest attack (Figure 3). These repositories are intended for storing exfiltrated data harvested from compromised users. GitHub users concerned about whether their account has been compromised should search their account for “Sha1-Hulud:The Second Coming” to identify a (randomly) named exfiltration repository that would indicate a compromise.

Searching for the compromised GitHub users

Figure 3: Searching for compromised GitHub users

The RL Spectra Assure Community (secure.software) successfully detects the threats posed in this new wave of Shai-hulud. When searching for packages to use, look out for the TH15502 policy violation: “Detected presence of files with behaviors similar to malicious packages published on npm.”

RL Spectra Assure automate detection of this threat

Figure 4: RL Spectra Assure automate detection of this threat

RL recommends that development teams review all dependency updates from the last 12 hours. To prevent getting infected with Sha1-Hulud, disable automated dependency upgrading without prior verification.

The RL threat research team is continuing to monitor this malicious campaign, and more updates will be shared to RL Blog. For the most up-to-date, real-time updates, follow RL on X and/or Bluesky.

Worm outbreaks prompt security reforms

The Shai-hulud malware was first identified by RL researchers on September 15. That attack began with a compromise of the npm package rxnt-authentication version 0.0.3, published Sep 14, 2025, after which  the malware quickly spread to infect hundreds of npm packages, including some with large weekly download numbers. (Read our origian Shai-hulud FAQ.) 

Following the initial outbreak of the Shai-hulud worm in September, GitHub, which maintains the npm registry, unveiled measures to harden the npm package publishing process against account takeovers and malware injection. Those measures include requiring two-factor authentication (2FA) for all local publishing; limiting the lifespan of tokens to seven days; and promoting the use of trusted publishing- an approach pioneered by PyPI that removes API tokens from build pipelines.

Developers publishing a package directly from their own machine (local publishing), rather than via a trusted, automated system (trusted publishing), will need to use hardware security keys, biometrics, authenticator apps, or some other form of 2FA to authenticate themselves.

Indicators of Compromise (IoCs)

Indicators of Compromise (IoCs) refer to forensic artifacts or evidence related to a security breach or unauthorized activity on a computer network or system. IoCs play a crucial role in cybersecurity investigations and incident response efforts, helping analysts and security professionals identify and detect potential security incidents.

The following IoCs were collected as part of RL’s investigation of this malicious software supply chain campaign.


FAQ: The Shai-hulud attacks (versions 1.0 and 2.0)

What is Shai-hulud, and why is this campaign notable?

  • “Shai-hulud” is a self-replicating worm found in the npm package registry.
  • The worm exploits compromised npm developer accounts, then uses them to inject malicious code into packages that the compromised accounts maintain. Shai-hulud then spreads via package inter-dependencies. 
  • Shai-hulud is one of the first known worms that operates within the open source supply chain at scale, combining token-stealing, the exposure of private code repositories, and automated propagation.

When and how was the worm discovered?

  • RL researchers first detected Shai-hulud as a cascading compromise on September 15.
  • Researchers identified the npm package rxnt-authentication version 0.0.3, published September 14 at 17:58:50 UTC as the first known compromised package (patient zero).
  • Between this initial detection and September 16, the campaign affected hundreds of npm packages, including some with large weekly download numbers.

What does the worm do?

  1. Code Injection & Autospreading
    • After compromising an npm account, the worm finds other packages maintained by that account. It automatically creates new versions of those packages with a postinstall script, adding a malicious bundle.js.
    • This bundle.js is executed when users install the package.
  2. Secret / token theft
    • The worm’s bundle script searches for environment tokens, focusing on npm, GitHub, AWS, GCP, etc.
    • It uses TruffleHog, a popular open-source tool that can detect more than 800 different types of secrets, to identify the victims’ secrets.
  3. Exfiltration to GitHub
    • Data is exfiltrated to GitHub repositories created by the attacker, named “Shai-hulud Repository,” with the description “Shai-hulud Repository.” The stolen data is double Base64-encoded in a file called data.json.
    • Also, in some compromised user accounts, a new branch named Shai-hulud is added in existing repositories, with a malicious GitHub Actions workflow (.github/workflows/Shai-hulud-workflow.yml) that exfiltrates accessible tokens.
  4. Exposure of private repos
    • The worm attempts to create public copies (“migration”) of all private GitHub repositories belonging to the compromised account, naming them with a “-migration” suffix. These are described as “Shai-hulud Migration.”
    • The intent appears to be both exposure of source code and secrets embedded in private repos, possibly for the purpose of harvesting and re-use by malicious actors.

Which packages / developers have been affected?

  • Hundreds of npm packages were compromised, including several popular ones. They include ngx-bootstrap ( about 300K weekly downloads), ng2-file-upload (about 100K weekly downloads), and @ctrl/tinycolor (about 2.2 million weekly downloads).
  • The compromised maintainer accounts are diverse and include maintainers of open source libraries, founders/CTOs of tech firms, developers in AI companies, non-profits, security companies, etc.

How can I check whether I (or my organization) are infected?

  • On GitHub, check for new repositories you didn’t create, especially with descriptions such as “Shai-hulud Migration.”
  • Look for branches in your existing repositories named Shai-hulud.
  • Inspect whether any of your npm packages have been updated in ways you didn’t author or approve.
  • If you maintain any packages, the Spectra Assure Community can help your team see whether any packages you manage have been flagged as infected.

What are the Indicators of Compromise (IOCs)?

  • A list of package names + versions + SHA-1 hashes of compromised versions has been published and can be viewed on the RL research team’s post.
  • The GitHub repos created by the attackers (“Shai-hulud Repository”, “Shai-hulud Migration”) and branches/workflows with known naming conventions.

What similarities or connections to earlier attacks are there?

  • The techniques resemble those used in the “Nx compromise” (late August) and other recent attacks on open source maintainers involving token theft, exfiltration, and CI/CD vector abuse.
    Prior attacks exposed the vulnerabilities that are common in popular open source packages. 
  • Attacks targeting the maintainers of packages exposing widely used dependencies have also been seen before, as recently as the compromise of Qix
  • Shai-hulud is an escalation and exception to other incidents impacting open source, because of its worm-like propagation and its multifaceted impact (tokens, private repos, etc.). 

What should npm and other repos do to stop the next Shai-hulud?

  • Open-source registries like npm, PyPI and RubyGems should implement an emergency shutdown or pause button for new package publications during active, widespread attacks. 
  • Add more robust monitoring for anomalous package updates and version changes for maintainers.
  • Improve security posture for maintainers: Two-factor authentication (2FA), token hygiene, limiting privileges, rotating tokens.
  • Increase automation and tooling for detection (e.g. labeling infected packages, scanning for suspicious postinstall scripts) plus faster communication from registries when high-impact compromises are identified.

November 2025 Campaign Update

What Changed in November?

Weeks after the initial appearance of Shai-hulud in September, a second campaign was observed in November 2025, targeting npm maintainers and CI environments. Unlike the first wave, the November operation (“Sha1-Hulud: The Second Coming,” or more broadly refrerred to a Shai-hulud 2.0) emphasized credential harvesting and controlled propagation over broad typosquatting.

The threat actor reused parts of the earlier Shai-hulud toolset but refined packaging scripts and obfuscation, showing a deeper understanding of npm publishing workflows. The following FAQ updates and expands RL's earlier FAQ for Shai-hulud 1.0 with new technical details, detection priorities, and defensive actions taken from the second campaign. 

What is the new malware called? 

  • The new npm malware is referred to as “Sha1-Hulud: The Second Coming” based on a description attached to the GitHub repositories created by the malware and used to exfiltrate stolen data and secrets.  
  • Most reports refer to the malware as Shai-hulud 2.0.

What distinguishes the November campaign from the original wave?

  • The second campaign reused the same worm framework and capabilities including stealing cloud service secrets and exfiltrating them to public GitHub repositories.
  • As with the first version of Shai-hulud, Shai-hulud 2.0 malware infected packages and then allowed the worm to propagate through other open source packages that the compromised author maintains. 

Notable differences between the two campaigns include:  

  • The use of randomly generated names for the GitHub repositories used to exfiltrate data.
  • The addition of wiper functionality capable of deleting user data folders 

How did the latest malware infect packages? 

  • Sha1 Hulud: The Second Coming spread via a package version update that was released with two new javascript files added: setup_bun.js and bun_environment.js
  • Execution of the malicious loader in setup_bun.js is triggered through the preinstall script added to package.json file. 
  • The loader then executes the obfuscated payload from the bun_environment.js file.   

How did propagation change between Shai-hulud 1.0 and 2.0?

Propagation did not change significantly between the first and second versions of Shai-hulud.

  • Threat actors placed malicious code into more than 700 npm packages, some of them prominent and widely used including @asyncapi/specs, which averages more than 1.4 million weekly downloads. 
  • Developers who installed an infected package unwittingly executed the malware during installation, giving the attackers access to the developer’s machine and development resources. 
  • The automated tool TruffleHog was then deployed to locate sensitive information like GitHub or NPM credentials, API keys and more
  • Stolen secrets granting access to code repositories or package registries were re-deployed by attackers to break into more developer accounts and publish more malicious packages, allowing Shai-hulud 2.0 to spread. 

What new IOCs have been reported?

Analysts documented a wide range of new package names, staging URLs, and domain patterns distinct from the first campaign. Refer to RL’s published IOCs (PDF) for a list of the new indicators and populate your detection feeds with hashes and domains once confirmed.

Which organizations are affected?

RL observed packages associated with AsyncAPI, Browserbase, ENS, OKU Motion PostHog, Postman, Trigo, Zapier, and many other organizations that were affected by the Sha1-Hulud: The Second Coming campaign. Refer to RL’s published IoCs for a list of affected packages. (PDF

How can developers detect local infection?

Check for unexpected .npmrc entries, recent global installs, or hidden scripts in node_modules subtrees. Also, compare the registry’s published tarball to your repository build output to ensure alignment.

Additionally, RL's Spectra Assure Community successfully detects the threats posed in this new wave of Shai-hulud including SQ30109, indicating the presence of malicious files through analyst-vetted file reputation. When searching for packages to use, look out for designations such as that, or the TH15502 policy violation, which flags the presence of files with behaviors similar to malicious packages published on npm.

Which CI/CD defenses help most?

To help defend against future attacks such as Shai-hulud 1.0 and 2.0, developers should take steps to harden their npm package publishing process against account takeovers and malware injection. Those steps should include: 

  • Requiring two-factor authentication (2FA) for all local publishing
  • Limiting the lifespan of tokens to seven days
  • Promoting the use of trusted publishing to remove API tokens from build pipelines.Trusted publishing requires developers publishing a package directly from their own machine (local publishing), rather than via a trusted, automated system to deploy hardware security keys, biometrics, authenticator apps, or some other form of 2FA to authenticate themselves.
  • Enforcing short-lived OIDC-based credentials instead of static tokens.
  • Restricting publish permissions to dedicated release jobs.
  • Blocking global npmrc files on runners and disallowing secret reuse.
  • Requiring provenance-attested builds (npm + Sigstore).

Can provenance prevent similar attacks?

Yes, as npm provenance ensures published packages match a trusted workflow origin (e.g., GitHub Actions OIDC). If stolen tokens such as those harvested by the Shai-hulud 1.0 and 2.0 malware are used outside that path, publish attempts are rejected. This directly neutralizes the Shai-hulud method of credential reuse.

How should maintainers respond if compromised?

  1. Revoke all npm tokens (user and automation).
  2. Compare registry tarballs vs. source; republish clean versions with provenance.
  3. Announce advisories detailing affected versions and remediation.
  4. Review logs and Investigate lateral movement into Git/CI credentials.

What should organizations be monitoring?

Development organizations concerned about threats like the Shai-hulud npm worm should configure alerts around suspicious behaviors associated with registry-native malware and other attacks including:

  • Unexpected npm publish events.
  • The addition or removal of package maintainers.
  • Moved latest tags or major version bumps outside normal cycles.
  • New token creations from unknown IPs.
  • The addition of unexplained, obfuscated code

How did obfuscation and loader code evolve?

The November samples appear to vary string encodings and staging URLs per build but maintain a consistent behavioral signature that includes credential scraping and remote data exfiltration.

Can MFA still be bypassed?

Yes. The latest Shai-hulud campaign showed how attackers can abuse automation tokens, which are not protected by user-interactive multi-factor authentication (MFA). To address this risk, organizations should mandate provenance enforcement and scoped automation tokens to close this gap.

Are consumers of npm packages at risk?

Yes. Both Shai-hulud campaigns underscore how developers that install a tainted dependency and execute its lifecycle scripts are at risk of compromising the security of their code and potentially exposing CI credentials. Developers who rely on npm package dependencies should run installs with --ignore-scripts in untrusted contexts and prefer sandboxed environments to reduce the risk of compromise. 

What long-term governance updates should CISOs consider?

  • Enforce provenance for all published artifacts.
  • Require 2-person review for publish rights.
  • Mandate quarterly token rotation attestations.
  • Incorporate npm event monitoring into security and information event management (SIEM) pipelines.
Back to Top