DEV Community

Cover image for Supply Chain Attacks Aren't Just a Big Library Problem — Here's What You Can Do Today
LuzAramburo
LuzAramburo

Posted on

Supply Chain Attacks Aren't Just a Big Library Problem — Here's What You Can Do Today

#javascript #cybersecurity #npm #webdev

In May 2026, a worm called Shai-Hulud compromised 42 TanStack packages — including @tanstack/react-router, a library sitting in millions of JavaScript projects. It was live for about 3 hours. That was enough. If you installed dependencies that day, you may have been affected without knowing it. This post isn't for the people who maintain those libraries. It's for the rest of us — the developers who just use them.

"Fun fact" 1
It was live ~3 hours. @tanstack/react-router alone gets 12.7 million weekly downloads. Meaning that it had ~225K downloads in the ~3 hour window — just for react-router. That's one package. The attack hit 42 @tanstack/* packages total.

Supply chain attacks used to feel like someone else's problem. A big library gets compromised, the maintainers fix it, life goes on. The Shai-Hulud worm changed that framing. It spread automatically to every package its victims maintained, turning regular developers into unwilling distributors of malware. Here's what happened, and what you can do today to reduce your exposure.

What happened?

  1. The workflow used pull_request_target, which runs with the base repo's trusted permissions — including access to secrets and a build cache shared with the real release pipeline.

  2. But it also checked out and executed the fork's code for benchmarking purposes. That's the dangerous mix: a stranger's code running with your own repo's trust.

  3. The attacker didn't need to steal anything immediately. They just poisoned the shared cache and waited. Hours later, the legitimate release pipeline ran, picked up the tampered cache without knowing it, and published the malicious packages itself — using TanStack's own valid credentials.

The key insight: the misconfiguration wasn't obvious. The benchmarking intent was reasonable; the mistake was not realizing that pull_request_target + "run the PR's code" is always a dangerous combination regardless of what you're trying to do with it.

"Fun fact" 2
The worm had a dead-man's switch. It planted a background service that polled api.github.com/user with the stolen GitHub token every 60 seconds. If the token was revoked — meaning GitHub returned a 40x response — the service triggered rm -rf ~/, wiping the user's entire home directory. You had to disable and remove the monitor service before revoking any credentials

The good news

Th pull_request_target Pwn Request specifically requires a public repo where strangers can open PRs.

The bad news

That said, the other parts of this attack (cache poisoning between workflows, OIDC token over-scoping) can still apply to private repos if your GitHub Actions workflows have similar misconfigurations

So far this sounds like a problem for library maintainers. It isn't. You don't need to maintain a library with millions of downloads to be exposed. You just need to run npm install on the wrong day at the wrong time. The moment a compromised package lands in your node_modules, you're part of the chain too.

"Fun fact" 3
Other affected libraries were @mistralai/mistralai, @uipath, @draftlab/auth, @draftlab/db, @draftauth/client, @squawk, safe-action, cmux-agent-mcp, nextmove-mcp, ts-dna, cross-stitch, and more

How to prevent similar incidents?

min-release-age & ignore-scripts

NPM — .npmrc 

min-release-age=7
ignore-scripts=true
Enter fullscreen mode Exit fullscreen mode
  • min-release-age=7 blocks packages published less than 7 days ago
  • ignore-scripts=true prevents lifecycle scripts like preinstall/prepare from running on install — which is exactly the vector the malicious optionalDependency used.
  • ⚠️ npm CLI v11 is required. Upgrade to Node 24, or manually install npm v11.

pnpm (10.16) — pnpm-workspace.yaml 

minimumReleaseAge: 10080  # minutes — 7 days
Enter fullscreen mode Exit fullscreen mode
  • minimumReleaseAge is on by default, it uses 1 day
  • Requires version 10.16 to avoid a bug that ignored this config.
  • ignore-scripts: pnpm v10 stopped running preinstall/postinstall scripts by default

Yarn Classic

  • ❌ min-release-age — not available. No equivalent exists in v1.
  • yarn install --ignore-scripts exists but only as a CLI argument

Yarn Berry (v2+) — .yarnrc.yml 

npmMinimalAgeGate: 10080   # minutes — 7 days
enableScripts: false        # ignore-scripts equivalent
Enter fullscreen mode Exit fullscreen mode
  • ⚠️ Requires Yarn 4.10 and applies globally with no way to scope it

Enforce the right versions with engines in package.json

All these protections depend on developers running the right version of their package manager. A simple way to make that explicit is the engines field in package.json:

{
  "engines": {
    "node": ">=22.0.0",
    "npm": ">=11.0.0"
  }
}
Enter fullscreen mode Exit fullscreen mode

This won't block anything on its own — it's just a warning by default. To make it fail loudly, add this to .npmrc:

engine-strict=true
Enter fullscreen mode Exit fullscreen mode

With that in place, anyone running an older npm version will get an error instead of silently skipping min-release-age protection.

⚠️ Use engine-strict=true carefully. It will cause install failures anywhere the version requirements aren't met — including CI pipelines, Docker builds, or teammates' machines that haven't upgraded yet. Make sure your entire environment is aligned before enabling it, otherwise it can block legitimate work.

For pnpm you can do the same in package.json, and it's respected out of the box without extra config:

{
  "engines": {
    "pnpm": ">=10.16.0"
  }
}
Enter fullscreen mode Exit fullscreen mode

It's a small addition but it closes the gap between "we have this config" and "we know everyone on the team is actually running it."

What does this mean for Docker?

If you're using npm ci in your Dockerfile — which you should — you're already covered. npm ci installs exactly what's in package-lock.json, with no dependency resolution. No new versions are fetched, so there's nothing for min-release-age to gate.

The protection happens upstream, on the developer's machine or CI pipeline when the lockfile is generated. As long as min-release-age is configured there, your Docker builds inherit that safety automatically.

# No extra config needed — npm ci uses the lockfile
RUN npm ci
Enter fullscreen mode Exit fullscreen mode

The one thing worth calling out: this only holds if npm install is never run inside Docker. If someone switches to npm install in the Dockerfile — say, to work around a lockfile sync issue — that protection disappears and min-release-age would need to be configured there too.

Update

Another 317 packages affected: https://safedep.io/mini-shai-hulud-strikes-again-314-npm-packages-compromised/

New proposal for install scripts to be opt-in: https://github.com/npm/rfcs/pull/868

Sources

Top comments (0)