Top
Best
New

Posted by varunsharma07 16 hours ago

Postmortem: TanStack NPM supply-chain compromise(tanstack.com)
https://github.com/TanStack/router/issues/7383
912 points | 382 commentspage 4
vldszn 12 hours ago|
Recommend adding this globally:

pnpm config set minimum-release-age 10080 # 7 days in minutes

https://pnpm.io/supply-chain-security#delay-dependency-updat...

blhack 10 hours ago||
Is there any obvious way to detect if you’ve gotten owned by this?
loginatnine 12 hours ago||
https://github.com/opensearch-project/opensearch-js/issues/1...

The worm is spreading...

consumer451 12 hours ago|
> This commit does not belong to any branch on this repository, and may belong to a fork outside of this repository.

My naive private repo enjoying take: wt wtf?

I understand why this needs to be a thing, maybe... but I am so glad that I am nowhere near maintaining a public repo.

captn3m0 15 hours ago||
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.

silverwind 13 hours ago|
It'll always be a cat-and-mouse game. If npm adds protections, it'll only yield false-positives and workarounds will be trivial.
tedchs 12 hours ago||
This is another indicator that "lifecycle" scripts in NPM (or other packaging systems, except perhaps Debian or RPM) are an idea we need to learn to live without. At most, packages should be able to emit a message to the user asking them to invoke a one-liner if a setup action is truly necessary.

As a side benefit, eliminating package scripts will contribute toward reproducibility of Docker and VM images.

I realize this will be a controversial opinion.

zbentley 9 hours ago|
Agreed, but that’ll be a marginal improvement at best.
tannerlinsley 14 hours ago||
Post Mortem: https://tanstack.com/blog/npm-supply-chain-compromise-postmo...
dang 7 hours ago|
Thanks! We changed the link to that from https://github.com/TanStack/router/issues/7383 above but have kept the github.com URL in the toptext.
basilikum 14 hours ago||
The next NotPetya will be an NPM package or Rust crate that no one has ever heard of, but everything depends on through transitive dependencies.
FooBarWidget 5 hours ago||
I really wonder wtf Github is doing. Cache poisoning issues like this are so easily solved at the platform level by ensuring that pull_request_target caches live can only write cache changes to a different namespace that cannot be read from normal workflows. Furthermore, the fact that the cache actions can write caches even though the workflow only has read permissions is just bad security design.

Another worry that I've had recently is that anybody who is able to get Github push access, can push new releases with malicious assets. Even if you have branch protection and environments, it doesn't do anything: the attacker can simply create a new workflow, push to a branch (which runs that workflow), and then the workflow creates a new release. No merge to main needed, pull request reviews bypassed. I want a policy that says "only this environment can create releases" (and "this environment can only be triggered by this workflow from this branch") but that's not possible.

Github, please step up.

astrostl 9 hours ago||
Updated https://github.com/astrostl/surplies to scan for it too
j-bos 15 hours ago|
> 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.

mdavidn 15 hours ago|
If the payload couldn't execute at install time, it would at runtime? Disabling prepare scripts does not seem like an effective countermeasure.
igregoryca 14 hours ago|||
Postinstall scripts have remained an effective attack vector for quite a while – which, ironically, has meant the worm's authors had little incentive to try something else, so it was easier to inoculate yourself. Alas, you're right, it should be pretty simple to bypass this kind of protection, if they haven't already (and seems like they have).
ChocolateGod 14 hours ago|||
Well at runtime one would hope they're not giving their JS app access to their home folder.
More comments...