Live data from Hacker News

Postmortem: TanStack NPM supply-chain compromise

tanstack.com

151–160 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#151

Earlier quoted context omitted.

I'd like to have touch to sign from a YubiKey or similar. The whole idea of trusting the cloud to manage credentials on your behalf seems like a mistake.

”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).

Re: Postmortem: TanStack NPM supply-chain compromise

#152
post #121

Earlier quoted context omitted.

I think you missed the joke/sarcasm there.

It's been less than a month since I responded to a comment on a different thread arguing basically the same thing about C/C++ in a serious way. I've long since lost the ability to distinguish.

Fair, I'm in fact not 100% sure it's a joke. But there's a smiley, that's pushing me to 90%.

Re: Postmortem: TanStack NPM supply-chain compromise

#153

Earlier quoted context omitted.

Incredible. Mutually assured destruction. The next five years are going to be truly WILD in the software world. Air-gapped systems are gonna be huge.

Maybe just ai-gapped.

Is that an offhanded joke on the terminology or do you actually mean something? I can't tell.

Re: Postmortem: TanStack NPM supply-chain compromise

#154

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…

Yeah I have one semi-popular package and I am still doing local publish with 2fa because all this "trusted publishing" stuff seems really complicated and also seems to get hacked constantly. Maybe it's just too complicated for us to do securely and we should go back to the drawing board.

Re: Postmortem: TanStack NPM supply-chain compromise

#155
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.

Also `allow-git=none` for npm v11+: https://github.blog/changelog/2026-02-18-npm-bulk-trusted-pu...

Re: Postmortem: TanStack NPM supply-chain compromise

#156
post #41

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 ~/. https://github.com/TanStack/router/issues/7383#issuecomment-...

One should always have had backups configured, but if this is what gets people to setup backups, so much the better.

Sure. But even restoring from backup means a cost is being inflicted, and not a small one.

Re: Postmortem: TanStack NPM supply-chain compromise

#157

Earlier quoted context omitted.

I agree with you that TP is an improvement over long lived npm tokens in CI. However, the threat Im most afraid of still does involve dev environment compromise. Because if your repo admin gets their token stolen from their gh cli, they can trivially undo via API (without a 2fa gate!) any github level gate you have put in place to make TP safe. I want so badly to be wrong about that, we have been evaluating TP in my…

Yes, that is the threat I'm most worried about as well. But look at your description of it - a repo admin has to be compromised. Not just "random engineer". Although, in this case, the attacker leveraged a cache poisoning attack to move into the privileged workflow and I suspect this sort of thing will be commonplace. I'm in agreement that a second factor would be ideal, to be clear. I think it's a good idea, somethi…

Not to beat the dead horse, but ths floored me when I realized it so I keep trying to shout it at the top of my lungs.

There is no gate you can put on a Trusted Publisher setup in github which requires 2fa to remove. Full stop. 2fa on github gates some actions, but with a token with the right scope you can just disable the gating of workflow-runs-on-approve, branch protection, anything besides I think repo deletion and renaming.

And in my experience most maintainers will have repo admin perms by nature of the maintainer team being small and high trust. Your point is well taken, however, that said stolen token does need to have high enough privileges. But if you are the lead maintainer of your project, your gh token just comes with admin on your repo scope.

Re: Postmortem: TanStack NPM supply-chain compromise

#158
post #41

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 ~/. https://github.com/TanStack/router/issues/7383#issuecomment-...

Realistically if you have installed malware, you need to do a full wipe of your computer anyway.

[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.

Re: Postmortem: TanStack NPM supply-chain compromise

#159

Earlier quoted context omitted.

Realistically if you have installed malware, you need to do a full wipe of your computer anyway.

[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.

You should assume other LPEs exist though

Re: Postmortem: TanStack NPM supply-chain compromise

#160

Earlier quoted context omitted.

QubesOS had the right idea. You want layers and layers of security, with multiple VMs at the root.

> had the right idea Is it no longer the right idea?

I mean that in the sense that they had the idea way before the wave of rapid linux 0days and supply chain attacks were common. The design they picked has only become more relevant.
Post reply on HN