Postmortem: TanStack npm supply-chain compromise

varunsharma07

The Mini Shai-Hulud worm is actively compromising legitimate npm packages by hijacking CI/CD pipelines and stealing developer secrets. StepSecurity's OSS Package Security Feed first detected the attack in official @tanstack packages and is tracking its spread across the ecosystem in real time.

slopinthebag

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.

ChoosesBarbecue

> 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 studied these closely.) Jesus, that's vindictive.

ljm

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.

fabian2k

At least it was only online for 1-2 hours at most, and it didn't affect react-query. But still a bunch of quite well-known packages. This doesn't really feel sustainable, you're rolling the dice every time the dependencies are updated.

gajus

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.

rvz

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 libraries, increasing the risk of a supply chain attack. At this point, JS and TS are considered harmful.

sn0n

As Theo goes live…

jonchurch_

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: changed "still not secure" to "still not enough by itself" bc that is the point I want to make) Going to Trusted Publishing / pipeline publishing removes the second factor that typically gates npm publish when working locally. The story here, while it is evolving, seems to be that the attacker compromised the CI/CD pipeline, and because there is no second factor on the npm publish, they were able to steal the OIDC token and complete a publish. Interesting, but unrelated I suppose, is that the publish job failed. So the payload that was in the malicious commit must have had a script that was able to publish itself w/ the OIDC token from the workflow. What I want is CI publishing to still have a second factor outside of Github, while still relying on the long lived token-less Trusted Publisher model. AKA, what I want is staged publishing, so someone must go and use 2fa to promote an artifact to published on the npm side. Otherwise, if a publish can happen only within the Github trust model, anyone who pwns either a repo admin token or gets malicious code into your pipeline can trivially complete a publish. With a true second factor outside the Github context, they can still do a lot of damage to your repo or plant malicious code, but at least they would not be able to publish without getting your second factor for the registry.

chrisweekly

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.

cube00

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

nathanmills

TanStack? Jia Tan? Who is falling for this???

captn3m0

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.

bpavuk

related: CVE-2024-YIKES https://news.ycombinator.com/item?id=48086082

j-bos

> it installs that commit's declared dependencies (which include bun) and then runs its prepare lifecycle script Again? How have lifecycle scripts not instantly been defaulted off? Yes breaking things is bad, but come on, this keeps happening, the fix is easy, and if an *javascript* build relies of dependendlcy of dependency's pulled build time script, then it's worth paying in braincells or tokens to digure it out and fix the biold process, or lately uncover an exploit chain. This isn't even a compiled language.

getcrunk

I think we are at the point where everyone really needs to run each project in its own vm. Given the recent lpe vulns docker 100% won’t cut it. And containers were never meant primarily as a security boundary anyways

riteshnoronha16

Applying cooldowns is probably the easiest way to avoid picking up this packages. Stay safe.

idoxer

Ah shit, here we go again

chuckadams

The malware uses a "prepare" hook to use bun to run the payload, an attack that ironically enough, bun is immune to. Enabling lifecycle scripts in dependencies by default in 2026 is just plain malpractice.

varunsharma07

@mistralai/mistralai npm package was also compromised as part of this worm https://github.com/mistralai/client-ts/issues/217 It has been pulled from the npm registry now.