Live data from Hacker News

Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

safedep.io

61–70 of 329 posts

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

#61

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?

When you have AI models finding vulnerabilities by themselves in a for-loop, it isn't long before there is no human to go kinetic on.

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

#62
post #39

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

[dead]

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

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

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

#66

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

Why not run a proper virtual machine?

I dunno, why own a car when you could ride your bike instead? They’re just different things and people may choose to use one over the other for a variety of reasons.

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

#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 what?" I reply

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

#68
post #9
post #5

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

Wondering about Mr Bones' Wild Ride and suspecting it might be a reference to the 1991 movie Nothing But Trouble I took a look, and found I had remembered it wrong. The roller coaster in that movie was called Mr Bonestripper, https://www.youtube.com/watch?v=NEZEgd8GjJc . Instead it comes from Roller Coaster Tycoon 2, https://knowyourmeme.com/memes/mr-bones-wild-ride . As for the comparison with spam, there we kind of…

There's also Mr. Toad's Wild Ride at Disney parks, https://en.wikipedia.org/wiki/Mr._Toad%27s_Wild_Ride

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

#70

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?
Post reply on HN