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

Join the discussion

• Hacker News
• 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.

  by ethanwillis
• 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.

  by pixl97
• Oh boy, it's a big one.
  by codeduck
• > 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.

  by TacticalCoder
• I am kind of surprised GitHub doesn't seem to have built a simple classifier for public repos to proactively lock the account of anyone uploading such obviously fishy things (for their own good, at least before the repo is publicly findable), so it can't be used as a rendezvous.

  Surely Github's software is good enough that an intern can slop the 80/20 together in a day? It would be an actually good use of AI spending.

  by avaer
• > I am kind of surprised GitHub doesn't seem to have built a simple classifier for public repos to proactively lock the account of anyone uploading such obviously fishy things (for their own good, at least before the repo is publicly findable), so it can't be used as a rendezvous.

  Maybe that's the idea. Regards, the <insert your favourite 3 letter agency here>

  by hulitu
• GitHub announced this a while back:

  https://github.blog/changelog/2026-07-28-npm-publish-time-ma...

  by abhisek
• Couldn't GitHub detect a Shai-Hulud exfil repo being created and just... block it? Given that it's a worm, the attacker wouldn't be able to adapt all that quickly.
  by phyzome
• It's baffling that this hasn't been done after the 6th(?) time in the past year.
  by richbell
• We're talking about Microsoft, who created a notepad.exe that can run an RCE with an LLM bypass prompt.

  In the previous Miasma waves, Microsoft was so overwhelmed that they delayed the VSCode extension installs for a couple days with a timeout; literally not understanding what was going on and neither how the malware was spreading.

  by cookiengineer
• Once again, I ask myself: should we start "shaming" developers who don't use isolation? It still seems I am the exception and most people run their dev environment with full permissions. Why?

  I also wrote an article (https://evertheylen.eu/p/shame-devs-without-isolation/) to flesh out my thoughts, but I'd be really happy to discuss this in the comments.

  by evertheylen
• I think it’s premature before a lot of tools improve to make that more workable: for example, if you use AWS how realistic is maintain separate IAM for each tool you run and map the right one into a sandbox for each tool? To use your editor’s GitHub integration with a token which can do basic operations and only retrieves a high-privilege token with a hardware presence check when you cut a release?

  Theoretically you can do it but the friction is enough to make it non-viable.

  by acdha
• Yes, it gets boring that each time one of these supply chain attack article appears everybody starts talking about cooldowns, 2FA, MFA, etc. Just don't give Node the permissions to your complete filesystem / network.
  by vhcr
• Updated my docs covering these attacks since 2025:

  1. NPM Supply Chain Attack Techniques: https://npm-supply-chain-attack-techniques.pagey.site/

  2. NPM Ecosystem Threat Report: https://npm-supply-chain-attacks-25-26.pagey.site/

  by freakynit
• echo "min-release-age=5" >> ~/.npmrc

  This should be your default minimum if you work with node.

  by jesse_dot_id
• It's time for all developers to learn about devcontainers and use them consistently. They're super easy to setup and run and would protect from most of what this worm does. https://code.visualstudio.com/docs/devcontainers/containers is the best guide to get started if you use vscode.
  by TimJRobinson
• They help only to the extent that you have completely isolated credentials: the hard part isn’t the container, it’s things like fastidiously using separate least-privilege credentials everywhere and not using tools or editor integrations which don’t support that style of work. Once you map your GitHub or AWS token into a container, it’s no longer useful as a security boundary.
  by acdha
• I've been building an OSS tool to detect software supply-chain attacks: https://github.com/ossillate-inc/packj

  Packj uses static+dynamic code/behavioral analysis to scan for indicators of compromise (e.g., spawning of shell, use of SSH keys, network communication, use of decode+eval, etc). It also checks for several metadata attributes to detect impersonating packages (typo squatting).

  by ashishbijlani
• 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)?
  by mittermayr
• find . -type d -name node_modules -prune -exec find {} \( -name setup.mjs -o -name math_init.js -o -name Math_Symbol.js \) \; 2>/dev/null
  by orheep
• This article has a lot of information and ways to check & clean: https://safedep.io/keyv-npm-supply-chain-compromise/
  by byutifu
• 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`

  by chime
• 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$"

  by rhdunn
• 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.

  by ChrisMarshallNY
• 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.

  by xnorswap
• You'll just end up with people running `./configure` scripts or whatever instead. The solution I've currently landed on is:

  1. Audit build scripts/ proc macros for rust code (and mark with cargo-vet).

  2. Have an isolated workflow for "build/test/push artifact to temporary place" (s3, github artifact, whatever). No API keys in this workflow.

  3. Have another workflow that has the API keys to publish that grabs the artifact and then places it into a registry.

  This creates clear separation of "code runs here" and "environment has privileges".

  In my own slop-driven programming language I have build scripts declare their capabilities upfront so that you can statically reason about them (same with runtime permissions).

  by insanitybit
• 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.
  by mechazawa
• 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...
  by jitl