0

The TanStack npm Attack Shows Why pnpm 11 Matters

On April 28, 2026, pnpm 11 was released with some of the strongest security defaults we've seen from a mainstream JavaScript package manager.

The release follows a wave of npm supply chain attacks, including the recent TanStack compromise and the broader Mini Shai Hulud campaign. Both incidents exposed weaknesses in GitHub Actions workflows, CI/CD pipelines, and automated dependency installs.

Modern frontend applications often depend on hundreds or thousands of transitive npm packages, which makes dependency installation one of the easiest places for supply chain attacks to spread.

Inside the TanStack Attack

The attack took advantage of weaknesses in GitHub Actions workflows and CI trust boundaries to publish malicious versions of multiple @tanstack/* packages.

In short, attackers were able to poison CI caches, leak runtime tokens, and publish malicious packages directly to npm.

TLDR of the attack

On 2026-05-11 between 19:20 and 19:26 UTC, an attacker published 84 malicious versions across 42 @tanstack/* npm packages by combining: the pull_request_target "Pwn Request" pattern, GitHub Actions cache poisoning across the fork↔base trust boundary, and runtime memory extraction of an OIDC token from the GitHub Actions runner process. No npm tokens were stolen and the npm publish workflow itself was not compromised.

The malicious versions were detected publicly within 20 minutes by an external researcher ashishkurmi working for stepsecurity. All affected versions have been deprecated; npm security has been engaged to pull tarballs from the registry. We have no evidence of npm credentials being stolen, but we strongly recommend that anyone who installed an affected version on 2026-05-11 rotate AWS, GCP, Kubernetes, Vault, GitHub, npm, and SSH credentials reachable from the install host.

Direct Quote from TanStack official postmortem.

New Security Defaults in pnpm 11

For a long time, package managers optimized mostly for convenience: install packages immediately, run scripts automatically, and trust external sources by default.

pnpm 11 starts to push back on some of those assumptions with new defaults focused on safer installs and tighter dependency verification. In earlier pnpm versions, many of these protections were opt-in.

Here are a few of the biggest changes:

  • minimumReleaseAge: 1440 — delays installs of newly published packages by 24 hours
  • blockExoticSubdeps: true — blocks risky non-registry dependencies
  • strictDepBuilds: true — tightens install-time build behavior
  • verifyDepsBeforeRun: install — verifies dependencies before execution

Delaying New Package Installs by Default

pnpm 11 now delays installation of newly published packages for 24 hours by default.

minimumReleaseAge: 1440

The first few hours after a package is published are usually the riskiest. A delay gives more time to catch malicious releases before they spread.

In the TanStack case, with a 24-hour delay, the affected versions would never have reached users in the first place.

This shifts package installation:

from "install immediately"

to "allow time for ecosystem verification."

Restricting Riskier Dependency Sources

Another big change is stricter handling of exotic subdependencies by default.

JavaScript package managers have traditionally allowed dependencies from Git repositories, tarballs, and custom registries with very few restrictions.

Example:

{
  "dependencies": {
    "some-lib": "github:user/repository"
  }
}

The issue is that these sources don't go through the same checks and visibility you typically get from the npm registry and are much harder to monitor or audit. That makes them a lot easier to abuse.

Tightening Install Script Permissions

Dependencies don't just add code to your project. They can also run code during installation through scripts like postinstall.

pnpm 11 tightens this up quite a bit by making install scripts something you explicitly opt into.

That closes off one of the easiest ways for malicious packages to execute code during install. If certain packages legitimately require build scripts, you can explicitly allow them:

allowBuilds:
  - esbuild
  - sharp

Key Takeaways

  • pnpm 11 ships with several security-focused defaults enabled out of the box.
  • minimumReleaseAge delays installs of newly published packages for 24 hours.
  • Several of the new defaults are designed to make common npm attacks much harder.
  • Package managers are becoming a much bigger part of how JavaScript apps stay secure.

See the official pnpm 11 release notes for the full list of changes.

Conclusion

pnpm 11 feels like a response to the kinds of attacks the npm ecosystem keeps running into.

After incidents like the TanStack compromise, these kinds of changes feel pretty hard to ignore.