Live data from Hacker News

Postmortem: TanStack NPM supply-chain compromise

tanstack.com

411–420 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#411
post #353

Earlier quoted context omitted.

`sops` combined with `age` is great! Benefit is that it doesn't tie you into 1Password's ecosystem

That looks interesting, but unless I'm missing it, it still leaves you with things like ~/.aws/credentials in plaintext on disk, doesn't it?

AWS allows you to set `credential_process` and have it point to a script that fetches your credential from wherever you like and print it to stdout.

Re: Postmortem: TanStack NPM supply-chain compromise

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

> as a systemd user service Hah! I know why I don't use systemd.

> I know why I don't use systemd

Could just as easily install it in your user's crontab though?

Re: Postmortem: TanStack NPM supply-chain compromise

#414
post #285

What do folks here do to avoid having plaintext credentials on disk? I try to use 1Password's plugins where I can. I find the SSH key (and got signing) experience flawless, but the cli experience (eg aws cli) pretty clunky - they often break, and they don't even have a gcp plugin last I checked.

I use `pass` on all my personal dev workstations and phone (because I happen to own YubiKeys/OpenPGP cards with my PGP key on them anyway; would probably use `age`/SOPS instead if I already hadn't committed to the PGP ecosystem).

If /usr/bin/bar wants a credential via a FOO_API_KEY environment variable, I create a /usr/local/bin/bar wrapper script like so:

    #!/bin/bash
    set -eu +x
    
    if [[ -z "${FOO_API_KEY:-}" ]]; then
      echo >&2 Decrypting FOO_API_KEY
      FOO_API_KEY="$(pass show bar/FOO_API_KEY)"
    fi

    export FOO_API_KEY
    exec /usr/bin/bar "$@"

Re: Postmortem: TanStack NPM supply-chain compromise

#416

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…

Those should be defaults in npm.

Re: Postmortem: TanStack NPM supply-chain compromise

#417

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: chan…

The astral blog recently pointed out how they do release gates (manual approvals on release workflows) even with trusted publishing. And sadly, all of the documentation for trusted publishing (NPM/PyPi/Rubygems) doesn't even mention this possibility, let alone defaulting to it.

It seems the feature is only available for enterprise users if you want it in a private repo.

Re: Postmortem: TanStack NPM supply-chain compromise

#418

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.

Note that bun is only immune to this because it isnt in the “top 500” that bypass this system by default. I was actually surprised (pleasantly, but still surprised) tanstack wasnt in that list already

https://bun.com/docs/pm/lifecycle

Re: Postmortem: TanStack NPM supply-chain compromise

#420

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…

I hate to spam this but Ive seen this misconception on bun repeatedly in each of these incident threads. It should really be noted that bun _does_ run lifecycle scripts for the top 500 most popular packages by default. You can opt out of this but its not the default config. Its much better than the npm strategy but I think it would be much better if there was a way to explicitly acknowledge you want this default whitelist applied (eg scriptPolicy = allow, deny, or allow popular only)

https://bun.com/docs/pm/lifecycle

Post reply on HN