Postmortem: TanStack NPM supply-chain compromise • Hacker News Board

Re: Postmortem: TanStack NPM supply-chain compromise

#31

Post by AgentME » Mon, May 11, 2026, 10:12 PM UTC

nine_k wrote: post #26

devttyeu wrote: post #19

Earlier quoted context omitted.

Cargo is spiritually based on NPM so it's not much better. Go Get is closer to always locking dependencies unless you explicitly upgrade them with a go get, so it's much much better in my view. Yes, you can lock deps in NPM/Cargo/etc. but that's not the default. It is the default in Go. In Go projects my policy for upgrading dependencies includes running full AI audit of all code changed across all dependencies, come…

> comes out to ~$200 in tokens every time BTW a curated mirror of packages, where every package is guaranteed to have been analyzed and tested, could be an easy sell now. Also relatively easy to create, with the help of AI. A $200 every time is less pleasant than, say, $100/mo for the entire org. Docker does something vaguely similar for Docker images, for free though.

People are already scanning npm constantly. You can limit yourself to pre-scanned packages by setting npm's minimum release age setting to 1 or 2 days (a timeframe that all the recent high-profile malicious package versions were unpublished within).

Re: Postmortem: TanStack NPM supply-chain compromise

#32

Post by AgentME » Mon, May 11, 2026, 10:13 PM UTC

bakugo wrote: post #8

slopinthebag wrote: post #3

My decision to abandon the JS ecosystem and language entirely continues to pay off. What a mess... I am, however, concerned that this will pwn my workplace. We don't use Tanstack but this seems self-propagating and I doubt all of our dependencies are doing enough to prevent it.

I highly recommend enforcing a minimum dependency release age of at least a week across all package managers used at your workplace. Most package managers support it now, and it will save you from the vast majority of these attacks. https://news.ycombinator.com/item?id=47582632

Highly recommend using the minimum release age setting, though I think a week is probably overkill. Did any of the recent supply-chain attacks have a malicious version up for more than a day?

Re: Postmortem: TanStack NPM supply-chain compromise

#33

Post by captn3m0 » Mon, May 11, 2026, 10:13 PM UTC

rvz wrote: post #22

gajus wrote: post #13

Reminder to secure your npm environments. https://gajus.com/blog/3-pnpm-settings-to-protect-yourself-f... Just a handful of settings to save a whole lot of trouble.

And absolutely pin, pin, pin, ALL your dependencies. If I see a package version dependency that looks like this: ^1.0.0 or even this: "*", then stop reading, pin it to a secure version immediately.

I've been collecting things you can't pin:

- Python inline dependencies in PEP-0723, which you can pin with a==1.0, but can't be hash-pinned afaik.

- The bin package manager lets you pin binaries, but they aren't hash-pinned either.

- The pants build tool suggests vendoring a get-pants.sh script[0] but it downloads the latest. Even if you pass it a version, it doesn't do any checks on the version number and just installs it to ~/.local/bin

[0]: https://github.com/pantsbuild/setup/blob/gh-pages/get-pants....

Re: Postmortem: TanStack NPM supply-chain compromise

#34

Post by nine_k » Mon, May 11, 2026, 10:15 PM UTC

AgentME wrote: post #31

nine_k wrote: post #26

Earlier quoted context omitted.

> comes out to ~$200 in tokens every time BTW a curated mirror of packages, where every package is guaranteed to have been analyzed and tested, could be an easy sell now. Also relatively easy to create, with the help of AI. A $200 every time is less pleasant than, say, $100/mo for the entire org. Docker does something vaguely similar for Docker images, for free though.

People are already scanning npm constantly. You can limit yourself to pre-scanned packages by setting npm's minimum release age setting to 1 or 2 days (a timeframe that all the recent high-profile malicious package versions were unpublished within).

Note to self: the test suite for vetting a package should include setting the system date some time in the future, to check if an exploit is trying to sleep long enough to defeat the age limit.

Re: Postmortem: TanStack NPM supply-chain compromise

#35

Post by squidsoup » Mon, May 11, 2026, 10:15 PM UTC

rvz wrote: post #16

Once again, Shai-Hulud wrecking havock in the Javascript and Typescript ecosystems via NPM. One of the worst ecosystems that has been brought into the software industry and it is almost always via NPM. Not even Cargo (Rust) or go mod (Golang) get as many attacks because at least with the latter, they encourage you to use the standard library. Both Javascript and Typescript have none and want you to import hundreds of…

If cargo was as popular as npm, the same issues would surface.

