BM
Bhavik Mehta
Contact Me
Back to Blog
{ 07 } — Engineering

npm Supply Chain Attacks: What Happened and What to Do

2026-05-1213 min read
#Security#npm#JavaScript#Supply Chain#DevOps

What Is Happening With npm Right Now

Over 416 npm package versions were compromised in a single attack wave that finished two days ago. This is not an isolated incident. Since September 2025, the JavaScript ecosystem has been hit by a coordinated, evolving series of supply chain attacks that have touched packages with billions of weekly downloads combined: chalk, debug, axios, TanStack Router, Mistral AI, and hundreds more.

If your project runs JavaScript and installs packages from npm, this is not a theoretical risk. It is something that may have already run on your developer machine, in your CI pipeline, or inside your production environment. This post breaks down every major attack wave, explains how they work in plain terms, lists all known affected packages, and walks through exactly what to check and fix in your repository today.

What Is a Supply Chain Attack

A supply chain attack does not break into your code. It breaks into the code your code depends on.

When you run npm install, npm downloads packages written by other developers. You trust those developers not to put malicious code in their packages. A supply chain attack works by compromising one of those trusted developers, either by stealing their credentials, tricking them into clicking a phishing link, or abusing the automated systems that publish packages on their behalf. Once the attacker controls a trusted maintainer account, they push a new version of the package with malicious code embedded. Your npm install downloads it automatically and silently.

The reason this is so dangerous is the transitive dependency problem. Your project might not directly list chalk or debug in your package.json, but dozens of packages you do install depend on chalk or debug internally. When a foundational package gets compromised, the infection spreads to everything above it in the dependency tree. You are affected even though you never made a choice to install the compromised package directly.

Falling dominoes showing how one phished npm maintainer triggered a cascade compromising 500 plus packages and YOUR PROJECT


The Full Timeline: September 2025 to May 2026

Timeline of npm supply chain attacks from Sept 2025 to May 2026 across five waves including chalk, axios, and TanStack compromises

September 2025: The Original Shai-Hulud Attack

The first major attack wave started with a phishing campaign targeting Josh Junon (npm username: qix), the maintainer of several foundational JavaScript packages. Attackers created a fake domain designed to look like the real npmjs.com site, tricked Josh into entering his credentials, and then used his compromised account to push malicious versions of 18 packages.

Packages directly compromised in September 2025:

  • chalk
  • debug
  • ansi-styles
  • strip-ansi
  • supports-color
  • 13 additional packages in the same dependency cluster

These 18 packages collectively receive over 2.6 billion weekly downloads. Almost every JavaScript project on the planet depends on at least one of them.

The malicious code was not just a static payload sitting in one package. It was a self-propagating worm that researchers named Shai-Hulud. After executing on a developer machine or CI runner, the worm scanned for other npm packages the compromised maintainer account had publish rights to, then automatically published new malicious versions of those packages as well. Within 24 hours of the initial compromise, over 180 additional packages were infected. Within a week, the count exceeded 500.

The payloads were designed to steal cloud service tokens, GitHub credentials, npm authentication tokens, and intercept cryptocurrency transactions by replacing wallet addresses silently before they were transmitted.

November 2025: The Second Wave

Two months later, a second Shai-Hulud campaign launched targeting a different set of maintainer accounts but using the same worm propagation technique. Researchers dubbed this wave "The Second Coming." The worm spread to a new set of packages that had not been affected in September.

March 2026: Axios Is Compromised

On March 30, 2026, axios, the JavaScript HTTP client with over 100 million weekly downloads, was compromised. Two specific versions contained malicious code:

  • axios@1.14.1
  • axios@0.30.4

The malicious versions deployed a cross-platform remote access trojan (commonly called a RAT). A RAT gives the attacker full remote control of any machine that executed the infected package. Both versions were pulled from npm within three hours, but any developer machine or CI pipeline that ran npm install during that window was exposed.

Microsoft's security team linked the attack to UNC1069, a North Korean state-sponsored threat actor also tracked as part of the Lazarus Group, which has been financially active targeting the software supply chain since at least 2018.

Safe versions of axios to pin:

  • 1.14.0 or lower (for the 1.x branch)
  • 0.30.3 or lower (for the 0.x branch)

If your CI pipeline installed axios@1.14.1 or axios@0.30.4 at any point, treat every credential accessible from that environment as compromised and rotate immediately.

This incident is structurally similar to the Vercel OAuth breach earlier in 2026, where third-party integrations became the attack surface rather than first-party systems. The pattern of compromising trusted intermediaries is consistent and deliberate.

March 2026: React Native Packages

On March 16, 2026, StepSecurity Threat Intel detected malicious releases in two React Native packages:

  • react-native-international-phone-number
  • react-native-country-select

Combined, these packages have over 130,000 monthly downloads.

