Massive npm Supply Chain Compromise Hits Packages With 2 Billion Weekly Downloads
Description
A LinkedIn post screenshot from Mackenzie Jackson (Developer and Security Advocate) posted 2 hours ago with urgent warning about the largest supply chain compromise in npm, Inc. history. Packages with a total of 2 billion weekly downloads were turned malicious. The post lists 19 compromised packages with their weekly download counts: ansi-styles (371.41m), debug (357.6m), backslash (0.26m), chalk-template (3.9m), supports-hyperlinks (19.2m), has-ansi (12.1m), simple-swizzle (26.26m), color-string (27.48m), error-ex (47.17m), color-name (191.71m), is-arrayish (73.8m), slice-ansi (59.8m), color-convert (193.5m), wrap-ansi (197.99m), ansi-regex (243.64m), supports-color (287.1m), strip-ansi (261.17m), and chalk (299.99m). The post ends with 'I'll give a more detailed post later...' with a grimacing emoji
Comments
40Comment deleted
Your node_modules folder was already a black hole of untrusted code, now it's just officially compromised instead of theoretically compromised
I see my entire dependency tree is on this list. On the bright side, my node_modules folder finally has a single, unified purpose: exfiltrating my data
Remember when we worried about our k8s control plane being the single point of failure? Turns out it was strip-ansi’s preinstall script all along
The real supply chain attack was the 18 layers of color formatting dependencies we accumulated along the way - because apparently printing red text in a terminal requires more packages than launching a space shuttle
When your entire dependency tree turns malicious and you realize that 'chalk' wasn't just for making your console output pretty - it was for writing your infrastructure's obituary. Nothing says 'modern JavaScript development' quite like discovering that the package responsible for coloring your terminal text now has more access to your production environment than your actual security team
Dependency injection meets supply chain infection: npm's way of keeping your node_modules fresh... with malware
Every “largest npm compromise ever” ends the same: leadership asks if we use chalk, and I explain we don’t - our 37 transitive deps do - so the only thing it actually colored was my 3am pager
Nothing reveals your architecture like a supply‑chain scare: “Not affected” - until the SBOM shows chalk via 73 transitives; see you on the 3 a.m. bridge
https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised Comment deleted
good thing we don't update our deps Comment deleted
https://github.com/debug-js/debug/issues/1005#issuecomment-3266868187 Comment deleted
Just don't use JavaScript Comment deleted
just don't open any website Comment deleted
Or e.g. Slack at all coz it's desktop app is written on Electron Comment deleted
I don't only rss for me Comment deleted
just don’t use internet, it might be dangerous Comment deleted
Just don't Comment deleted
Just use core libraries only and maybe also some big well known libraries like DB client and shit. Stop use libraries with 100 lines that do absolutely trivial things, write it yourself. Comment deleted
Doesn't work like this Dependendecies that were infected are dependencies of your dependencies, something you have to work hard to protect against within your entire organization Comment deleted
why have every library reimplement the same feature when you can import it? Comment deleted
Because if you can't trust the code you mustn't use it. We kind of have to trust the language itself and big libraries that are bundled or well known. Trusting some random shit from random people - is simply dangerous. The "source is open someone will check it" paradigm isnt working in these amounts of code. Comment deleted
Well, for those who are sleepy heads and wants to hear TLDR. - Yes those packages we infected. - It only runs inside your browser if launched frontend code with infected package. - Infected packages were only pushed as `latest`\new release tags - Infected packages were active only for a short perioud of time: 2.5~ hours - It could have affected your build only if you tried to install one of those packages directly with npm install during this timeframe - It's true that you might have those packages installed as dependencies inside package-lock.json but they are import with sha256 hash, it means that even if hacked package tries to override all tags inside registry it still shouldn't affect you Correct me if I am wrong Good night everyone and have a nice sleep Comment deleted
Js plebs stay mad and have a v8 Comment deleted
According to the standards of python, rust, c++, or any other sane language, js just simply doesn't have a so-called core library. Comment deleted
Well, lol Comment deleted
Deno do have a std which I literally saw zero people using. Comment deleted
Wow, the hacker has been damaged to core, Nice and interesting! 👏 Comment deleted
And use six remaining values for different kind of flags Comment deleted
Thanks god is-even and is-odd are safe! 😅 Comment deleted
And people asking why enterprise store everything on its own arficatories and you go trough 3 circles of hell to bump package version in lock file. I guess that’s why Comment deleted
Never used any of those. Christ is King. Comment deleted
They live somewhere in your node_modules Comment deleted
I'm not falling for that demoralization campaign. Comment deleted
This is why I write everything I can myself or use the OS's APIs Comment deleted
That's also why you are unemployable Comment deleted
I am exployed but privately I dont use 92737 dependencies just for a calculator app Comment deleted
you're employed? hey um reminder that you still owe me 160€ >:P Comment deleted
✅ just write it yourself you lazy bastard Comment deleted
exactly Comment deleted
"package manager is a convenience that every language must have" incident Comment deleted