Shai-Hulud NPM supply chain attack: a new generation of self-propagating threats

The anatomy of the Shai-Hulud worm

The Shai-Hulud attack is not a simple, brute-force affair. It operates through a multi-stage process, beginning with a malicious payload that is meticulously injected into popular npm packages. The attackers seeded a significant number of packages with the malware themselves, likely using npm tokens that were previously stolen from the s1ngularity/Nx attack. Evidence for this comes from user metadata in the archives of the initial 49 packages, which bore the telltale fingerprint of a Kali Linux distribution—a tool often used by security professionals and threat actors, not typical developers.

At its core, the malware is a sophisticated, minified JavaScript file named bundle.js, which is typically over 3MB in size. This file is not a simple script; it's a modular, multi-stage engine that uses Webpack chunks to organize its various functions. It gets executed automatically after a compromised package is installed, typically through a hijacked postinstall script embedded in the package’s package.json file. The attackers would download a package's tarball, inject their malicious script, repack the archive, and republish it as a new version. This process is so subtle that downstream users can easily install a compromised version without noticing anything amiss.

Once executed on a victim's machine, the malware's modular design kicks into action. The core functionalities of the payload include:

• System and credential reconnaissance: The malware first performs an initial reconnaissance of the host system. It collects a system profile, including the operating system and architecture. It then proceeds to dump the entire process.env, capturing a wide range of sensitive environment variables such as GITHUB_TOKEN, NPM_TOKEN, AWS_ACCESS_KEY_ID, and AWS_SECRET_ACCESS_KEY.

• Targeted cloud credential harvesting: Shai-Hulud specifically targets credentials for major cloud providers. Using its own embedded cloud SDKs (software development kits) and API wrappers, it attempts to enumerate and access secrets from services like AWS Secrets Manager and Google Cloud Platform (GCP) Secret Manager. It can even probe cloud metadata endpoints to capture ephemeral IAM (identity and access management) credentials, which can grant even higher privileges. The malware is designed to fail silently on permission errors, making its activity even harder to detect.

• Filesystem secret scanning: To maximize its haul, the malware repurposes open-source tools like TruffleHog, a legitimate secret-scanning tool. It spawns a process to scan the entire filesystem for high-entropy secrets and sensitive files, such as ~/.aws/credentials or other configuration files that may contain hard-coded credentials. This aggressive scanning expands the scope of the data theft far beyond just environment variables.

It's important to note that the malware was observed to be AI-generated in some variants, suggesting that the threat actors may have used tools like Claude, Gemini, or Q to assist in writing the malicious code. The design also assumes a Linux or macOS execution environment, as it includes a check to deliberately skip Windows systems.

Persistence, exfiltration, and the attack's unrelenting spread

The true danger of the Shai-Hulud attack lies in its ability to not only steal data but also to replicate and establish persistence. After harvesting credentials, the worm immediately puts them to use to spread further and ensure continued access.

Data exfiltration via GitHub and Webhooks

The stolen data is not just sent to a single location; the attackers used a dual-pronged exfiltration strategy:

• Public GitHub repositories: The malware uses a stolen GitHub Personal Access Token (PAT) to create a new public repository under the victim's account. This repository is typically named Shai-Hulud and contains a dump of the harvested secrets, often within a file named data.json. The data is then double-encoded with Base64 to make it less readable to casual observers. This method is particularly effective as it blends in with normal developer activity and bypasses many traditional security controls. Security researchers observed hundreds of such repositories appearing on GitHub, demonstrating the scale and ongoing nature of the attack.

• Webhook endpoints: The malware also attempts to exfiltrate data to a hard-coded webhook endpoint, specifically hxxps://webhook[.]site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7. However, due to the high volume of activity, the webhook platform eventually deactivated the account, rendering this method non-functional. Despite this, secrets were still being exposed in the workflow logs on GitHub, which provided a new avenue for attackers to access sensitive data.

The self-propagating mechanism

With a valid npm token in hand, the malware becomes a true worm. It leverages the NpmModule.updatePackage function to query the npm registry for other packages owned by the compromised maintainer. It can retrieve up to 20 packages at a time. The worm then automatically creates and publishes new, malicious versions of each of these packages. This is done by injecting the malicious bundle.js script and adding a postinstall command to the package.json file. This automated process creates a cascading effect, where each infected package serves as a new distribution vector, infecting new hosts and stealing their credentials to repeat the cycle. This "cascading compromise" turns a single successful breach into an exponential threat that spreads at the speed of CI/CD pipelines.

