Inside Shai-Hulud's Maw: How The NPM Worm Exploits And Propagates

Introduction

In September 2025, researchers discovered “Shai-Hulud”, a self-replicating malware worm targeting the NPM ecosystem. This wasn’t just another piece of malware – at its core, it stole developer credentials, cloud tokens, and private repositories owned by the affected maintainers, then weaponized developer trust and automatically propagated itself and infected as many packages and system as possible.

Just 2 months later, in November 2025, a new version of the malware, dubbed “The Second Coming”, arrived with improved sophisticated techniques prepared to cause more damage.

What follows is a comparison of both versions of the malware, showcasing how it evolved and the differences between the two. Hopefully this will help you understand a bit more about malware, and the malicious intents behind this campaign.

If you’re more interested in IOCs and recommended mitigation strategies, check our original posts:

High-Level Comparison: Shai-Hulud original vs. Second Coming

Feature	Version 1	Version 2
Installation	Postinstall script	Preinstall script
Obfuscation	Simple minification	Multi-layered obfuscation
Data Harvesting	GitHub username + token GitHub secrets Npm username + token AWS secrets Google Cloud secrets TruffleHog output System Environment variables Host information – mainly about the Operating System architecture Exfiltration of all private/internal organization repositories the user has access to	GitHub username + token GitHub secrets Npm username + token AWS secrets Google Cloud secrets Azure Vault keys TruffleHog output System Environment variables Host information – not only about the OS, but also hostname and userinfo
Defense Evasion/Security Tampering	–	Attempts privilege escalation via docker container escape Attempts to stop systemd-resolved Flushes iptables
Persistence and Spread Mechanisms	Spreads to all packages of the infected user Injects a malicious GitHub Workflow in all the repositories that the user owns, collaborates, or is a member	Spreads to all packages of the infected user Injects a malicious GitHub Workflow in all the repositories that the user owns, collaborates, or is a member Installs a self-hosted GitHub runner that serves as a backdoor to the infected system
Fallback Mechanisms	–	Wipes all files in the user’s profile/home directory

The first wave of Shai-Hulud

The first observed instance of the malware infected packages with a “postinstall” script that automatically executed a “bundle.js” file containing the malicious code. The code itself was not hard to reverse engineer because it was only minified, meaning the code is presented in a single long line, where all whitespaces, tabs, and line breaks are removed, and variables and function names are usually shortened. This is easily reversible.

Note that this post contains screenshots of code captured during our investigation. Plain-text snippets are provided for accessibility, but be aware that the plain-text versions were created automatically using AI-enhanced OCR, and therefore may contain errrors.

package.json snippet for @ctrl/tinycolor with a highlighted postinstall script — Figure 1 – package.json for @ctrl/tinycolor with a postinstall script; after the attack

This malicious script then performed several actions in the background, the first one being credential harvesting for Shai-Hulud to exfiltrate later. It scanned the system for credentials, such as GitHub PATs, NPM tokens, and cloud provider keys (AWS and Google). If the operating system allowed it, it also deploy TruffleHog, a known secrets discovery software, to leak as many credentials as possible.

To explain in more detail, the malware contained different class modules for this purpose:

A class named “TruffleHogModule”, containing the necessary functions for checking the Operating System information, downloading the compatible binaries of Truffle Hug, installing it, and then scanning the file system for credentials.
A class named “GCPModule”, containing the necessary functions for connecting to the user’s Google Cloud account and harvesting its secrets.
A class named “AWSModule”, containing the necessary functions for connecting to the user’s AWS account and harvesting its secrets.
A class named “GitHubModule”, containing the necessary functions for harvesting the user’s GitHub token from the system, and later performing other actions related to the malware’s propagation and data exfiltration steps.

TypeScript class TruffleHogModule showing constructor logic and method stubs — Figure 2 – TruffleHogModule constructor and method stubs

TypeScript class GCPModule showing constructor with GoogleAuth and Secret Manager client setup — Figure 3 – GCPModule constructor and async method stubs

TypeScript class AWSModule showing constructor and AWS-related method stubs — Figure 4 – AWSModule constructor and async method stubs

TypeScript class GitHubModule showing token retrieval and Octokit initialization — Figure 5 – GitHubModule authentication logic and async method stubs

After having all the victim’s keys, Shai-Hulud proceeded to exfiltrate this data to the attacker. For this, it started by creating a new GitHub repository named “Shai-Hulud” – hence the name attributed to this campaign – with a file named “data.json” containing all user data base64 encoded. It further exfiltrated more secrets to a webhook (under “webhook.site”) controlled by the attacker(s), but this was done as part of the propagation mechanism of the malware.

JavaScript object ue collecting system info, environment variables, and module auth state — Figure 6 – Aggregating system, env, and module state

As a further exfiltration step, the malware went beyond stealing keys – it copied all private and internal repositories owned by the compromised maintainer’s organization and pushed them into new public repositories controlled by the attacker. The repos were given a “Shai-Hulud Migration” description. This is particularly interesting because it shows the attackers goal was to gather maximum data.

In the end, Shai-Hulud used sophisticated, automated propagation techniques to spread across packages and repositories:

It started to propagate itself by injecting the same malicious code to all packages the user has access to. This was done by the “NpmModule” class, and only in case the malware finds any NPM token during the credential harvesting step.
It also injected a malicious GitHub Workflow, named “shai-hulud-workflow.yml” in all the repositories that the user owns, collaborates, or is a member. This workflow exfiltrated the GitHub secrets from every repository accessible with the user’s PAT token and sent them to an attacker controlled webhook via our classic “curl”.

