“Socket detected 84 compromised TanStack npm package artifacts modified with suspected CI credential-stealing malware.” — @SocketSecurity
https://socket.dev/blog/tanstack-npm-packages-compromised-mini-shai-hulud-supply-chain-attack
Zach Leatherman 1111 replies 99 likes77 reposts11 quote Original on Mastodon11 replies
And here is an absolute masterclass in writing a post-mortem from the team: https://tanstack.com/blog/npm-supply-chain-compromise-postmortem
@zachleat I'm not sure I would agree. This entire article reads like they dumped all their logs to Claude Code and asked it to generate a post mortem.
@jeromechoo I’m not sure I need to be included in this feedback
@zachleat I’m not trying to be rude. I’m genuinely trying to figure out what makes this a masterclass retro.
It does include a lot of details, but doesn’t mention the dead man’s switch that was posted 3 hours ago https://github.com/TanStack/router/issues/7383#issuecomment-4425225340 and has exactly one general line on what owners of compromised machines should do.
Did I miss something?
@zachleat npm needs to make prepare/postinstall hooks opt-in and allow-listed instead of on by default for the whole universe
and a declarative/sandboxed solution for packages that have to download and compile as an escape hatch (something like flathub's manifest where the framework does the downloading for you and rejects anything that doesn't match the expected hashes)
absurd that even crates.io has the same problem and no solution in sight :S
@zachleat pull_request_target strikes again!
A follow up here on action items (assuming you’re already using trusted publishers OIDC to scope releases to a single GitHub Action workflow):
1. Look for any `pull_request_target` GitHub Actions workflows! (this allows external forks/code to run your actions with write access ☠️☠️☠️☠️☠️)
2. Look for use of `cache` in your GitHub Actions release workflow (cache was poisoned/compromised by `pull_request_target` trigger)Learn more about `pull_request_target`: https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/
Importantly, `pull_request_target` IGNORES this GitHub security setting: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#controlling-changes-from-forks-to-workflows-in-public-repositories
This was very surprising to me.
@zachleat Surprise!
@jgarber luckily I don’t use `pull_request_target` anywhere but WOOOOOOOFFFFF
@zachleat pull_request_target has •always• been a yard full of rakes waiting to be stepped on. I don’t know enough to draw any conclusions, and (like you) I’ve never used it, but I also never understood why they’d ship something so easily misused.
