Live data from Hacker News

Postmortem: TanStack NPM supply-chain compromise

tanstack.com

51–60 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#51
1. _Multiple third-party companies_ can detect these obviously malicious packages in almost-real-time

2. NPM still not only publishes them, but also keeps distributing them for anything beyond 5 minutes.

Microsoft/GitHub/NPM can only keep repeating "security is our top priority" so many times. But NPM still doesn't detect these simple attacks, and we keep having this every week.

Re: Postmortem: TanStack NPM supply-chain compromise

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

Re: Postmortem: TanStack NPM supply-chain compromise

#53
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…

I wonder whether NPM has surpassed the costs of the billion dollar mistake, null references. NPM hasn't been around as long, but the industry is much bigger today than it was when systems languages were dominant.

Re: Postmortem: TanStack NPM supply-chain compromise

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

if so, then this is actual terrorism of the software world!!

Re: Postmortem: TanStack NPM supply-chain compromise

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

Wild claim that setting the minimum age to 7 days will result in me "never" getting a supply chain npm vuln.

Re: Postmortem: TanStack NPM supply-chain compromise

#58
post #30

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…

It's insane to me you spend $200 on a report you likely rarely read in detail or double check for correctness, yet you're doing it to feel good about security.

If it runs in a harness that will alert me when something dodgy is detected I'm fine to stay at that level.

I don't read it in detail because reading in detail is precisely what I delegate to the harness. The alternative is that I delegate all this trust to package managers and the maintainers which quite clearly is a bad idea.

Whether the $$ pricetag is worth it is.. relative. Also in Go you don't update all that often, really when something either breaks or there is a legitimate security reason to do so, which in deep systems software is quite infrequent.

Funnily enough for frontend NPM code our policy was to never ever upgrade and run with locked dependencies, running few years old JS deps. For internal dashboards it was perfectly fine, never missed a feature and never had a supply chain close call.

Re: Postmortem: TanStack NPM supply-chain compromise

#59
post #7

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.

Abandon NPM in exchange for what? Cargo? Go get? Pip install? Every package manager that does not analyze and run tests on the packages being uploaded (like Linux distros do) is vulnerable.

Just writing the actual code that you are being paid to write

Re: Postmortem: TanStack NPM supply-chain compromise

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

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