Live data from Hacker News

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

aikido.dev

61–70 of 145 posts

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

#61

No way to prevent this says only package manager where this regularly happens

This is the most boring comment posted on every one of these. NPM is by no means the worst offender here and offers a ton of solutions to this, lots of package managers are behind it or equivalent. NPM gets targeted a lot because it's popular. That's it.

It’s correct that NPM is not unique but it is the worst for cultural reasons: no other ecosystem started with such a limited language, which lead to the culture of publishing tons of small packages working around things which everything else had builtin. A Python project which has a hundred dependencies is considered quite large but the median React project had north of 30 thousand for years and years.

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

#62
OW. That's gonna leave a mark.

It sucks that we have this glass-jaw dependency system, which is really the main reason these supply chain attacks work.

Really hard to clean up, too. These days, you (being the blackhat) would likely send agents to leverage every compromised repo/app/Web site, almost the instant it comes online, so even if the original mess is cleaned up, there's still a ton of knock-on compromises.

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

#63
post #36
post #16

Earlier quoted context omitted.

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

when i was searching i got a heartattack when i saw Math_Symbol.js. Thankfully my agent was able to figure it out.

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

#64
post #28

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/

I ended up asking my agent with auto mode:

can you search all installed node modules for any sign of the shai hulud supply chain attack? What happened Every package in the family received two new files, setup.mjs and Math_Symbol.js, along with a "preinstall": "node setup.mjs" entry added to each package.json. Anyone who ran npm install against an affected version would have had setup.mjs execute automatically before their install completed.

setup.mjs is a heavily obfuscated dropper. Its only job is to silently download the Bun JavaScript runtime from github[.]com/oven-sh/bun/releases/download/bun-v1.3.13/ and use it to execute the real payload, Math_Symbol.js:

execFileSync(, ['/Math_Symbol.js'], { stdio: 'inherit', cwd: }) The Math_Symbol.js is a heavily obfuscated 728 KB JavaScript file containing credential stealers that harvest secrets from the victim's environment, encrypt the findings, and exfiltrate them to a public GitHub repository whose description reads "Shai-Hulud: Here We Go Again". The payload also contains worm-like propagation functionality to infect packages of other maintainers that have installed one of the compromised packages.

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

#65

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

Highly recommend `fd` for the sheer speed:

    fd -HI "^(setup\.mjs|Math_Symbol\.js|math_init\.js)$"
1. https://github.com/sharkdp/fd

2. `brew install fd`

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

#66
post #32
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…

> You will also not get very far in engineering if

Man, I wish.

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

#67

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.

LLMs are better at attacking than writing secure code.

LLMs aren't terrible at securing systems, humans are bad at using secure systems and typically disable measures with insecure workarounds.

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

#68
post #50

Earlier quoted context omitted.

This is the most boring comment posted on every one of these. NPM is by no means the worst offender here and offers a ton of solutions to this, lots of package managers are behind it or equivalent. NPM gets targeted a lot because it's popular. That's it.

No other package manager is worse than NPM. Outside of its 'popularity', there are several fundamental reasons why this continues to happen to NPM: - Imported packages are not pinned by default. - Typescript / Javascript's lack of a standard library encourages the developer to import more packages into their codebase to address the short-comings which increases the risk of importing a bad package. - Post install scri…

> Imported packages are not pinned by default

What do you mean? The lockfile of all package managers is there for pinning the exact versions. For yarn and pnpm, installs on CI run automatically from lockfile only, for npm I think you still need to run `npm ci` instead of `npm install`. But this guarantees that no new versions get pulled automatically in by CI.

> Typescript / Javascript's lack of a standard library

That's true, but it's not an issue of the package manager / registry

> Post install scripts execute external code by default upon downloading dependencies.

They are disabled by default in all package managers now, the user needs to manually allow them

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

#69
post #61

Earlier quoted context omitted.

This is the most boring comment posted on every one of these. NPM is by no means the worst offender here and offers a ton of solutions to this, lots of package managers are behind it or equivalent. NPM gets targeted a lot because it's popular. That's it.

It’s correct that NPM is not unique but it is the worst for cultural reasons: no other ecosystem started with such a limited language, which lead to the culture of publishing tons of small packages working around things which everything else had builtin. A Python project which has a hundred dependencies is considered quite large but the median React project had north of 30 thousand for years and years.

I think that's barely meaningful. Which of the compromised packages would have been part of any reasonable stdlib?

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

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

iirc does pnpm not allow them by default. But even if we killed them off there would still be a chance of the malware hooking into something else or only working in cli applications.

The latest version of all node package managers (npm, yarn, pnpm) now deny this by default. pnpm was ahead of the curve.
Post reply on HN