Live data from Hacker News

Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

safedep.io

101–110 of 329 posts

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

#101
post #20

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

> Make sure you're running a rootless VM engine (e.g. podman instead of docker) ! Aren't most people running docker rootless (at least on Linux)? Does podman do more?

> Aren't most people running docker rootless (at least on Linux)? Does podman do more?

In the HPC space Apptainer (previously "Singularity") was created precisely due to (multi-)user-level access, especially with the use of NFS.

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

#102

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

Using code from these repositories should be considered the same as licking toilet seats at highway rest stops. There’s something wrong with you if you do it.

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

#103

Earlier quoted context omitted.

Why not run a proper virtual machine?

That's the direction container runtimes are trending Amazon has been doing it with Firecracker for a while and Kata containers is another popular one https://github.com/firecracker-microvm/firecracker https://github.com/kata-containers/kata-containers

I think Google took a different approach with gVisor and limited userspace kernel interface, tradeoffs...

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

#104
post #20

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

> Make sure you're running a rootless VM engine (e.g. podman instead of docker) ! Aren't most people running docker rootless (at least on Linux)? Does podman do more?

I'd guess that most people who run Docker on linux install it through their distro's package manager, which has a dockerd running as root.

On Debian derivatives, you need some kind of extra privs to even talk to it (being a member of the "docker" group, iirc).

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

#105
post #56

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.

This is what many AI supply-chain security startups (like the one that posted the article) are already doing with all NPM packages, so save yourself the Claude tokens. All of these compromises were detected within minutes, but it takes some time (<1 hour) for NPM to unpublish all of the affected packages.

Sorry for my ignorance, but then couldn't we build this into NPM itself? So before a package is publicly available it would be quaranteened and checked.

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

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

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

#107
post #80

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.

Without node, how do you control your cloud resources? Cloudflare requires wrangler. AWS has a lot of node clis. Etc.

From CI pipelines with pinned package versions and OIDC instead of permanent secrets limited, least privileges.

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

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

Isn't this more like a "Macs don't have viruses" type scenario though?

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

#109
> 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/

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

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

> Says Only Development Community Where This Regularly Happens

We've had such issues on other places as well... Shai-Hulud got into Maven [1] and PHP Composer [2], typosquatters got into Maven [3], and it's not new either [4].

No one is safe from skiddies, much less from nation state actors.

[1] https://thehackernews.com/2025/11/shai-hulud-v2-campaign-spr...

[2] https://semgrep.dev/blog/2026/malicious-intercom-php-package...

[3] https://www.esecurityplanet.com/threats/malicious-jackson-lo...

[4] https://socket.dev/blog/malicious-maven-package-exfiltrates-...

Post reply on HN