Is My Project Affected by an npm Supply Chain Attack? (2026)

Between March and July 2026, six separate npm supply chain campaigns pushed malicious code into packages that vibe-coded apps install by default. Two of them ran for under three hours before npm pulled the tarballs. That is short enough to feel like someone else's problem, and long enough that if you deployed during the window, you have a real one.

The honest answer to "am I affected" takes about two minutes to reach. Here's the procedure, then the version list.

Step 1: Look for the injected package names

Three of the six campaigns worked by adding a dependency that has no business being there. That makes them trivially greppable, because the malicious package name appears in your lockfile as plain text no matter which package manager wrote it.

grep -nE 'plain-crypto-js|easy-day-js|@tanstack/setup' \
  package-lock.json pnpm-lock.yaml yarn.lock bun.lock 2>/dev/null

No output means none of those three landed in your tree. That is the good result, and for most projects it's the result you'll get.

If you do get a hit, note which one:

• plain-crypto-js came in through axios. It's declared as a dependency but never imported by any axios source file, which is the whole tell.
• easy-day-js came in through the @mastra scope. It is a typosquat of dayjs that copies the real package's author name, homepage, repository URL and license verbatim, so it survives a skim of the lockfile diff. The malicious version is 1.11.22.
• @tanstack/setup shows up as an optionalDependencies entry pointing at a GitHub commit rather than a registry version. Packages in that campaign also dropped a router_init.js file of roughly 2.3 MB into their package root, which is a size no router bootstrap file has any reason to be.

Step 2: Check the versions that were poisoned in place

The other three campaigns republished packages you already depend on, under versions that look ordinary. Nothing new appears in the lockfile. Only the number changes.

npm ls axios jscrambler \
  @asyncapi/specs @asyncapi/generator \
  @asyncapi/generator-components @asyncapi/generator-helpers

Substitute pnpm why <pkg> or yarn why <pkg> if that's your manager. Then compare against this list.

The TanStack incident is the awkward one to check by version, because it hit 42 @tanstack/* packages with 84 malicious versions published in a six minute window on May 11, 2026 (19:20 to 19:26 UTC). There's no short version list to eyeball. Use the @tanstack/setup grep from Step 1, and if you want the full enumeration, the GitHub advisory is GHSA-g7cv-rxg3-hmpx.

The binding.gyp campaign of June 3, 2026 is the same shape at larger scale: 57 packages across more than 286 malicious versions, starting with @vapi-ai/server-sdk at 23:30 UTC and spreading through everything the compromised maintainer account could publish. If you install AI SDK packages, that's the one to look at hardest.

Step 3: Ask when your lockfile last moved

This is the check that resolves most cases, and almost nobody runs it.

git log --follow --format='%h  %ad  %s' --date=short -- package-lock.json | head -20

A lockfile pins exact versions and exact tarball hashes. npm ci reads it and resolves nothing, so it physically cannot pull a version that was published after the lockfile was written. If your lockfile has not been touched since, say, February 2026, and your deploys run npm ci, then none of the six campaigns reached you. You can stop here.

Check your deploy config for which command actually runs. Vercel, Netlify and Railway all pick a command based on which lockfile they detect, and a missing or gitignored lockfile silently downgrades you to a fresh resolve on every single build.

Why --ignore-scripts is no longer the answer

The standard advice for years has been npm install --ignore-scripts. It's still worth doing. It is also no longer sufficient, and 2026 is the year that became obvious, because the campaigns split across three different execution triggers.

The June campaign, which StepSecurity named "Phantom Gyp", skipped lifecycle hooks entirely. It shipped a binding.gyp file crafted so that node-gyp executed attacker-controlled code as part of building the native module. That's not a hook you can turn off. It's the build step doing its job.

The July AsyncAPI compromise went further and put the payload in the package entry point. Microsoft's analysis of that incident states it plainly: because the trigger is an import rather than an install script, the usual --ignore-scripts mitigation does not neutralize it. The code ran the first time your app did require('@asyncapi/specs'), which for a lot of projects is on every cold start.

That last detail is the one worth sitting with. Signed provenance answers "did this come from the expected pipeline", not "is this safe". A compromised pipeline produces perfectly valid signatures.

If you got a hit

Order matters here, and it's not the order most people use. Most people delete the package first.

What actually reduces the odds next time

Not much of the standard advice survives contact with these six incidents, so here's what does.

Install from a committed lockfile, always. npm ci in CI, npm ci on your host, lockfile committed and not gitignored. This single change would have blocked every campaign above for any project whose lockfile predated the window.

Delay your upgrades. Four of the six compromises were caught and pulled within hours: axios in about three, the first jscrambler release in six minutes, TanStack within 20 to 26 minutes of publication. A dependency policy that waits even 48 hours before adopting a new release turns most of these into nothing. You give up nothing real. Nobody needs axios@1.14.1 the hour it ships.

And read the diff when the lockfile changes. It's boring. It's also where every one of these was visible.