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: 0s | 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 #

cycomanic ◴[16 Sep 25 20:11 UTC] No.45267343[source]▶

>>45261303 #

I've been arguing a couple of times that the 2 main reasons people want package management in languages are

1. Using an operating system with no package management 2. Poor developer discipline, i.e. developers always trying to use the latest version of a package.

So now we have lots of poorly implemented language package managers, docker containers on top being used as another package management layer (even though that's not their primary purpose but many people use the like that) and the security implications of pulling in lots of random dependencies without any audit.

Developing towards a stable base like Debian would not be a pancea, but alliviate the problems by at least placing another audit layer in between.

replies(2): >>45267440 #>>45268911 #

1. cortesoft ◴[16 Sep 25 22:14 UTC] No.45268911[source]▶

>>45267343 #

It doesn't matter if the operating system I personally use has a good package manager, I need to release it in a form that all the people using it can work with. There are a lot of OSes out there, with many package managers.

Even if we make every project create packages in every package manager, it still wouldn't add any auditing.

↑