Shai-Hulud NPM Worm Attack: Overview and InvisiRisk Protection

A novel self-propagating malware strain dubbed the Shai-Hulud worm has recently infected hundreds of JavaScript (NPM) packages. Security researchers report that at least 187 NPM packages are known to have been compromised and the damage caused by this threat is suspected of impacting more than 500 packages in total.  This worm steals developer credentials (NPM, GitHub, AWS/Azure/GCP tokens, etc.) and publishes them publicly on GitHub. In each infection, the malicious code looks for secrets on the developer’s machine (using tools like TruffleHog) and, if a GitHub token is present, it creates a public repository named “Shai-Hulud” and commits a file (data.json) containing the stolen secrets (encoded in double-base64). It also pushes malicious GitHub Actions workflows into the developer’s projects, causing any new CI runs to leak further secrets to the attacker’s endpoint. The worm self-propagates: it uses any found NPM tokens to automatically publish malicious updates to the top packages the developer has access to. This creates a cascading effect where one infected developer can inadvertently infect dozens of packages under their control. The result is a large-scale supply chain breach with many secrets exposed and urgent key-rotation and cleanup required across the ecosystem.

Attack Progression

1. Initial Compromise: Attackers first inject malicious code into popular NPM packages (for example, the tinycolor library and dozens of others) by harvesting stolen credentials of maintainers via a phishing attack and publish these to the NPM registry. Developers unknowingly install a compromised package into their projects.

2. Secrets Harvesting: When an infected package is installed or run, the payload activates. It begins by searching the developer’s machine and CI environment for any secrets. In practice, the worm downloads and executes a tool like TruffleHog to scan for tokens and credentials.  The worm scans environment variables as well as cloud metadata endpoints. It looks specifically for keys such as NPM_TOKEN, GITHUB_TOKEN, AWS/Azure/GCP credentials, SSH keys, etc. and validates them (e.g. verifying NPM_TOKEN with an API call).

3. Exfiltration via GitHub: If the worm finds a GitHub token or other credentials, it begins exfiltration. It uses the token to create a new public GitHub repository named “Shai-Hulud”.  This repository writes a data.json file containing the stolen secrets. The secrets are encoded (often in double Base64) to obfuscate them, but the repository is public, so anyone can decode and see the credentials. (Security teams have identified that the worm pushes every victim’s secret to the created Shai-Hulud repository, hence the name.)

   

   Figure: Rouge Repository “Shai-Hulud” Created.

4. Malicious Workflows: Simultaneously, the worm pushes a malicious GitHub Actions workflow file into other repositories the developer has access to. Typically, it creates a new branch (often named “shai-hulud”) in each repository and adds a workflow that will, on the next CI run, send secrets to the attacker (for example via a hidden webhook). In some cases, the worm even clones private repos and republishes them as public “-migration” copies under the attacker’s control. These automated workflows ensure that any future builds (or collaborators) will leak more credentials back to the attacker.

5. Self-Propagation: The worm uses any NPM authentication tokens it finds to spread itself further. For each stolen NPM_TOKEN, the malware automatically modifies the most popular packages available to that account, roughly the top 20 packages the developer maintains, injecting the same malicious code and then publishing a new infected version. In other words, each infected developer becomes a contagion point. Effectively, the worm replicates whenever an infected package is installed on a new machine.

   
   

In summary, the Shai-Hulud attack is a multi-stage supply-chain breach: (a) delivers a hidden payload via NPM; (b) hunts for tokens on the host (local secrets, CI tokens, cloud keys); (c) publishes stolen data publicly on GitHub; (d) installs sneaky workflows to capture even more data; (e) uses NPM tokens to inject itself into other packages. Because it combines credential theft with automated propagation, the impact multiplies rapidly once the worm is active. Removal of known bad package versions will slow the spread; eradication can only be achieved when all compromised environments (or new developer installing an old version) have been removed.

Comprehensive Build Protection with InvisiRisk

To secure supply-chain poisonings like Shai-Hulud, InvisiRisk provides a Build Application Firewall (BAF): a policy-driven layer around your CI/CD pipeline. Instead of only scanning source code, the BAF enforces rules and inspects actions during the build, stopping risky operations before they reach production. It not only prevents known critical vulnerable packages from entering a build, but it also watches the dependencies you already use and notifies you if something later turns risky.

Key advantages:

• Trusted source validation: Ensures builds only pull code from approved registries and SCM providers; unknown registries or untrusted repos are flagged or blocked.

Figure: InvisiRisk BAF blocking untrusted source.

• Real build protection: Observes build behavior and halts suspicious actions (for example, unauthorized put attempts initiated by build scripts). This is the network activity that creates a new repository with double encoded secret leaks in data.json file.

  

  Figure: InvisiRisk BAF blocking unauthorized actions.

• Secrets and traffic inspection: Scans outbound build requests (including full request payloads) for leaked secrets and blocks exfiltration attempts.

Response filters: Enforces limits on response file size, MIME type, and response status codes to catch odd downloads or redirect-based payload fetches. The unauthorized API calls to “api.github.com” can be a great telltale sign as shown by the response status code.

Figure: InvisiRisk BAF blocking unauthorized API calls.

• Proactive policy enforcement: Blocks known vulnerable or blacklisted package versions at build time, blocking the download of malicious code eliminating the risk of compromise.

• Safe failure and alerts: When a policy is violated, the build can be safely stopped, avoiding compromise and your team receives a clear alert describing which policy was triggered and why.

These controls turn your CI/CD pipeline into an active, real-time filter: instead of discovering poisoneddependencies after deployment, the BAF keeps them out of the build in the first place.

Build Security AI Agent: a second line of defense

Separate from the default policy rules, InvisiRisk’s Build Security AI Agent watches for build anomalies and behavioral outliers that policies might miss. It learns normal build and repository behavior for your org and raises high-confidence alerts on unusual activity such as:

• Creation of unexpected repositories (e.g., a suddenly appearing shai-hulud repository) from unusual action operations originating from build agents (unexpected PUT/CREATE actions or pushes to strange branches).

  

  Figure: Build Security AI Agent showing anomalous actions.

• Visiting Non-standard repositories that were accessed during the build.

  

  Figure: Build Security AI Agent showing non-standard host access.

When AI Anomalies flags an event, it complements the BAF policies: you get an early, human-readable signal of novel or evolving attack patterns so your team can respond (revoke tokens, block the offending registry, invalidate caches, rotate keys) before a threat can propagate further.

Build Visualization

This feature provides a clear visualization of all network activity during the build process. It shows exactly where each connection originates and highlights potential risks in real time. Anomalies, vulnerabilities, and policy violations are flagged instantly, making it easier to spot issues before they escalate. With this view, teams gain deeper insights into dependencies and security posture across their builds.

Figure: Build Visualization.

Bottom line: InvisiRisk’s BAF enforces defensive rules in the build pipeline (trusted registries/SCM, blocked packages, secret-leak prevention, response checks, git protections), and the Build Security AI Agent feature provides behavioral detection for novel, suspected worm-style activities. The defensive rules and the agent work together to stop supply-chain worms and credential-theft campaigns from spreading through your builds.