I am amazed at the dates in this article. This compromise appears to have been discovered literally this morning. Incredibly fast turnaround on this article.
Shai-Hulud Returns: Over 300 NPM Packages Infected
591–600 of 797 posts
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#592The "use cooldown" [0] blog post looks particularly relevant today. I'd argue automated dependency updates pose a greater risk than one-day exploits, though I don't have data to back that up. That's harder to undo a compromised package already in thousands of lock files, than to manually patch a already exploited vulnerability in your dependencies. [0] https://blog.yossarian.net/2025/11/21/We-should-all-be-using...
For Python's uv, I think the closest thing to a cooldown is something like:
uv lock --exclude-newer $(date --iso -d "24 hours ago")
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#593Shai-Hulud is the best thing to happen for npm.
It's much easier to demonstrate a problem (twice!) than to convince a herd that there is a problem.
I hope that other languages with similar package manager (looking at you, cargo) take note.
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#594Earlier quoted context omitted.
Docker is not a sandbox. There is some work that can be done to harden it, but you're better off looking at genuinely sandboxing your dev environment
What is genuine sandboxing? Everyone waives there hands by saying this
Good question with a lot of possible answers. You can take sandboxing as far as you want, really. I typically just use bubblewrap (linux)
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#595Earlier quoted context omitted.
What is genuine sandboxing? Everyone waives there hands by saying this
Good question with a lot of possible answers. You can take sandboxing as far as you want, really. I typically just use bubblewrap (linux)
I have a perfect set up in inside docker that works.
I would love to know why bubblewrap is a superior alternative.
Here's mine https://github.com/ashishb/dotfiles/blob/067de6f90c72f0cf849...
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#596ProTip: use PNPM, not NPM. PNPM 10.x shutdown a lot of these attack vectors. 1. Does not default to running post-install scripts (must manually approve each) 2. Let's you set a min age for new releases before `pnpm install` will pull them in - e.g. 4 days - so publishers have time to cleanup. NPM is too insecure for production CLI usage. And of course make a very limited scope publisher key, bind it to specific packa…
You shouldn't have any keys anywhere at all. Use OIDC https://docs.npmjs.com/trusted-publishers Unfortunately you need to `npm login` with username and password in order to publish the very first version of a package to set up OIDC.
I'm struggling to understand why Trusted Publishers is any better.
Let's say you have a limited life, package specific scoped, IP CIDR bound publishing key, running on a private GH workflow runner. That key only exists in a trusted clouds secret store (e.g. no one will have access it from their laptop).
Now let's say you're a "trusted" publisher, running on a specific GitHub workflow, and GitHub Org, that has been configured with OIDC on the NPM side. By virtue of simply existing in that workflow, you're now a NPM publisher (run any publish commands you like). No need to have a secret passed into your workflow scope.
If someone is taking over GitHub CI/CD workflows by running `npm i` at the start of their workflow, how does the "Trusted Publisher" find themselves any more secure than the secure, very limited scope token?
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#597ProTip: use PNPM, not NPM. PNPM 10.x shutdown a lot of these attack vectors. 1. Does not default to running post-install scripts (must manually approve each) 2. Let's you set a min age for new releases before `pnpm install` will pull them in - e.g. 4 days - so publishers have time to cleanup. NPM is too insecure for production CLI usage. And of course make a very limited scope publisher key, bind it to specific packa…
Npm is what happens when you let tech debt stack up for years too far. It took them five attempts to get lock files to actually behave the way lock files are supposed to behave (lockfile version 3, + at least 2 unversioned attempts before that). It’s clear from the structure and commit history they’ve been working their asses off to make it better, but when you’re standing at the bottom of a well of suck it takes tha…
[dead]
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#598ProTip: use PNPM, not NPM. PNPM 10.x shutdown a lot of these attack vectors. 1. Does not default to running post-install scripts (must manually approve each) 2. Let's you set a min age for new releases before `pnpm install` will pull them in - e.g. 4 days - so publishers have time to cleanup. NPM is too insecure for production CLI usage. And of course make a very limited scope publisher key, bind it to specific packa…
Both NPM and Yarn have a way to disable install scripts which everyone should do if at all possible.
Good point, but until many popular packages stop requiring install.sh to operate, you'll still need to allowlist some of them. That is built into the PNPM tooling, luckily :)
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#599Earlier quoted context omitted.
Why not take it further and not update dependencies at all until you need to because of some missing feature or systems compatibility you need? If it works it works.
This works until you consider regular security vulnerability patching (which we have compliance/contractual obligations for).
This only makes sense for vulnerabilities that can actually be exploited in your particular use-case and configuration of the library. A lot of vulns might be just noise and not exploitable so no need to patch.
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#600Hundreds of people had access to publish the Zapier SDK, so it's little surprise they were eventually compromised! ( https://bsky.app/profile/benmccann.com/post/3m6fdecsbdk2u ) The e18e community are reducing dependencies in popular libraries and building tools to prevent and reduce the impact of such attacks. Join if you want to help out! https://e18e.dev/ Just this morning, after trying to make the case over the pa…
>e18e
Yay!
>Discord
...ew.