Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

moi2388

Because of course it’s npm

fnoef

I’m honestly at a point where I’m afraid to update any of my project’s dependencies, and I’m also afraid to run the locally without some locked down VM

wlkr

At this point I would very much like to get off Mr Bones' Wild Ride but I fear this is going to continue to happen because, from my own exploration at least, a large number of commercial detection strategies are directed at the repo/device/developer level when loading/using a package. This seems analogous to how we tackle email spam and general malware. It means that there is almost always a target valuable enough for bad actors to continue trying. However, unlike email (mostly...), package managers are centralised authorities (and anything out-of-band is surely the developers problem?). My ill-informed feeling is that we might need to change the culture of lazy versioning with rapid releases and focus on stable, deeply scanned versions at registries. There will be some effect of volume and scale so I could be off, but it still seems telling that this impacts high-churn languages more often. I don't know, I would love a comprehensive article that explores the landscape right now.

ares623

If you think about it, this is actually a new kind of security. Security by numbers. Overwhelm the attackers with so many compromised services and devices that they get a reverse denial of service. It's inspired by nature in herd animals.

mentalgear

The situation is getting crazy ... personally I have already uninstalled node, python and all package managers from my machine and instead only use them in devcontainers / VMs. But even if the dev community comes up with super hardened security, I fear in at least a year the models will be good enough in social engineering that we are still running a losing game.

mentalgear

> Docker Container Escape > The payload checks for the Docker socket and, if present, attempts container escape through three sequential methods: So even if you're running devcontainers / VMs, these worms are already trying to escape. Make sure you're running a rootless VM engine (e.g. podman instead of docker) !

jonkoops

Another day, another pre/postinstall script executed that could have easily have been prevented by any sane package manager. NPM really desperately needs an 'allowBuilds' style allowlist [1] and 'approve-builds' command [2]. 1. https://pnpm.io/settings#allowbuilds 2. https://pnpm.io/cli/approve-builds

knlsn

are these fixed removed now?

kunalsin9h

As similar to 1st wave of Shai Hulud, this also got it through opentionalDependency. intresting

somelamer567

In the fictional universe of William Gibson's Sprawl trilogy, it is legal and normal for defenders to go kinetic on cyberattackers. How long until it is simply easier for governments and big business in the countries victimised by these criminal groups, to find the path of least resistance and go after them personally?

Outlook5813

another day, another npm hack.

AgentME

Another supply chain attack found and blocked in a day. Everyone regularly using npm to install new packages should be using npm's min-release-age setting to avoid package versions that are newer than a few days old to avoid most attacks in practice like this. You can set it to two days with `npm config set min-release-age=2` for example. https://cooldowns.dev/ has info about equivalent settings in other dependency managers like PyPI and Cargo.

rubnogueira

aube (npm/yarn/pnpm drop-in alternative) now has a "jailBuilds" flag that restricts access to network/filesystem access. https://aube.en.dev/package-manager/jailed-builds.html But this feels like a cat/mouse game.

CafeRacer

i run all my stuff in vm's built with nix not as easy as docker, but i have a few bash scripts that simplify things for me a lot i hope that this protects me from the sweep attacks at least

aa-jv

Node is the Visual Basic of our day, if Visual Basic had the ability to update itself from a thousand strangers, any minute of the day, without the user-developer having any clue what is going on behind the scenes unless they apply the very skills that would have precluded their use of Node/Visual Basic in the first place. All that ease-of-development is being paid for by ease-of-rooting.

jgrahamc

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...

Havoc

Pretty wary of the entire JS/nodejs ecosystem at this stage.

nojs

One solution I haven’t seen recommended much is to have a Claude instruction/skill that explicitly audits the diff of every upgrade, and force this manual audit as part of your upgrade workflow. This seems like it would work pretty reliably.

teddyh

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

kixxauth

Vendor your dependencies, clone or port them where needed, and freeze them. Most good packages these days do not have a deep dependency tree, and we should stop using the ones that do. I spent a week with claude and codex re-implementing several packages which had dependency trees deeper than I would like. Most of these packages are trivial to clone. "But now you're not getting the upstream fixes" they will say. "So what?" I reply