Mass npm Supply Chain Attack Hits TanStack, Mistral AI, and 170+ Packages (safedep.io)
from sanitation@lemmy.radio to programming@programming.dev on 12 May 10:56
https://lemmy.radio/post/13277346

massive campaign for 170+ packages and 400+ malicious versions published. what we saw that not a single maintainer account compromised. tanStack and Mistral AI these are the names that stand out.

#programming

threaded - newest

ultimate_worrier@lemmy.dbzer0.com on 12 May 11:01 next collapse

youtu.be/zrS4yJt3rho

kibiz0r@midwest.social on 12 May 12:47 next collapse
  • Use lockfiles
  • Use minimum release age gating
  • Disable postinstall hooks
  • Limit credentials of CI jobs, especially ones that eagerly update deps
  • Disable dep-updating features completely (at the network level if you can) when deploying to higher envs
  • Be skeptical of standalone CLIs — they often try to self-update, or bootstrap deps from npm, and don’t always use lockfiles to manage it
mintiefresh@piefed.social on 12 May 12:12 next collapse

Another supply chain attack has hit npm. Crazy. Feels a bit scary to use npm right now.

robert02@programming.dev on 12 May 13:05 next collapse

Another supply chain attack has hit npm. Crazy. Feels a bit scary to use npm right now.

Body

Yeah, it’s getting pretty concerning. What makes this one worse is that it doesn’t look like maintainer accounts were even compromised, which suggests automated package flooding rather than traditional account takeover.

Still, npm itself isn’t inherently unsafe — the bigger risk is dependency trust and how quickly malicious packages can propagate. Pinning versions, using lockfiles, and auditing dependencies is more important than ever right now.

vane@lemmy.world on 12 May 16:10 collapse

It’s like Windows, it also have same owners.

Avicenna@programming.dev on 12 May 13:27 collapse

So how does this actually work? Lets say there is a package called A version 2.2.1. Other creates a fake package A 2.2.2 with malicous script and publishes it in npm. My question is why would anyone install this if it is not coming from the original package’s publisher? Would an automated updater even use these packages for an update if it is not coming from the same publisher? My second question is did this attacker use hundereds of different accounts to publish these hundereds of packages? If not isn’t it suspicious that a single account published so many packages all at once?

brian@programming.dev on 12 May 13:36 collapse

it was coming from the original package publisher. tanstack was cache poisoning via pr, so no account credentials were stolen but it was published as a normal update

tanstack.com/…/npm-supply-chain-compromise-postmo…

Avicenna@programming.dev on 12 May 14:05 collapse

and then other packages like mistral were affected because they depend on tanstack so those were direct credential hijacks?

brian@programming.dev on 12 May 14:15 collapse

probably not, I haven’t seen any other post mortems but the tanstack ones were only up for 20 minutes so really low chance. I wouldn’t be surprised if they were all a similar approach and that’s why they all happened at the same time