Establishing persistence

Beyond immediate data theft, the malware works to establish long-term persistence. It uses a stolen GitHub PAT to push a new GitHub Actions workflow, often named shai-hulud-workflow.yml, into all accessible repositories. This workflow is designed to trigger on push events and exfiltrate more secrets from the CI/CD pipeline itself using the expression ${{ toJSON(secrets) }}.

Additionally, the worm exhibits another malicious behavior, reminiscent of the s1ngularity attack: the "migration" of private repositories. The malware uses a script to clone private repositories and republish them as public repositories under an attacker-controlled user. These new public repositories are named with a -migration suffix and the description "Shai-Hulud Migration". This tactic is likely an attempt to gain access to secrets that are hard-coded in the source code or simply to steal proprietary code. The malware creates the repo as private and then immediately flips its visibility to public, leaving two observable events in GitHub's audit logs: a CreateEvent followed by a PublicEvent. A search for these repositories on GitHub yielded close to 700 results, indicating the massive scale of this particular facet of the attack.

The link to the s1ngularity/Nx attack: a dangerous trilogy

The Shai-Hulud attack is deeply intertwined with the s1ngularity supply chain attack, which targeted the widely used Nx build system package in late August 2025. Understanding the s1ngularity attack provides crucial context for Shai-Hulud.

In the s1ngularity attack, threat actors compromised the nrwl/nx repository by exploiting a flawed GitHub Actions workflow. The workflow, which was intended to validate pull requests, ran with elevated permissions and was vulnerable to code injection through unsanitized pull request titles. This allowed attackers to execute arbitrary commands, exfiltrate the team's npm token to a webhook, and publish malicious versions of the Nx package.

The s1ngularity malware was also a data-gathering payload, but it had its own unique characteristics:

• Malware payload: It used a malicious telemetry.js file triggered by a post-install script. The payload specifically targeted Linux and macOS systems and searched for sensitive files, including cryptocurrency wallets, SSH keys, and .env files.

• AI-powered reconnaissance: The malware notably leveraged AI command-line tools like Claude, Gemini, and Q, prompting them with dangerous flags (--dangerously-skip-permissions, --yolo) to aid in reconnaissance and steal filesystem contents. This was a novel approach at the time.

• Exfiltration: Stolen data was double and triple-Base64 encoded and uploaded to publicly accessible attacker-controlled victim repositories named s1ngularity-repository.

• Persistence: The malware attempted to achieve persistence and a denial-of-service effect by appending sudo shutdown -h 0 to the user's ~/.bashrc and ~/.zshrc files.

• Repository exposure: A second phase of the s1ngularity attack involved using the stolen GitHub tokens to turn private repositories public and rename them to a pattern like s1ngularity-repository-#5letters#. Over 5,500 private repositories from over 400 users were impacted.

The functional overlap between the two campaigns is significant. Both attacks:

• Targeted popular open-source packages with millions of weekly downloads.

• Focused on collecting environment variables and secret information.

• Leveraged user-owned GitHub accounts for data exfiltration.

• Exposed private repositories by making them public.

However, Shai-Hulud represents an escalation. As one security researcher noted, the attackers behind Shai-Hulud had likely been "sitting on" the credentials stolen from the s1ngularity attack, waiting for the opportune moment to launch a new, more automated campaign. The fact that Shai-Hulud includes a self-propagating mechanism—which was not present in s1ngularity—is what makes it a far more dangerous threat. The consistent and refined nature of these attacks shows that the threat actors are learning and adapting, using each successful compromise as a blueprint for the next. The keys to the kingdom have been leaked, and as one researcher aptly put it, this may be just the beginning of a trilogy.

The scope of the attack: packages, users, and the ecosystem at large

The Shai-Hulud attack impacted a wide range of packages and developers, from high-profile maintainers to students and tech leads. The sheer number of packages involved, coupled with the worm's self-propagating nature, created a massive attack surface that is difficult to fully quantify.

Some of the most popular packages affected included:

• @ctrl/tinycolor (with over 2.2 million weekly downloads)

• ngx-bootstrap (300k weekly downloads)

• ng2-file-upload (100k weekly downloads)

The attack also compromised multiple packages belonging to the @crowdstrike npm account, published by crowdstrike-publisher. This shows that the worm was not limited to individual developers but could also infect packages owned by major security vendors.

The list of compromised packages and their versions is extensive. To help developers and organizations identify if they were impacted, we have compiled a comprehensive table of all known affected packages and the malicious versions that were published.