April 2026: SAP Developer Packages (Mini Shai-Hulud)

Between April 29 and April 30, 2026, a new variant of the Shai-Hulud worm targeted SAP developers. Four SAP-related npm packages were compromised. The payloads were specifically designed to harvest developer credentials, GitHub tokens, npm tokens, GitHub Actions secrets, and cloud secrets from AWS, Azure, GCP, and Kubernetes environments.

April 2026: 36 Fake Strapi Plugin Packages

Security researchers also discovered 36 malicious packages on npm that were disguised as Strapi CMS plugins. These were not updates to legitimate packages but entirely new packages with names chosen to look similar to real Strapi plugins (a typosquatting attack). Their payloads exploited Redis and PostgreSQL instances to deploy reverse shells, harvest credentials, and establish persistent backdoors on compromised systems.

May 11, 2026: TanStack, Mistral AI, and More (Active Right Now)

The most recent and most technically sophisticated attack happened on May 11, 2026. Between 19:20 and 19:26 UTC, an attacker published 84 malicious versions across 42 @tanstack/* packages on npm. The attack window was only six minutes long.

The attacker chained three separate weaknesses in GitHub Actions:

Pwn Request: The repository used a pull_request_target workflow trigger. This trigger runs in the context of the base repository, meaning it has access to secrets. But it also checks out the code from the incoming pull request, even when that pull request comes from a fork. If the PR code is malicious, it can read those secrets.

GitHub Actions cache poisoning: Shared GitHub Actions cache entries were poisoned across the boundary between the forked repository and the base repository, allowing the attacker to inject malicious build artifacts.

OIDC token extraction: The attacker extracted a live OpenID Connect token from the GitHub Actions runner process memory at runtime. This token granted authenticated publish rights to npm without the attacker ever needing a stolen password or phishing anyone.

This final technique is particularly alarming. The attacker did not need credentials. They abused a legitimate authentication flow in a way that made the malicious packages appear to have valid cryptographic provenance attestation (SLSA Build Level 3). Automated security tools that check whether packages are properly signed and attested would have seen these packages and marked them as legitimate.

Confirmed compromised TanStack packages (84 malicious versions across 42 packages, all scoped under @tanstack):

  • @tanstack/react-router
  • @tanstack/router-core
  • @tanstack/router-plugin
  • @tanstack/start-server-core
  • @tanstack/start-client-core
  • 37 additional @tanstack/* packages (full list in the TanStack postmortem linked in references)

TanStack packages confirmed clean:

  • @tanstack/query* (React Query and all variants)
  • @tanstack/table*
  • @tanstack/form*
  • @tanstack/virtual*
  • @tanstack/store

Beyond TanStack, the same attack wave spread to packages from @mistralai, @uipath, @squawk, @tallyui, @beproduct, @draftlab, @draftauth, @taskflow-corp, @tolka, and several unscoped packages. Aikido recorded 373 compromised package-version entries. Socket tracked 416 compromised artifacts across npm and PyPI. Endor Labs confirmed over 160 compromised npm packages in this wave alone. Combined cumulative downloads across all affected packages exceeded 518 million.


What Gets Stolen

Across all the attack waves described above, the payloads are consistently designed to steal the same categories of information:

  • AWS, GCP, Azure, and Kubernetes credentials and access tokens
  • GitHub personal access tokens and organization tokens
  • npm authentication tokens (which allow publishing additional packages, spreading the attack further)
  • SSH private keys accessible on the compromised machine
  • Environment variables from .env files, including database connection strings and third-party API keys
  • Cryptocurrency wallet addresses and private keys (with some payloads replacing outgoing wallet addresses silently)
  • CI/CD secrets stored in GitHub Actions, CircleCI, and similar systems

The compounding danger is the npm token theft. When an attacker steals your npm publish token, they can compromise packages your own organization publishes, turning your packages into the next vector for the worm.


How to Check If Your Project Is Affected

Step 1: Check Your Lockfile

Your package-lock.json or yarn.lock records the exact version installed. If the version in your lockfile matches a known malicious version and the lockfile was generated during an attack window, your environment was exposed.

Key attack windows:

  • TanStack (May 2026): 2026-05-11T19:20Z to 2026-05-11T19:26Z
  • Axios (March 2026): 2026-03-30 (the compromised versions were live for approximately three hours)
  • September 2025 initial wave: September 15 through the end of September 2025

Step 2: Run npm audit

npm audit

This checks your installed packages against the npm advisory database. Known malicious versions are flagged here. However, the advisory database lags behind active attacks by hours to days, so do not rely on this alone.

Step 3: Use a Dedicated Scanner

Several security tools maintain real-time databases of compromised packages:

# Socket - real-time threat detection
npx socket scan
 
# Snyk - vulnerability database
npx snyk test

Aikido Security also maintains a free web-based checker for Mini Shai-Hulud affected packages.

Step 4: Check Your CI Logs

If your CI pipeline ran npm install or npm ci during any of the attack windows, review the runner logs for:

  • Outbound network connections to filev2.getsession.org or api.masscan.cloud (confirmed C2 infrastructure for the TanStack attack)
  • Any unexpected npm publish commands that your own workflows did not trigger
  • Subprocesses spawned from within the node package installation step

What to Do If You Were Affected

Rotate Every Credential Immediately

This is not optional and cannot wait. If a compromised package ran on a machine or in a CI environment, every credential that environment could reach must be rotated. That includes:

  • AWS IAM access keys and session tokens
  • GCP service account keys
  • GitHub personal access tokens and deploy keys
  • npm authentication tokens (revoke them from your npm account settings page)
  • SSH private keys on that machine
  • Any API keys in environment variables
  • Database connection strings
  • HashiCorp Vault tokens
  • Kubernetes service account tokens

You cannot know precisely what was exfiltrated. The only safe assumption is that all of it was.

Pin a Safe Package Version

Downgrade any compromised package to the last known-safe version and pin it exactly:

{
  "dependencies": {
    "axios": "1.14.0",
    "@tanstack/react-router": "1.120.15"
  }
}

Then do a clean reinstall:

rm -rf node_modules package-lock.json
npm install

Check If Your Published Packages Were Affected

If your organization publishes npm packages, and the compromised version ran in the same CI pipeline that publishes those packages, your published packages may also be infected. Check your package publish history for unexpected versions and pull any that were released from a potentially compromised CI run. Notify your package users.


How to Reduce Risk Going Forward

Use npm ci in CI Pipelines

npm ci installs exactly what is in your lockfile and fails if there is any discrepancy. It will not silently upgrade a package to a newer version. Make sure your lockfile is committed to version control and that your CI pipeline runs npm ci rather than npm install.

# In your CI pipeline
npm ci

Fix Your GitHub Actions Workflows

The TanStack attack succeeded by exploiting pull_request_target. If your repository uses this trigger, audit it now:

# Dangerous: pull_request_target with code checkout
on:
  pull_request_target:
jobs:
  build:
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      # anything that runs the checked-out code here can read secrets

The pull_request_target trigger runs with access to your repository secrets but executes code from the pull request. If you need to run checks on fork PRs, use the pull_request trigger instead, which does not have access to secrets. If you genuinely need both, scope secret access as narrowly as possible and never run untrusted code from a fork in a pull_request_target context.

Enable npm Two-Factor Authentication

Every npm account with publish rights to any package must have two-factor authentication enabled. The September 2025 attack started with a phishing campaign that worked because the target account had only a password. npm now supports passkeys. Use them.

You can enforce 2FA across your whole npm organization from the organization settings page.

Use a Dependency Security Scanner

Integrate a scanner into your pull request workflow so new dependency additions are checked automatically:

  • Socket integrates as a GitHub App and comments on PRs when a new dependency has known supply chain risk indicators
  • Snyk has a similar GitHub integration
  • Dependabot (built into GitHub) opens automated PRs for version bumps, keeping updates deliberate and reviewed rather than silent

Consider Lockfile-Only Deployments

In production, never run npm install from a fresh package.json. Always deploy from a committed lockfile using npm ci. Better yet, ship a pre-built artifact (a Docker image, a Vercel build output) rather than installing packages in the production environment at all. If nothing installs at deploy time, a compromised package version cannot affect your production environment even if it made it past your CI checks.


Where to Find the Full Affected Package Lists

The attack surface for the May 2026 wave is still being mapped. These sources are updated in near real-time:

  • TanStack official postmortem contains the complete list of every confirmed affected and clean @tanstack/* package
  • Aikido Security lists all 373 compromised package-version entries for Mini Shai-Hulud (May 2026 wave)
  • Palo Alto Networks Unit42 maintains a running tracker of all known compromised packages (last updated May 1, 2026)
  • CyberSec Guru maintains a full list specifically for Mini Shai-Hulud affected packages
  • Red Hat Customer Portal has a tracked list for the original September 2025 attack
  • CISA has published official advisories for both the September 2025 widespread compromise and the March 2026 Axios incident
  • JFrog maintains a list for the largest-scope packages in history across all waves

For a broader look at how these kinds of supply chain risks connect to the security vulnerabilities in modern developer tooling, take a look at my projects section to see the open source tooling I use and how I think about dependency hygiene in practice.


References


Disclaimer: This blog post was researched, written, and published with the assistance of AI. The content reflects general information on the topic and does not represent the personal opinions, beliefs, professional advice, or endorsements of Bhavik Mehta. Nothing in this post should be construed as legal, financial, technical, or professional advice. Readers should independently verify any information before acting on it.