top of page

Shai-Hulud Worm Reloaded: A New Wave of NPM Supply Chain Attacks and How InvisiRisk Stops It

  • Writer: Pranesh Shrestha
    Pranesh Shrestha
  • 7 minutes ago
  • 4 min read

Date of Attack: November 21-23, 2025.

Impact: More than 800 NPM packages and 25,000 GitHub repositories were affected.


The software supply chain has come under attack once again. Between November 21-23, the Shai-Hulud worm returned in a more aggressive form, rapidly spreading through the NPM ecosystem and Maven, compromising tens of thousands of repositories. This new variant, now known as Shai-Hulud 2.0, did not rely on a single weak link. Instead, it moved through trusted maintainers and widely used libraries, making its way into builds within hours as developers and CI systems pulled in new package versions.


This attack reinforces a new reality: threats now activate inside the build environment, where traditional scanning tools have no visibility. Package managers, automation pipelines, and build tools have become prime targets, and defending them requires real-time protection rather than post-build analysis.


How the Shai-Hulud 2.0 Attack Works


The latest wave of Shai-Hulud was engineered to appear completely routine. Instead of obvious malicious activity, it relied on the trust developers place in familiar open-source packages and automated tooling.


Initial Compromise

Attackers published malicious updates of well-known NPM packages. Because the names were trusted, developers and automated systems installed them without hesitation, even prompted at times by AI coding assistants.


Activation During BuildsThe malicious code remained quiet until a build or script executed it. There were no warnings; it simply ran alongside legitimate build tasks. The compromised package’s package.json triggers the pre-install script:


ree

Where the benign looking “setup_bun.js” sets up Bun and executes the 10MB+ “bun_environment.js” malicious payload.


It is noteworthy that, due to the large size of the payload, AI analysis tools’ context windows were overwhelmed, and traditional active monitoring tools that might run on the build server were not able to detect this malicious activity.


Collecting Sensitive DataOnce active, it searches for valuable information: environment variables, SSH keys, cloud tokens, configuration files, browser data, and GitHub Access Tokens artifacts.


ExfiltrationInstead of sending the data to an attacker-controlled server, the malware encoded it, created a brand-new GitHub repository in the victim’s own account, and committed the file there. The repository was made public automatically, turning the victim’s access into the attacker’s escape route. If the victim’s account was not accessible, the malware would still commit the file to another victim’s account, resulting in compromise either way.


Figure: Rouge Repository Created.
Figure: Rouge Repository Created.

Protecting Your Build Pipeline with InvisiRisk


Blocking Unauthorized Actions


InvisiRisk Build Application Firewall (BAF) includes a robust set of default security policies that enforce expected build behavior. The "Unauthorized PUT" policy serves as a critical defense against attacks like Shai-Hulud.


Figure: InvisiRisk BAF blocking unauthorized actions.
Figure: InvisiRisk BAF blocking unauthorized actions.

This is the network activity that creates a new repository with double encoded secret leaks in “.json” file. This single policy halts the exfiltration completely. While the attacker's script may execute, the compromised data can be alerted or blocked, so it never exits the build environment.


Slowing Down Fast-Spreading Attacks with Stability Buffer Periods


Supply chain attacks often spread within hours. A malicious package can be published, downloaded, installed, and built into production before anyone has time to react.


Using InvisiRisk’s custom Rego policy framework, you can easily define rules that block or flag NPM packages published within a configurable timeframe (for example, less than two days old). Stability Buffer Period introduces a safety window before brand-new package versions can be used. Teams can enforce rules such as “do not use a package published in the last 48 hours” unless explicitly approved.


This gives teams time to evaluate new releases while keeping development smooth. The waiting period can be customized per ecosystem or project; combined with the IR Score for contextual risk evaluation and continuously adapt their defenses as threat patterns evolve.


Figure: Custom Policy Blocking Recently Released Package.
Figure: Custom Policy Blocking Recently Released Package.

Build Security AI Agent: A Second Line of Defense


Alongside policy enforcement, InvisiRisk includes a Build Security AI Agent designed to notice the subtle behaviors that static rules may not catch. It learns about the normal patterns of your builds, what they access, how they behave, and what they create and raise alerts when something falls outside the norm.


  • Unexpected PUT, CREATE, or PUSH actions originating from build agents.


Figure: Build Security AI Agent showing anomalous actions.
Figure: Build Security AI Agent showing anomalous actions.

Shai-Hulud 2.0: Key Facts


Date of Attack:The new wave began on November 21-23, 2025, spreading quickly across the NPM ecosystem.


Impact: In just a few days, over 800 packages were infected, the worm jumped from NPM to Maven, and the infected packages were identified in over 25,000 repositories. No major theft has been tied to this attack yet, but the potential impact of so many stolen credentials, not to mention labor costs to remediate and loss of reputation to victims who were infected (including Zapier, Ethereum Name Service, AsyncAPI, PostHog, and Postman) is large.


InvisiRisk Features that would prevent this attack:


  • Blocking Unauthorized Actions- Stops unauthorized GitHub repository creation

  • Stability Buffer Period - Delays adoption of newly published packages to allow security review

  • Build Security AI Agent- Identifies unusual build behaviors like unexpected repository operations


What organizations should do now:

  • Reinstall dependencies and clear caches

  • Review repositories for unexpected commits

  • Rotate any secrets used in affected projects

  • Investigate build logs for unusual outbound activity


Even if the attack is contained, organizations should review their environments to ensure no residual artifacts remain.


© 2025 by InvisiRisk, Inc.

  • Twitter
  • LinkedIn
bottom of page