The impact of this attack is significant. Beyond the immediate theft of secrets, which can lead to data theft, cryptomining, or the deletion of production environments, the attack's self-propagating nature leaves a trail of compromised accounts and potentially exposed source code. A security firm analyzed the leaked data and found a total of 278 secrets, with 90 collected from local systems and 188 from malicious workflows. The most leaked secrets were GitHub tokens, npm tokens, and AWS keys, highlighting the primary targets of the campaign.

What developers and organizations can do: a few recommendations

The Shai-Hulud attack is a wake-up call for the entire open-source ecosystem. The incident demonstrates that software supply-chain risk is no longer just about vulnerabilities in code but also about compromised identities and trusted automation. Since the malware spreads at the speed of CI/CD, leaving very little time for detection and remediation, a strong and proactive defense is crucial.

Here are actionable recommendations to mitigate risk from this attack and similar threats:

Immediate containment and remediation

• Remove malicious packages: First and foremost, audit your project dependencies and remove or downgrade any affected packages. You can use tools like npm audit to identify vulnerable versions. After removing the packages, clear your cache by running npm cache clean --force and then reinstall a clean, known-good version.

• Assume compromise and rotate credentials: Any machine or CI runner that installed an affected package should be considered fully compromised. You must immediately revoke and regenerate all potentially exposed credentials, including npm tokens, GitHub PATs, SSH keys, and all cloud API keys.

• Audit GitHub accounts and logs: Review your GitHub account for any suspicious activity. Look for:

  • Newly created public repositories named "Shai-Hulud".

  • Private repositories that were suddenly made public and have the description "Shai-Hulud Migration" with a -migration suffix.

  • New branches named "shai-hulud."

  • Unexpected commits or modifications to GitHub Actions workflow files, specifically looking for shai-hulud.yml or shai-hulud-workflow.yml.

Long-term security hardening

• Enforce strong authentication: Mandate the use of multi-factor authentication (MFA) on all critical developer platforms, including GitHub and npm. Where possible, use hardware security keys for the highest level of protection.

• Implement the principle of least privilege: Limit the scope of your tokens. Use short-lived, narrowly scoped tokens that have only the permissions they need for their specific task. For example, a token used for CI/CD should not have broad administrative or publishing rights if it's not strictly necessary.

• Harden CI/CD pipelines: Treat your build environments as potential targets. Use ephemeral runners that are destroyed after each build to prevent malware from establishing persistence. Restrict outbound network connections from your build pipelines to only necessary domains.

• Pin dependencies and monitor for anomalies: Instead of allowing floating or automatic upgrades (^ or ~), pin all dependencies to a specific, known-good version in your package.json or package-lock.json file. This prevents an automated build from unknowingly pulling in a newly compromised release. Continuously monitor logs for unusual npm publish events or unexpected child processes, which could indicate a malicious script is running.

• Use advanced security solutions: The rise of these sophisticated attacks, which exploit identities and trusted automation, calls for a new approach to security. Solutions that offer software composition analysis (SCA) and software bill of materials (SBOM) can help you continuously track and manage your dependencies, identify vulnerable packages, and block malicious ones. These tools help you see what's in your software and stop risky changes before they enter your pipeline. At Fluid Attacks, our comprehensive Continuous Hacking solution includes automated AST and PTaaS, and we also provide SCA, including SBOM, to help companies continuously track and manage their dependencies, identify vulnerabilities, and proactively protect their software supply chain. We invite you to start our 21-day free trial right now.

Fluid Attacks customers can quickly determine if their applications are exposed to these vulnerable packages. Just go to the Inventory section and filter the Packages table by component name:

Conclusion: a turning point for supply chain security

The Shai-Hulud attack is a watershed moment for software supply chain security. It signifies a shift from isolated, one-time compromises to automated, scalable, and self-propagating threats. This new generation of attacks, which leverages stolen credentials to fuel a viral spread, leaves organizations with little to no margin for slow detection and remediation.

This incident, much like the wallet-drainer attack that preceded it, underscores a critical truth: our entire digital ecosystem depends on the security of the open-source supply chain. The rapid response from security researchers and the developer community in this case is a testament to the collaborative spirit that underpins open-source software. However, it also highlights the urgent need for organizations to move beyond traditional security models and embrace a proactive, continuous approach to protecting their software supply chain. By implementing robust security practices, leveraging modern tools, and staying vigilant, we can collectively meet this escalating challenge and secure our shared digital future.