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.
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..
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.
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)
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)
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.
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.
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).
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.
"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."
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.
> 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>
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.
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.
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.
Ok, I can agree it is a boring comment, but who is worse?
NPM gets targeted both because it is popular and because there is a wider attack surface (lots of little packages promoted by a huge variety of users) I have a high schooler who published work a couple weeks ago. This is good, but it comes with downsides. Maybe a couple more speed bumps or classifiers would be helpful. Maybe a consolidation of under maintained projects and deprecation is in order.
Other than what happened with 'xz', which was upstream of it getting packaged, how many times has this happened in the debian packages system? Also very popular.
No other package manager is worse than NPM. Outside of its 'popularity', there are a 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.
- Post install scripts execute external code by default upon downloading dependencies.
All of this comes by default in the ecosystem and we continue to see more shai-hulud worms all easily targeting NPM. Not even signed packages are enforced by default either.
aikido.dev: SAST, AI code analysis and therefore a website that uses 100% CPU and prevents scrolling.
To the point of the article: I don't know why GitHub still allows the release feature. It is complete insanity. Tar archives must be constructed manually and checked for leaked keys etc.
> Update — August 4, 2026, 13:37 CEST: At least 868 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.
This is such lazy or click baiting writing. Who cares how many installations there are per month normally? The high install numbers are almost certainly from running in CI where such secrets don’t exist. How many installs actually occur in a non CI environment and of those how many were the compromised version?
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 incentive to reduce waste and improve security globally.
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.
It's time pre-install / post-install hooks were killed off. Start with a moratorium on any new ones.
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.
(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)
Anti-tank measures are unnecessary because they can just use missiles
(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)
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.
To be clear, just solving the CI/CD portion is insufficient, but it is a massive win.
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).
For example:
https://x.com/jaredwray
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.
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.
https://github.blog/changelog/2026-07-28-npm-publish-time-ma...
Maybe that's the idea. Regards, the <insert your favourite 3 letter agency here>
Unless...
Maybe in 6 months.
How many instances of this are required before npm package maintainers learn?
NPM gets targeted a lot because it's popular. That's it.
Ok, I can agree it is a boring comment, but who is worse?
NPM gets targeted both because it is popular and because there is a wider attack surface (lots of little packages promoted by a huge variety of users) I have a high schooler who published work a couple weeks ago. This is good, but it comes with downsides. Maybe a couple more speed bumps or classifiers would be helpful. Maybe a consolidation of under maintained projects and deprecation is in order.
- 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.
- Post install scripts execute external code by default upon downloading dependencies.
All of this comes by default in the ecosystem and we continue to see more shai-hulud worms all easily targeting NPM. Not even signed packages are enforced by default either.
To the point of the article: I don't know why GitHub still allows the release feature. It is complete insanity. Tar archives must be constructed manually and checked for leaked keys etc.
This is such lazy or click baiting writing. Who cares how many installations there are per month normally? The high install numbers are almost certainly from running in CI where such secrets don’t exist. How many installs actually occur in a non CI environment and of those how many were the compromised version?
CI usually has the most privileged secrets anywhere in a company lol
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 incentive to reduce waste and improve security globally.