Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

safedep.io

Post reply on HN
Print view View original

121–130 of 329 posts

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#121

Post by throwaway27448 »

jubilanti wrote: post #119
teddyh wrote: post #65

‘No way to prevent this’, Says Only Development Community Where This Regularly Happens ­— https://itnext.io/no-way-to-prevent-this-says-only-developme... >

Yeah funny, but npm is not the only development community where this regularly happens. The Onion article this joke refers to [1] is funny because there is a very clear and obvious reason why the U.S. has far more gun deaths per capita. This doesn't apply for npm. [1] https://theonion.com/no-way-to-prevent-this-says-only-nation...

Oh?

Edit: please explain. What other community has this rate of attacks? It's possible they are just detected or publicized less, too. Please help me understand what you're referring to.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#122

Post by lyu07282 »

pier25 wrote: post #106
827a wrote: post #91

I can't wait for npm/github to do literally anything at all to mitigate these attacks. Literally anything. Have we considered a basic WAF-style block on some postinstall script strings? LLM-assisted code scanning on publish? Is there anyone home? No I suspect not.

Third parties can detect compromised packages. It’s ridiculous Microsoft doesn’t.

They can and do indeed detect those attacks, it's just from Microsoft's POV a feature of Microsoft Defender (on Windows and Cloud) they sell:

https://www.microsoft.com/en-us/security/blog/2025/12/09/sha...

https://azure.microsoft.com/en-us/pricing/details/defender-f...

So this is presumably why they will never address this in npm itself.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#123

Post by troad »

I'm very glad I never bought into fullstack JS/TS.

My JS is frontend only, served as a compiled bundle off a server that doesn't even have a JS runtime of its own. Whatever random vulnerabilities the frontend contains are limited in blast radius to the user's own browser, and since all frontends should be untrusted anyway, there is no real security risk to the server or backend. No reason to update more than a few times a year, if that.

Combine with obvious basic security practices like pnpm cooldowns + no build scripts. When you upgrade a few times a year, and frontend vulns don't matter, there's really no limit to the cooldown you can set. 60 days, why not.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#125

Post by austin-cheney »

troad wrote: post #123

I'm very glad I never bought into fullstack JS/TS. My JS is frontend only, served as a compiled bundle off a server that doesn't even have a JS runtime of its own. Whatever random vulnerabilities the frontend contains are limited in blast radius to the user's own browser, and since all frontends should be untrusted anyway, there is no real security risk to the server or backend. No reason to update more than a few ti…

If you serve any third party logic, such as advertisements, your code is just as potentially compromised.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#126

Post by [deleted] »

jubilanti wrote: post #119
teddyh wrote: post #65

‘No way to prevent this’, Says Only Development Community Where This Regularly Happens ­— https://itnext.io/no-way-to-prevent-this-says-only-developme... >

Yeah funny, but npm is not the only development community where this regularly happens. The Onion article this joke refers to [1] is funny because there is a very clear and obvious reason why the U.S. has far more gun deaths per capita. This doesn't apply for npm. [1] https://theonion.com/no-way-to-prevent-this-says-only-nation...

[deleted]

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#127

Post by jgrahamc »

Shank wrote: post #115
jgrahamc wrote: post #52

And this is partly why my development machine is a Raspberry Pi that I can image any time by removing the SD card: https://blog.jgc.org/2026/04/raspberry-pi-as-isolated-ai-cod...

I mean that's lovely, but you still store confidential data, I assume, like credentials on your development machine? This doesn't solve anything but the least important "reinstall the OS post-compromise" step.

On that machine there's Claude's authentication for my account so I can run Claude on it, a public key so I can SSH to the box, and a private key for GitHub access.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#128

Post by jcgl »

pingou wrote: post #82
jcgl wrote: post #60

Earlier quoted context omitted.

On my personal machine, I run OpenSnitch. Much better defense against data exfil if you reject outbound connections to unexpected/unwanted hosts.

That wouldn't help in that case as exfiltrated data is committed to public GitHub repositories. Unless you have to accept every time an app posts or requests data from known hosts?

> That wouldn't help in that case as exfiltrated data is committed to public GitHub repositories

Correct in general that it doesn't protect against stuff like that. But this whitelisting is done per-command (in this case, the whitelisting is scoped to the node executable). I've had no need to allow node access to Git in the first place, so no problem there.

> Unless you have to accept every time an app posts or requests data from known hosts?

OpenSnitch doesn't have access to application-level information, so it has no concept of "post" or "request." It's got DNS names, layer 3 info, layer 4 info, and other such things that are visible to the kernel. Your rules get matched to network traffic based on these various properties.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#129

Post by jcgl »

gus_ wrote: post #118
pingou wrote: post #82

Earlier quoted context omitted.

That wouldn't help in that case as exfiltrated data is committed to public GitHub repositories. Unless you have to accept every time an app posts or requests data from known hosts?

Personally I don't allow outbound connections from almost any app, except web browsers to port 80/443. So nodejs, pip, ruby, curl, wget, etc, opening unexpected outbound connections is a big red flag for me. In some cases, maybe you need to allow permanently git to open outbound resquests to github.com (or gitlab, etc), but at least in my case, I'm okey allowing these connections manually. > preinstall script: bun ru…

> Personally I don't allow outbound connections from almost any app, except web browsers to port 80/443. So nodejs, pip, ruby, curl, wget, etc, opening unexpected outbound connections is a big red flag for me.

Yep, exactly. Reject by default, with reasonably judicious always-allow rules.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#130

Post by troad »

austin-cheney wrote: post #125
troad wrote: post #123

I'm very glad I never bought into fullstack JS/TS. My JS is frontend only, served as a compiled bundle off a server that doesn't even have a JS runtime of its own. Whatever random vulnerabilities the frontend contains are limited in blast radius to the user's own browser, and since all frontends should be untrusted anyway, there is no real security risk to the server or backend. No reason to update more than a few ti…

If you serve any third party logic, such as advertisements, your code is just as potentially compromised.

Only the frontend, which is already untrusted. Any risk would be restricted to individual users who used the compromised frontend to communicate something sensitive, and while that's not great, it is significantly better than the backend being compromised. A very significant reduction in blast radius.

Funnily enough, I don't actually think I do serve third party JS, though. Don't serve ads, don't use external telemetry, don't use JS CDNs. I don't think you have to go quite as far as I do, though - I imagine if your ads are Google AdSense or something, you're probably going to be fine.

Post reply on HN