- 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
this post was submitted on 12 May 2026
65 points (100.0% liked)
Programming
26892 readers
427 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
Another supply chain attack has hit npm. Crazy. Feels a bit scary to use npm right now.
It's like Windows, it also have same owners.
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.
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?
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
https://tanstack.com/blog/npm-supply-chain-compromise-postmortem
and then other packages like mistral were affected because they depend on tanstack so those were direct credential hijacks?
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