Keyv and friends compromised in active Shai-Hulud supply chain attack • Hacker News Board

Re: Keyv and friends compromised in active Shai-Hulud supply chain attack

#21

Post by rcxdude » Tue, Aug 04, 2026, 2:51 PM UTC

TeMPOraL wrote: post #6

insanitybit wrote: post #4

Earlier quoted context omitted.

> almost certainly from running in CI where such secrets don’t exist. CI usually has the most privileged secrets anywhere in a company lol

CIs having per-package installs : version ratio > 1 are fundamentally dumb idea in the first place. In a way, this teaches us that there is something as too much reliability in an ecosystem. Specifically, Github is apparently reliable enough that its occasional outages are insufficient to kill all the companies running these dumb CI setups that redownload packages from the Internet every build - so there's no incenti…

Redownloading and automatically updating to the new version are pretty orthogonal. You can have a solution which caches the packages but would still update to a new version or a solution which redownloads the (verifiably) same package each time. Vendoring libraries stops both but it's the automatic updates which are the biggest risk factor.

Re: Keyv and friends compromised in active Shai-Hulud supply chain attack

#22

Post by jitl » Tue, Aug 04, 2026, 2:56 PM UTC

rcxdude wrote: post #19

jerf wrote: post #15

Earlier quoted context omitted.

Nobody is claiming this is a complete solution to security. I would call this "necessary but not sufficient". You won't get far as an engineer if you refuse to implement "necessary but not sufficient" changes because the change doesn't in and of itself one-shot the entire problem.

The fact that it's not sufficient also largely means it's not necessary either, because the real solution is auditing and trusting the codebase as a whole. All you do when disabling install hooks is make a lot of situations much more difficult to handle.

"make no mistakes" is not the "real solution"

Re: Keyv and friends compromised in active Shai-Hulud supply chain attack

#23

Post by wolfi1 » Tue, Aug 04, 2026, 2:59 PM UTC

cute_boi wrote: post #17

I think npm can use chatgpt/claude for each published package to detect these types of attack? And if it sees they can restrict the package from making any changes.

the remedy is worse than the disease

Re: Keyv and friends compromised in active Shai-Hulud supply chain attack

#24

Post by sysguest » Tue, Aug 04, 2026, 2:59 PM UTC

jitl wrote: post #13

xnorswap wrote: post #5

At this point, any package adding a pre-install hook where there previously was not one should be denied and treated with extreme suspicion. It's time pre-install / post-install hooks were killed off. Start with a moratorium on any new ones.

yeah but they can just put the dropper, etc in index.js, so that it runs at import time rather than at install time, no? i guess first-install time is often a privileged developer machine, and will execute in a "server"-like runtime such as Node, Bun, Deno. but blocking preinstall scripts is basic first aid...

well Deno has the necessary ingredients for defense: file-system permission by path

Re: Keyv and friends compromised in active Shai-Hulud supply chain attack

#25

Post by rcxdude » Tue, Aug 04, 2026, 3:01 PM UTC

jitl wrote: post #22

rcxdude wrote: post #19

Earlier quoted context omitted.

The fact that it's not sufficient also largely means it's not necessary either, because the real solution is auditing and trusting the codebase as a whole. All you do when disabling install hooks is make a lot of situations much more difficult to handle.

"make no mistakes" is not the "real solution"

Neither is 'close the gate with no fence on either side of it'. If you want to run code, you either need to run it in a sandbox or trust it. Choosing to run only part of the code is not really a solution.

(if you want to disable such hooks yourself, then you may get some security by diversity because you're not using the common configuration. But if it becomes the default then these worms will switch to a different vector)

Re: Keyv and friends compromised in active Shai-Hulud supply chain attack

#26

Post by insanitybit » Tue, Aug 04, 2026, 3:10 PM UTC

jitl wrote: post #13

xnorswap wrote: post #5

At this point, any package adding a pre-install hook where there previously was not one should be denied and treated with extreme suspicion. It's time pre-install / post-install hooks were killed off. Start with a moratorium on any new ones.

yeah but they can just put the dropper, etc in index.js, so that it runs at import time rather than at install time, no? i guess first-install time is often a privileged developer machine, and will execute in a "server"-like runtime such as Node, Bun, Deno. but blocking preinstall scripts is basic first aid...

Prod tends to have less privileges than CI/CD. CI/CD tends to be full admin, so it's far more sensitive. Prod tends to have tooling for detecting breaches, better logging, etc. People tend to use containers, which act as a sandbox.

Prod also won't be wormable the way that CI/CD is. With CI/CD I can own another dev, use their creds to push another malicious build script, etc. "Attacker is in my prod env" isn't wormable.

Yes, capabilities in prod would be hugely beneficial but removing CI/CD is massive as a win.

Re: Keyv and friends compromised in active Shai-Hulud supply chain attack

#27

Post by ethanwillis » Tue, Aug 04, 2026, 3:11 PM UTC

You know with all this AGI swirling around nowadays that is stronger than nation state hackers you think one of these companies would demonstrate just how capable they are by defending public infrastructure.

Unless...

Maybe in 6 months.

Re: Keyv and friends compromised in active Shai-Hulud supply chain attack

#28

Post by byutifu » Tue, Aug 04, 2026, 3:15 PM UTC

mittermayr wrote: post #9

Does anyone happen to have a grep or similar that helps me check if this is showing up anywhere in the trillions of files in node_modules (or pnpm store)?

This article has a lot of information and ways to check & clean: https://safedep.io/keyv-npm-supply-chain-compromise/

Re: Keyv and friends compromised in active Shai-Hulud supply chain attack

#29

Post by TacticalCoder » Tue, Aug 04, 2026, 3:18 PM UTC

codeduck wrote: post #20

Oh boy, it's a big one.

> Oh boy, it's a big one.

Yup the "Update" in TFA is scary:

"Update — August 4, 2026, 13:37 CEST: At least 434 packages (across 1381 versions) have been compromised by the worm, with a combined total of over 2 billion monthly installs at the time of writing."

Lots of pain ahead.

Re: Keyv and friends compromised in active Shai-Hulud supply chain attack

#30

Post by JustSkyfall » Tue, Aug 04, 2026, 3:21 PM UTC

insanitybit wrote: post #26

jitl wrote: post #13

Earlier quoted context omitted.

yeah but they can just put the dropper, etc in index.js, so that it runs at import time rather than at install time, no? i guess first-install time is often a privileged developer machine, and will execute in a "server"-like runtime such as Node, Bun, Deno. but blocking preinstall scripts is basic first aid...

Prod tends to have less privileges than CI/CD. CI/CD tends to be full admin, so it's far more sensitive. Prod tends to have tooling for detecting breaches, better logging, etc. People tend to use containers, which act as a sandbox. Prod also won't be wormable the way that CI/CD is. With CI/CD I can own another dev, use their creds to push another malicious build script, etc. "Attacker is in my prod env" isn't wormabl…

Wouldn't the dropper get executed once tests are run within CI though?