Back

Shai-Hulud-Worm

Ofek Haviv

September 18, 2025

3 minutes read

A new phase in supply chain threats

Over the past 24 hours, the security community has been tracking an unprecedented event in the open-source ecosystem: the Shai-Hulud campaign, a worm-style malware attack against the NPM registry.

The incident began with a compromise of @ctrl/tinycolor, a widely used JavaScript package. Once trojanized, the package contained a malicious payload that executed during installation. This payload scanned the local environment for sensitive information - including npm publish tokens, GitHub tokens, and cloud credentials - and exfiltrated them. Using those stolen credentials, the attackers were able to publish malicious versions of additional packages under the victims’ accounts.

This self-propagating mechanism has already resulted in more than 180 npm packages (listed below) being compromised, including some belonging to well-known vendors. Security researchers have also confirmed that the malware creates public repositories named Shai-Hulud under compromised GitHub accounts, where stolen secrets are dumped.

Recent npm compromises like the chalk/debug hijack and the s1ngularity attack on Nx showed how a single stolen maintainer credential can ripple across the ecosystem-Shai-Hulud takes that threat a step further by turning each new compromise into fuel for a worm.

Why this matters

The significance of Shai-Hulud lies in its combination of tactics:

  • It turns developer machines and CI/CD runners into targets for credential theft.
  • It uses those credentials not just for lateral movement but for self-propagation, multiplying the number of compromised packages.
  • It accelerates the timeline of supply chain compromises from days or weeks to hours, leaving organizations with almost no margin for slow detection or remediation.

This is a turning point for supply chain security. Attacks against open-source ecosystems are no longer isolated incidents - they are automated, scalable, and capable of spreading on their own.

Inside the attack

At the center of Shai-Hulud is a malicious bundle.js injected into compromised packages. When the package is installed, the script executes automatically - either during npm install or when the module is required - and immediately begins harvesting secrets. It downloads a tool like TruffleHog and scours the environment for anything valuable:

  • GITHUB_TOKEN and NPM_TOKEN variables
  • Cloud keys such as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY
  • Configuration files (~/.npmrc, CI environment files, GitHub Actions runtime)

Before putting them to use, the malware validates each token against the appropriate service (for example, calling npm whoami or hitting GitHub’s API) to ensure it has real publishing rights.

Once it has a valid GitHub token, the malware moves to persistence. It attempts to write its own workflow into repositories - typically .github/workflows/shai-hulud.yaml - ensuring that every CI/CD run continues the cycle of exfiltration. On cloud build agents, it goes a step further by probing metadata endpoints (AWS, GCP, others) to grab ephemeral IAM credentials that can yield even higher privileges.

Replication is the final and most dangerous stage. With a valid npm publish token in hand, Shai-Hulud can release malicious versions of any package owned by the compromised maintainer. That turns each victim into a new seed for infection. As more accounts are breached, the number of tainted packages grows exponentially.

Exfiltrated data doesn’t just disappear into attacker infrastructure; it also shows up in public GitHub repositories named Shai-Hulud, automatically created under compromised accounts. These repos serve as evidence of the worm’s spread and a reminder of the scale of stolen credentials.

For defenders, there are clear warning signs to monitor:

  • Unusual outbound connections during npm install
  • Sudden creation of new workflow files (especially with “shai-hulud” in the name)
  • Unexpected publishes from dormant accounts or trusted vendor namespaces like @crowdstrike/*
  • The presence of unfamiliar bundle.js scripts in node_modules that fetch binaries or launch secret scanners

Responding teams should capture artifacts - the infected node_modules tree and lockfile, CI/CD logs, audit logs of token usage, and snapshots of any “Shai-Hulud” repos - to build a forensic picture of what happened. Embedding tactical rules into monitoring and EDR systems can also help: flagging when install scripts create or modify workflows, blocking downloads from unapproved domains during installation, or alerting on unusual publishing patterns in the npm registry.

How organizations should respond

In the immediate term, teams should:

  • Pin all dependencies to specific known-safe versions rather than allowing floating or automatic upgrades; this ensures builds cannot unknowingly pull in newly compromised releases
  • Audit dependencies for any use of the compromised packages and lock to known-safe versions. (as the campaign spreads, the best possible way to look for it is to search for the hash of the malicious bundle.js )
  • Revoke and rotate tokens - including npm, GitHub, and cloud credentials - that may have been present in developer or CI/CD environments.
  • Rebuild affected artifacts from clean sources, ensuring that no infected packages remain in caches.
  • Inspect logs and audit trails for suspicious publishes, workflow changes, or the creation of unexpected repositories.
  • Harden CI/CD by moving to ephemeral runners, limiting outbound network access, and reducing reliance on long-lived secrets.

Indicators of Compromise

  • bundle.js SHA-256: 46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09
  • Exfiltration endpoint: hxxps://webhook[.]site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7
  • de0e25a3e6c1e1e5998b306b7141b3dc4c0088da9d7bb47c1c00c91e6e4f85d6
  • 81d2a004a1bca6ef87a1caf7d0e0b355ad1764238e40ff6d1b1cb77ad4f595c3
  • 83a650ce44b2a9854802a7fb4c202877815274c129af49e6c2d1d5d5d55c501e
  • 4b2399646573bb737c4969563303d8ee2e9ddbd1b271f1ca9e35ea78062538db
  • dc67467a39b70d1cd4c1f7f7a459b35058163592f4a9e8fb4dffcbba98ef210c
  • 46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09
  • b74caeaa75e077c99f7d44f46daaf9796a3be43ecf24f2a1fd381844669da777

Terra Security’s perspective

Shai-Hulud is a reminder that modern supply chain attacks aren’t just about vulnerable code - they exploit how software is built, tested, and shipped. This wasn’t just a compromised package. It was malware that lived in the dev environment, hijacked credentials, and used CI pipelines to spread.

That’s exactly the kind of attack surface Terra focuses on.

Our agentic AI platform doesn’t stop at production APIs. It continuously tests what most tools ignore: install scripts, developer workflows, CI/CD runners, and how code changes affect risk. If a malicious dependency started exfiltrating tokens or writing to GitHub Actions, Terra’s agents would catch it, not weeks later, but the moment it landed.

That’s where traditional approaches fall short. Pentests are too slow and point-in-time. Automated tools and DAST scanners are blind to dynamic, install-time behavior and the actual workflows attackers target. Terra combines continuous, context-aware testing with exploit-focused AI agents - so you see what’s really at risk, as it happens.

Because we test like attackers do - with full context of your environment - we can surface threats like Shai-Hulud before they become breaches.