Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

aikido.dev

Post reply on HN
Print view View original

31–40 of 145 posts

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

#31

Post by jitl »

JustSkyfall wrote: post #30
insanitybit wrote: post #26

Earlier quoted context omitted.

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?

yeah, or when a dev starts the local development server (unless that server is containerized).

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

#32

Post by jerf »

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.

You will also not get very far in engineering if you have a production incident, someone proposes a thing that will mitigate it partially but significantly, and you insist that we can't deploy that mitigation because we need to do the multi-year project that will actually fix it instead. Even if we still need that project, we also need that mitigation.

Sure, solve the problem of "auditing and trusting codebases". Go for it. Shouldn't take you until, oh, let me be generous and give you until next Monday. No sweat.

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

#34

Post by csomar »

jerf wrote: post #15
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...

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.

These half-measures is why everything has gone to shits. Instead of properly auditing software, reducing the quantity and increasing the quality, we keep pushing more and more garbage where all you find is 2FA that, captcha this, not supported this, app not signed, etc..

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

#36

Post by yread »

rhdunn wrote: post #16
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)?

The what happened section mentions the addition of the `setup.mjs` and `Math_Symbol.js`, along with a change in `package.json` to add `"preinstall": "node setup.mjs"`, so presumably checking for any of those would be a good indication to check further. For example: find . -type f | grep -P "/Math_Symbol\.js$"

Crucially, Math_Symbol.js that is almost 800KB, not the innocent 1KB one from regenerate-unicode-properties

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

#37

Post by somebudyelse »

TacticalCoder wrote: post #29
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.

the irony of the update being at 1337

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

#38

Post by insanitybit »

JustSkyfall wrote: post #30
insanitybit wrote: post #26

Earlier quoted context omitted.

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?

Yes, you should separate "tests execute" into their own unprivileged workflows that don't have "deploy" secrets.

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

#39

Post by rcxdude »

jerf wrote: post #32
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.

You will also not get very far in engineering if you have a production incident, someone proposes a thing that will mitigate it partially but significantly, and you insist that we can't deploy that mitigation because we need to do the multi-year project that will actually fix it instead. Even if we still need that project, we also need that mitigation. Sure, solve the problem of "auditing and trusting codebases". Go…

Feel free to turn it off yourself, just don't be surprised when the attackers switch tactics. And don't make life harder for everyone else by pushing it as mandatory.

(if you want a better mitigation: don't automatically update dependencies in CI. At a minimum have a cooling-off period that you only bypass on manual review. This is not hard to implement and at least gives some time for alarm bells to be sounded before you're pwned. Probably while doing the updates you can also just do a quick sanity check on the changes, that'll also catch the ones using a blatant install hook)

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

#40

Post by insanitybit »

jitl wrote: post #31
JustSkyfall wrote: post #30

Earlier quoted context omitted.

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

yeah, or when a dev starts the local development server (unless that server is containerized).

Dev laptops tend to have better monitoring than CI/CD so I still think this is a better option. You can also have devs use VMs or separate dev environments like an ec2 instance.

To be clear, just solving the CI/CD portion is insufficient, but it is a massive win.

Post reply on HN