←back to thread

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

(socket.dev)
1208 points jamesberthoty | 2 comments | 16 Sep 25 11:22 UTC | HN request time: 0.16s | source
Show context
utbabya ◴[17 Sep 25 01:22 UTC] No.45270447[source]▶
Blog author company's runner detects anomalies in them, but we shouldn't need a product for this.

Detecting outbound network connection during an npm install is quite cheap to implement in 2025. I think it comes down to tenant and incentives, if security is placed as first priority as it should, for any computing service and in particular for supply chain like package management, this would be built in.

One thing that comes to mind that would make it a months long deabte is the potential breakage of many packages. In that case as a first step just make an eye catching summary post install, with gradual push to totally restriction with something like a strict mode, we've done this before.

Which, reminds me of another long standing issue with node ecosystem toolings, information overload. It's easy to bombard devs with thesis character count then blame them for eventually getting fatigue and not reading the output. It takes effort to summarize what's most important with layered expansion of detail level, show some.

replies(1): >>45270562 #
1. killerstorm ◴[17 Sep 25 01:40 UTC] No.45270562[source]▶
"Outbound network connection at npm install" is just one of many ways malware in NPM package can manifest itself.

E.g. malware might be executed when you test code which uses the library, or when you run a dev server, or on a deployed web site.

The entire stack is built around trusting a code, letting it do whatever it wants. That's the problem.

replies(1): >>45284632 #
2. utbabya ◴[18 Sep 25 02:49 UTC] No.45284632[source]▶
Trust is hard, it all comes down to trust no matter what you do. The more general idea is sandboxed build, it doesn't eliminate all problems but one class.