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

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

#201

Post by Yokohiii » Tue, May 19, 2026, 4:19 PM UTC

madamelic wrote: post #150

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 message…

There are prompt guard classifiers that can detect prompt injections, but they are not perfect (false positives, obfuscation) and should be only a part of the defense.

The concern is real and unsolved. I think security researchers have an advantage here because they still can fall back to manual audits if their automated analysis (or scores thereof) is off.

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

#202

Post by erikerikson » Tue, May 19, 2026, 4:25 PM UTC

sph wrote: post #181

mghackerlady wrote: post #142

Earlier quoted context omitted.

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

JS programmers today are the PHP programmers of 25 years ago. Remember how many SQL injection bugs there was at the time? Little Bobby Tables remembers. The standards haven't changed; for the vast majority of JS programmers, this is their first programming language and they have no solid foundation of architecture and security. So what you get are these overly enthusiastic newbies that want to share their latest achi…

I wrote a little PHP about 25 years ago and hated it, dropped it like a rock as soon as it wasn't my job. Before that basic, assembly, c, and c++. Then scheme, C#, Java, prolog, and others too minor to mention before I started using nodejs. My last company I chose full stack Typescript and it was great. There's a lot to love and a plenty to avoid.

You're not wrong that there's a lot of crap, a massive legacy, and some bad behavior. It is also approachable, flexible, and portable. Even if you sometimes need to say "Wat?!?"

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

#203

Post by erikerikson » Tue, May 19, 2026, 4:29 PM UTC

no-name-here wrote: post #70

kixxauth wrote: post #67

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…

Wouldn't just having devs pin/not upgrade packages accomplish about as much, have the added benefit that if a package is discovered malicious it would be removed from npm but if already vendored you’d still have the vulnerability on your vendored copy, and pinning versions seems like it would be more likely for devs to do than vendoring?

Not to support the GPs choices (they are not mine) but pinned dependencies can get grumpy over time with endless LTS migrations.

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

#204

Post by shoeb00m » Tue, May 19, 2026, 4:31 PM UTC

throwaway27448 wrote: post #121

jubilanti wrote: post #119

Earlier quoted context omitted.

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.

some Pipy packages were also attacked recently. And is even more vulnerable due to many projects using requirements.txt which doesn’t lock sub dependencies

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

#205

Post by corford » Tue, May 19, 2026, 4:36 PM UTC

MattCruikshank wrote: post #160

mapontosevenths wrote: post #77

Earlier quoted context omitted.

Despite what some people will tell you (including many in the security indistry), Docker is not a strong security boundary, and it should not be treated as one. It shares a kernel with the running system. It reminds me of the good old days when people would hand out low privilege Linux accounts and rely on the kernel to prevent privilige escalation. Docker is literally the same thing, just with extra steps. Especiall…

I've been toying with using Jart's Blink, the "tiniest x86-64-linux emulator". If it were hardened against attacks by a smart community, it seems really attractive... Then I've been toying with using WASM, with a strictly limited API surface... (API stands for what, "Attack, Please, Infiltrators"?) I'd really love to make a service which can run "untrusted" code... I want this to exist. I want it to feel like the San…

We've been leaning on Lima recently for a "dockeresque" experience with hard VM guarantees. Also keeping an eye on https://github.com/containers/crun/blob/main/krun.1.md

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

#206

Post by shoeb00m » Tue, May 19, 2026, 4:38 PM UTC

freedomben wrote: post #146

ch4s3 wrote: post #131

Earlier quoted context omitted.

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 tha…

Most of these attacks have nothing to do with installing trivial dependencies. It’s usually because the authors npm tokens got hacked; often due to github actions.

The issue is that github actions has too many security gaps that are easy to miss.

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

#207

Post by WorldMaker » Tue, May 19, 2026, 4:45 PM UTC

zahlman wrote: post #188

WorldMaker wrote: post #182