TypeScript class NpmModule showing constructor and package query methods — Figure 7 – NpmModule client initialization and API method stubs

How Shai-Hulud evolved into its “Second Coming”

The malware is now installed using the “preinstall” script, instead of “postinstall”. This makes sure that the malware is executed even if the compromised package for some reason fails to install, making its infection and spread more plausible to happen.

package.json for accordproject/concert-analysis with highlighted preinstall script — Figure 8 – an infected package.json with a preinstall hook

Now, before diving in, it’s important to note that this version of the malware was heavily obfuscated in comparison to the previous version. Obfuscation makes the code significantly harder to detect, analyze, and reverse engineer. If we look at the source code, it’s almost unreadable because variable names, function names, and even function calls are replaced with meaningless hexadecimal strings. As a result, please note that the function names and variables you’ll see throughout this blog have been renamed to our liking to make the code easier to understand.

Obfuscated JavaScript function with mangled identifiers and stream/blob logic — Figure 9 – Example of an obfuscated JavaScript function with stream and blob handling

One particularity of this version is that before it does anything, the malware starts by attempting privilege escalation and tampering with the security of the network in Linux systems. This was not part of the first campaign. It now attempts to stop systemd-resolved and modify network settings by flushing iptables if running as root or with passwordless sudo.

JavaScript function stopping systemd-resolved and flushing iptables output chains — Figure 10 – Network configuration tampering via shell calls

Most of its data harvesting steps, although different in structure, share the same logic to the previous version. It harvests host information, NPM tokens, GitHub token, and Cloud Provider secrets, but this version collects a significantly broader set of credentials and host data:

It now expands its host profiling by getting the hostname of the operating system, and userinfo data, which contains the user/group IDs, the username of the logged-in user, the home directory and the default shell.
It targets more cloud providers and attempts to harvest the user’s Azure vault access keys.

JavaScript aggregating system info, GitHub auth state, environment variables, and cloud secrets — Figure 11 – Harvesting system metadata, GitHub auth data, env vars, and cloud secrets

Exfiltration still relies on the same method of creating a public GitHub repository where all the data is stored. This time, however, the repo gets the description “Sha1-Hulud: The Second Coming”. Additionally, instead of relying on a single base64 encoded file, the uploaded files are now organized into:

contents.json – containing the system and user information
environment.json – containing the system environment variables
cloud.json – containing the cloud provider secrets
truffleSecrets.json – containing the trufflehog findings
actionsSecrets.json – containing the secrets found via GitHub Actions workflows

Another notable difference is that instead of extracting GitHub secrets to an attacker controlled webhook, using the injected malicious GitHub workflow, the malware now harvests those in real time and saves them into the respective file actionsSecrets.json.

JavaScript committing JSON files with system, environment, and cloud data to a Git repository — Figure 12 – Writing collected data to repository files for exfiltration

JavaScript function running TruffleHog scan and committing results to a repository — Figure 13 – Extracting secrets with TruffleHog and committing results to Git for exfiltration

JavaScript function extracting GitHub Actions secrets via API and committing them to a repository — Figure 14 – Extracting GitHub Actions secrets and writing them to the repo for exfiltration

Finally, the most significant difference is how the malware is much more dangerous when compared to the first version. It has new 2 main features:

A destructive fallback mechanism: If unable to obtain a GitHub or NPM token, the script attempts to shred and delete all files in the user’s profile/home directory.
Backdoor installation: Establishes persistence by installing a self-hosted GitHub runner that acts as a backdoor. The runner is registered to the created repository, meaning the infected machine can execute GitHub Actions jobs from that repository. In other words, the attacker who controls the repo can now run arbitrary commands on the infected machine.

JavaScript logic handling missing GitHub authentication and invoking destructive OS commands — Figure 15 – Fallback path when Git/GitHub auth fails, including OS-level commands

JavaScript createRepo method installing a self-hosted GitHub Actions runner across Linux, Windows, and macOS — Creating a repo and installing a self-hosted GitHub Actions runner

Supply Chain Security has to level up

These steps show how a single compromised package became a multiplier – now imagine the actual propagation of the malware occurring across thousands of NPM packages or even spreading to other ecosystems as it was already observed with this campaign. Due to automatic mirroring of NPM packages being rebuilt for Maven, some infected packages were automatically rebuilt in the Maven ecosystem. The result is a widespread supply chain incident with serious consequences for projects and users that depend on the registry. This campaign reminds us how fragile the ecosystems we trust are and forces us to rethink how to secure open-source ecosystems.

It also is a lesson to defenders about the importance of not only being able to detect and respond to malicious open-source pacakges, but also to procatively defend against malicious packages, blocking them before they’re installed in order to avoid being infected by preintall and postinstall scripts.

NPM’s response to Shai-Hulud has led them to take some steps to make such attacks at least more complicated for adversaries to conduct. For details, read their official blog post on their upcoming security measures.

Tags:

Malicious Code

Malicious Package

Malware

Open-Source Analysis

Open-Source Supply Chain

Shai-Hulud

supply chain attack

Supply Chain Security

Worm

Inside Shai-Hulud’s Maw: How The NPM Worm Exploits And Propagates

Introduction

High-Level Comparison: Shai-Hulud original vs. Second Coming

The first wave of Shai-Hulud

How Shai-Hulud evolved into its “Second Coming”

Supply Chain Security has to level up