Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised • Hacker News Board

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

#141

Post by zarzavat » Tue, May 19, 2026, 2:25 PM UTC

ajross wrote: post #95

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

The Node ecosystem happens to be more vulnerable for social and software design reasons, it's true. But people need to be aware that PyPI and Cargo et. al. are not in any fundamental way less vulnerable. This will happen there too.

To expand on this, PyPI is slightly less vulnerable because Python users tend to install mega packages (such as numpy or django) and do not frequently interact with their package manager. There is also not a culture of using sub-dependencies.

Cargo is essentially the same as NPM though, it's only "safer" because it's less popular.

Although the situation on NPM is extremely uncomfortable, you're probably less likely to get hit if you take reasonable precautions than on PyPI, simply because NPM is getting scanned more often. Most of these attacks on NPM have been detected and pulled days before my min age kicks in. A sleeper attack on PyPI could be devastating.

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

#142

Post by mghackerlady » Tue, May 19, 2026, 2:26 PM UTC

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…

Also, I feel like a lot of fullstack JS is written by people who started with frontend JS and don't have nearly enough backend experience

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

#143

Post by rubiquity » Tue, May 19, 2026, 2:26 PM UTC

HWR_14 wrote: post #80

mentalgear wrote: post #12

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.

AWS has CLIs and SDKs in many languages.

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

#144

Post by Rohansi » Tue, May 19, 2026, 2:26 PM UTC

perkovsky wrote: post #96

jonkoops wrote: post #17

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

Agree. Postinstall scripts should be explicit opt-in, not ambient capability. Most packages should not need arbitrary code execution during install. And when they do, that should be obvious during review. The default should probably be: install files, don’t run code.

If postinstall scripts are restricted the people behind these attacks will switch to something else. Package code is executed automatically by Node when imported, which could be a good replacement. It'll probably run when tests run instead but it's still going to run for most people.

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

#145

Post by erikerikson » Tue, May 19, 2026, 2:28 PM UTC

wavemode wrote: post #138

ZiiS wrote: post #133

Earlier quoted context omitted.

It is your development machine's AWS keys they want. The server's keys should be too finly scooped anyway.

I would imagine it's the opposite. Most dev's machines can't query the prod database, for example, whereas a prod server can.

Nope, they've been targeting credentials so they can deploy whatever they like into prod. They prefer the build machine with it's broader rights than the individual dev boxes.

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

#146

Post by freedomben » Tue, May 19, 2026, 2:28 PM UTC

ch4s3 wrote: post #131

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

NPM by virtue of its popularity and the vagaries of the ecosystem is always going to be a prime target for attackers, and people (maintainers) will always be a weak point.

I agree generally, but I also think it's important to point out that in the NPM ecosystem it is culturally acceptable and even encouraged to install even trivial dependencies to avoid reinventing the wheel. Philosophically I completely agree with this, though practically we see the result and it is not good. The left pad debacle should have been a huge wake up call, but not really much seems to have changed after that.

As long as developers in the ecosystem are cavalier about installing huge chains of dependencies, NPM will be an attractive target for attackers.

Even though we wish it were not so, cultural problems seem to be the hardest technical problems to solve.

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

#147

Post by pennomi » Tue, May 19, 2026, 2:29 PM UTC

jeswin wrote: post #72

Maakuth wrote: post #26

Earlier quoted context omitted.

The docker CLI tool is normally executed with user privileges, but there's dockerd, a daemon running as root that actually does the container execution.

Installing docker doesn't require root. "Rootless mode lets you run the Docker daemon and containers as a non-root user." https://docs.docker.com/engine/security/rootless/ This is how docker is best installed on Linux, and there's a convenience script for it as well ( https://get.docker.com/rootless ). I am surprised that's not how people are using docker.

If it’s not default, most people won’t do it.

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

#148

Post by mghackerlady » Tue, May 19, 2026, 2:29 PM UTC

Havoc wrote: post #53

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

JS is a fine frontend language I guess, if you're willing to hand-roll your own code instead of using frameworks and junk. Whoever decided that JS deserves to run as a backend is an idiot who should not be trusted to evaluate languages anymore, lest they decide cobol is a good idea

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

#149

Post by gabdpipi » Tue, May 19, 2026, 2:30 PM UTC

ch4s3 wrote: post #131

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

NPM by virtue of its popularity and the vagaries of the ecosystem is always going to be a prime target for attackers, and people (maintainers) will always be a weak point.

Yeah I was thinking the difference between open source and enterprise to mitigate this is a simple hardware security module right?

If the attackers spearfish folks who hold “keys to the castle” and everything is digital it’s game over no matter what ecosystem.

Those things should be locked down by “something you have” because that’s much more difficult.

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

#150

Post by madamelic » Tue, May 19, 2026, 2:36 PM UTC

nojs wrote: 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.

Super dumb question as someone who has been using some form of AI for dev since 2023:

How does having an AI audit external code help? Can they not be prompt injected to ignore a malicious change?

I guess I am sort of concerned that they are a pretty thin layer and even if you put "DO NOT ALLOW PROMPT INJECTION", it's a bit like saying "make no mistakes". There _is_ a priority between `system` and `user` level messages as I had recalled, so a specifically made tool that has its own system prompt should prevent injection while asking Claude CLI could still allow for prompt injection.

What are your thoughts and experience?