Re: Postmortem: TanStack NPM supply-chain compromise

#36

Post by jonchurch_ » Mon, May 11, 2026, 10:15 PM UTC

captn3m0 wrote: post #27

jonchurch_ wrote: post #23

It is unfortunate, but this is evidence (IMO) that Trusted Publishing is still ~~not secure~~ not enough by itself to securely publish from CI, as an attacker inside your CI pipeline or with stolen repo admin creds can easily publish. This isnt new information, TP is not meant to guarantee against this, but migrating to TP away from local publish w/ 2fa introduces this class of attack via compomise of CI. (edit: chan…

The astral blog recently pointed out how they do release gates (manual approvals on release workflows) even with trusted publishing. And sadly, all of the documentation for trusted publishing (NPM/PyPi/Rubygems) doesn't even mention this possibility, let alone defaulting to it.

I have not read that blog post. But unfortunately (and I'd love to be wrong!) it doesn't matter for if a repo admin's token gets exfiled, because if you put your gates within Github, an admin repo token is sufficient to defang all of them from the API without 2fa challenge.

That is why I want 2fa before publish at the registry, because with my gh cli token as a repo admin, an attacker can disable all the Github branch protection, rewrite my workflows, disable the required reviewers on environments (which is one method people use for 2fa for releases, have workflows run in a GH environment whcih requires approval and prevents self review), enable self review, etc etc.

Its what I call a "fox in the hen house" problem, where you have your security gates within the same trust model as you expect to get stolen (in this case, having repo admin token exfiled from my local machine)

Re: Postmortem: TanStack NPM supply-chain compromise

#37

Post by mediaman » Mon, May 11, 2026, 10:16 PM UTC

ChoosesBarbecue wrote: post #4

> Please be careful when revoking tokens. It looks like the payload installs a dead-man's switch at ~/.local/bin/gh-token-monitor.sh as a systemd user service (Linux) / LaunchAgent com.user.gh-token-monitor(macOS). It polls api.github.com/user with the stolen token every 60s, and if the token is revoked (HTTP 40x), it runs rm -rf ~/. (It looks like it might also have a bunch of persistence mechanisms. I haven't studi…

I could imagine this might also be to try cover its tracks. If it gets 40x it means it's been found, time to nuke everything it can.

Re: Postmortem: TanStack NPM supply-chain compromise

#38

Post by skydhash » Mon, May 11, 2026, 10:16 PM UTC

rvz wrote: post #16

Once again, Shai-Hulud wrecking havock in the Javascript and Typescript ecosystems via NPM. One of the worst ecosystems that has been brought into the software industry and it is almost always via NPM. Not even Cargo (Rust) or go mod (Golang) get as many attacks because at least with the latter, they encourage you to use the standard library. Both Javascript and Typescript have none and want you to import hundreds of…

The Standard C library is also very small. Even though there’s POSIX, for anything that’s not system programming, you will be using libraries.

The difference is that the usual C libraries don’t split the project into small molecules for no good reasons. You have to be as big as GTK to start splitting library in my opinion.

Re: Postmortem: TanStack NPM supply-chain compromise

#39

Post by svachalek » Mon, May 11, 2026, 10:18 PM UTC

DrewADesign wrote: post #18

ljm wrote: post #5

So when do we call out NPM as an easy supply chain vector and also Microsoft's ownership of NPM and their prioritisation of AI at any cost. NPM is the windows of package managers right now.

People have for years. The real question is do people enjoy not putting any thought into their super convenient JavaScript stack too much to actually do anything about it. Delaying updating to new packages assuming the vulnerability will be discovered in two days or whatever is putting a knee brace on a leg that needs to be amputated. Sooner or later there will be a vulnerability good enough to not be caught in a cou…

The part that always gets me is I tend to only install a few packages like React and maybe some kind of data access layer. But you let that recurse down a few levels and suddenly you've installed a thousand packages, some of them hopelessly obsolete, some of them for patently stupid things that are 1 line of code, etc, etc. I.E. you can't choose to be thoughtful if the main entry points into the language are all built on a pile of garbage.

Re: Postmortem: TanStack NPM supply-chain compromise

#40

Post by chrisweekly » Mon, May 11, 2026, 10:18 PM UTC

Postinstall scripts are deadly. Everyone should be using pnpm.

Crazy that an "orphan" commit pushed to a FORK(!) could trigger this (in npm clients). IMO GitHub deserves much of the blame here. A malicious fork's commits are reachable via GitHub's shared object storage at a URI indistinguishable from the legit repo. That is absolutely bonkers.