Earlier quoted context omitted.

It still seems wild that npm hasn't gone allowlist-only for pre- and post-install scripts like every other JS package manager (yarn, pnpm, Deno, Bun). Obviously it would be a breaking change that might wreck some developers' day for a little while until that allowlist is built, but it would go a long way to eliminate some of the biggest vectors for these attacks.

... Deno and Bun manage packages? I thought they were just runtimes.

Bun started out with npm compatibility as a key requirement, so has a very npm-like package manager from the beginning.

Deno at first tried to focus only on web-like/browser-like package management with a focus on full URLs ("https://mypackage.example.com/v2/mypackage.js") and importmaps (a JSON file mapping "mypackage" to a URL such as the previous example) and package/file caching over installing. Deno 2 made Node-compatibility a higher priority (partly because of Bun's competition, partly because of complaints that Deno was hard to migrate to piecemeal from existing Node codebases) and one of those initiatives was a more npm-compatible package manager out of the box (that can also speak Node package.json and manage a node_modules directory), even as Deno still encourages for greenfield projects the URL/importmap/caching approach (with the expansion that it also understands `npm:` pseudo-URLs, `jsr:` pseudo-URLs [an alternative package registry with a stronger focus on ESM and Typescript types], and `node:` pseudo-URLs [emulated node internals], beyond just browser-safe `http:` and `https:` URLs).

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

#208

Post by okanat » Tue, May 19, 2026, 4:48 PM UTC

mghackerlady wrote: post #198

sph wrote: post #181

Earlier quoted context omitted.

JS programmers today are the PHP programmers of 25 years ago. Remember how many SQL injection bugs there was at the time? Little Bobby Tables remembers. The standards haven't changed; for the vast majority of JS programmers, this is their first programming language and they have no solid foundation of architecture and security. So what you get are these overly enthusiastic newbies that want to share their latest achi…

And before PHP it was Visual Basic, and COBOL even further back. I'm convinced trying to teach people to program without them understanding the basics of how computers work will lead to this.

It is not about not teaching them, I am co-graduated with many people who do YOLO JS and AI slop right now. They had to pass the same architecture and microprocessor programming lectures.

Educated or not, there are many programmers who simply don't give a fuck. Unless you make all the IT jobs a regulated profession and enforce significant yearly recertification, the mediocres will dominate. You cannot be nice and inclusive to mediocre programmers and expect good baselines.

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

#209

Post by cyphar » Tue, May 19, 2026, 4:49 PM UTC

ErroneousBosh wrote: post #196

moebrowne wrote: post #22

Earlier quoted context omitted.

Or don't mount the Docker socket into containers

Or mount it read-only if you do, like for Traefik.

That doesn't actually do anything, connect(2) doesn't need write access to connect to a socket. If you think about it, if that did work then a socket with read-only permissions would be basically useless -- Docker uses HTTP for its API, how would the request for "read-only data" be sent without the ability to send messages?

I wrote a comment ~8 years about this[1], I'm kinda sad people still do this and seem to misunderstand just how big of a security hole they are opening...

Just don't do it. If you absolutely must then you can configure some very restrictive AuthZ plugin (but those are incredibly fickle and are almost certainly security theatre because they are basically just an application firewall).

[1]: https://news.ycombinator.com/item?id=17983623

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

#210

Post by grim_io » Tue, May 19, 2026, 4:50 PM UTC

lyu07282 wrote: post #157

grim_io wrote: post #132

Earlier quoted context omitted.

Maybe they should prove their shit works first. What a wonderful marketing opportunity! Leave it to Microsoft to blindly ignore it.

No look at the article of this post, it's by SafeDep they are in the same business as Microsoft with their Defender product line. They both publish near identical post mortems with subtle hints at how their product would've defended you against the attack. Why should Microsoft fix the cause instead of selling the cure to each business individually?

Is the complete loss of trust in the platform they want to profit off a better alternative?