(socket.dev)

1208 points jamesberthoty | 1 comments | 16 Sep 25 11:22 UTC | HN request time: 0.22s | source

A lot of blogs on this are AI generated and such as this is developing, so just linking to a bunch of resources out there:

Socket:

- Sep 15 (First post on breach): https://socket.dev/blog/tinycolor-supply-chain-attack-affect...

- Sep 16: https://socket.dev/blog/ongoing-supply-chain-attack-targets-...

StepSecurity – https://www.stepsecurity.io/blog/ctrl-tinycolor-and-40-npm-p...

Aikido - https://www.aikido.dev/blog/s1ngularity-nx-attackers-strike-...

Ox - https://www.ox.security/blog/npm-2-0-hack-40-npm-packages-hi...

Safety - https://www.getsafety.com/blog-posts/shai-hulud-npm-attack

Phoenix - https://phoenix.security/npm-tinycolor-compromise/

Semgrep - https://semgrep.dev/blog/2025/security-advisory-npm-packages...

Show context

foxfired ◴[16 Sep 25 21:41 UTC] No.45268501[source]▶

>>45260741 (OP) #

My problem is that, in the JS ecosystem, every single time you go through a CI/CD pipeline, you redownload everything. We should only download the first time and with the versions that are known to work. When we make a manual update to version, than only that should be downloaded once more.

I just checked one of our repos right now and it has a 981 packages. It's not even realistic to vet the packages or to know which one is compromised. 99% of them are dependencies of dependencies. Where do we even get started?

replies(3): >>45268537 #>>45268574 #>>45268604 #

1. amarshall ◴[16 Sep 25 21:45 UTC] No.45268537[source]▶

>>45268501 #

Redownloading everything isn’t a risk when the lock file contains a hash of the download on first update.

↑

Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised