Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

‘No way to prevent this’, Says Only Development Community Where This Regularly Happens

­— <https://itnext.io/no-way-to-prevent-this-says-only-developme...>

> In regards to the whole ecosystem: TC39 should take a look into adding a better standard library to JS itself, which would reduce the amount of one-liner packages.

I concur, the best part of working with Deno way back was its standard library [0] and overall complete dev environment. It is just so damn obvious that a runtime comes with an integrated test runner and assertion library.

0 - https://docs.deno.com/runtime/reference/std/

> 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) !

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.

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.

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.

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

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.

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

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.

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

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

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.

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.

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.

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

Because of course it’s npm

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

it seems obvious to me the ability to push code to public repositories shluld be tied to real human identity.

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

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?

are these fixed removed now?

another day, another npm hack.

[flagged]

[flagged]

[dead]