←back to thread

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

(socket.dev)

1208 points jamesberthoty | 1 comments | 16 Sep 25 11:22 UTC | HN request time: 0.24s | 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

Meneth ◴[16 Sep 25 12:25 UTC] No.45261303[source]▶

>>45260741 (OP) #

This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person.

The general solution is to do what Debian does.

Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use.

Keep a testing/unstable distro where new packages and new versions can be added, but even then added only by the distro maintainer, NOT by the package developers. This is where the audits happen.

NPM, Python, Rust, Go, Ruby all suffer from this problem, because they have centralized and open package repositories.

replies(25): >>45261528 #>>45261617 #>>45261792 #>>45262591 #>>45262655 #>>45262978 #>>45263089 #>>45263137 #>>45263570 #>>45263728 #>>45264113 #>>45264189 #>>45265297 #>>45266032 #>>45266873 #>>45267343 #>>45268626 #>>45268669 #>>45269007 #>>45269777 #>>45270131 #>>45270753 #>>45272097 #>>45273282 #>>45273471 #

1. ExoticPearTree ◴[17 Sep 25 08:27 UTC] No.45273282[source]▶

> The general solution is to do what Debian does.

The problem with this approach is that frameworks tend to "expire" pretty quickly and you can't run anything for too long on Debian until the framework is obsolete. What I mean by obsolete is Debian 13 ships with Golang 1.24, A year from now it's gonna be Golang 1.26 - that is not being made available in trixie. So you have to find an alternative source for the latest golang deb. Same with PHP, Python etc. If you run them for 3 years with no updated just some security fixes here and there, you're gonna wake up in a world of hurt when the next stable release comes out and you have to do en-masse updates that will most likely require huge refactoring because syntax, library changes and so on.

And Javascript is a problem all by itself where versions come up every few months and packages are updated weekly or monthly. You can't run any "modern" app with old packages unless you accept all the bugs or you put in the work and fix them.

I am super interested in a solution for this that provides some security for packages pushed to NPM (the most problematic repository). And for distributions to have a healthy updated ecosystem of packages so you don't get stuck who knows for how long on an old version of some package.

And back to Debian, trixie ships with nginx 1.26.3-3+deb13u1. Why can't they continuously ship the latest stable version if they don't want to use the mainline one?