▲ 391 points
back
313 comments
At this point lifecycle script should be disabled by default in NPM.
It's a convenience feature that provides built-in Arbitrary Code Execution (even for transient dependencies), and every one of these widespread NPM worm style attacks has propagated through it, because of the default setting. Also enabling it for one command shouldn't automatically permit all transient dependencies to run lifecycle scripts, it should be required to explicitly mark each dependency to limit it to where it's absolutely necessary.
The vast majority of NPM packages do not depend on these scripts, and you should disable them globally if you haven't already.
There's an RFC for this: https://github.com/npm/rfcs/pull/868
Or simply use pnpm.
Yeah. Or they should run in a sandbox. I would have no problem with a post install script which ran arbitrary commands in the context of the installed package itself. But arbitrary scripts + user level permissions is a recipe for disaster.
That said, packages could still just run whatever junk they want when they first get imported in a program.
“No way to prevent this” says only package manager where this regularly happens.
Is there anything about npm that makes it particularly susceptible to these attacks, other than the fact that it's the most popular package manager of all?
OWNED BY MICROSOFT
At a certain point, is it better to just turn off Dependabot and freeze all NPM packages (minor/patch version and all), rather than continuously update? Particularly for frontend packages, meaningful security fixes seem less likely than supply chain attacks these days.
It's a sad state of affairs, for sure - but is there a reason we can't just switch our frontends to static BOMs, and trust that NPM at least gets their "you can't republish to an old version" bare-minimum constraint right?
> At a certain point, is it better to just turn off Dependabot and freeze all NPM packages (minor/patch version and all), rather than continuously update?
But then the compliance team gets annoyed because some CVE with a CVSS score of 3.1 that has a patch available sits unfixed.
Enforce a “seasoning” period, for example don’t let any pull pull versions newer that 30 days. Perhaps with an exception for versions that address known CVEs.
Yes. This is partially why other ecosystems don’t see as many supply chain attacks.
The situation is getting crazy ... personally I have already uninstalled node, python and all package managers from my machine and instead only use them in devcontainers / VMs.
But even if the dev community comes up with super hardened security, I fear in at least a year the models will be good enough in social engineering that we are still running a losing game.
I want to go all in on zed now that it's 1.0 but it's security model is all or nothing AFAIK - either I allow it to download and install unknown to me NPM packages whenever it wants with no notice to me, or I turn off all LSP functionality. And then I keep seeing news like this.
> In regards to the whole ecosystem: TC39 should take a look into adding a better standard library to JS itself, which would reduce the amount of one-liner packages.
I concur, the best part of working with Deno way back was its standard library [0] and overall complete dev environment. It is just so damn obvious that a runtime comes with an integrated test runner and assertion library.
> Docker Container Escape
> The payload checks for the Docker socket and, if present, attempts container escape through three sequential methods:
So even if you're running devcontainers / VMs, these worms are already trying to escape.
Make sure you're running a rootless VM engine (e.g. podman instead of docker) !
At this point I would very much like to get off Mr Bones' Wild Ride but I fear this is going to continue to happen because, from my own exploration at least, a large number of commercial detection strategies are directed at the repo/device/developer level when loading/using a package.
This seems analogous to how we tackle email spam and general malware. It means that there is almost always a target valuable enough for bad actors to continue trying. However, unlike email (mostly...), package managers are centralised authorities (and anything out-of-band is surely the developers problem?).
My ill-informed feeling is that we might need to change the culture of lazy versioning with rapid releases and focus on stable, deeply scanned versions at registries. There will be some effect of volume and scale so I could be off, but it still seems telling that this impacts high-churn languages more often.
I don't know, I would love a comprehensive article that explores the landscape right now.
This list is incomplete - at least one other package (nx-console VS code extension; 2.2M downloads) was compromised yesterday with this worm: if suitably qualified/connected people are reading this, it could be worth following that dependency chain too in case there are more. See here:
https://github.com/nrwl/nx-console/security/advisories/GHSA-...
PS: I posted on HN to try and alert people right after it was compromised but sadly got almost no upvotes :-(
Node is the Visual Basic of our day, if Visual Basic had the ability to update itself from a thousand strangers, any minute of the day, without the user-developer having any clue what is going on behind the scenes unless they apply the very skills that would have precluded their use of Node/Visual Basic in the first place.
All that ease-of-development is being paid for by ease-of-rooting.
If you think about it, this is actually a new kind of security. Security by numbers. Overwhelm the attackers with so many compromised services and devices that they get a reverse denial of service. It's inspired by nature in herd animals.
aube (npm/yarn/pnpm drop-in alternative) now has a "jailBuilds" flag that restricts access to network/filesystem access.
https://aube.en.dev/package-manager/jailed-builds.html
But this feels like a cat/mouse game.
Pretty wary of the entire JS/nodejs ecosystem at this stage.
Collected all the attacks that happened in the npm ecosystem in past 1 year here:
And this is partly why my development machine is a Raspberry Pi that I can image any time by removing the SD card: https://blog.jgc.org/2026/04/raspberry-pi-as-isolated-ai-cod...
One solution I haven’t seen recommended much is to have a Claude instruction/skill that explicitly audits the diff of every upgrade, and force this manual audit as part of your upgrade workflow. This seems like it would work pretty reliably.
This had been going on for years. I'd expect there would be some kind of solution for now? Like banning scripts and only allowing them to be executed at the explicit user request, for example (not a guarantee but at least a barrier) or somehow restricting them from accessing stuff that does not belong to packaging system. I mean, we have millions of people in the ecosystem, and we keep having this problem for years. Maybe we should ask Claude Code how to fix it (sad laugh)?
I'm very glad I never bought into fullstack JS/TS.
My JS is frontend only, served as a compiled bundle off a server that doesn't even have a JS runtime of its own. Whatever random vulnerabilities the frontend contains are limited in blast radius to the user's own browser, and since all frontends should be untrusted anyway, there is no real security risk to the server or backend. No reason to update more than a few times a year, if that.
Combine with obvious basic security practices like pnpm cooldowns + no build scripts. When you upgrade a few times a year, and frontend vulns don't matter, there's really no limit to the cooldown you can set. 60 days, why not.
Another day, another pre/postinstall script executed that could have easily have been prevented by any sane package manager. NPM really desperately needs an 'allowBuilds' style allowlist [1] and 'approve-builds' command [2].
Another supply chain attack found and blocked in a day. Everyone regularly using npm to install new packages should be using npm's min-release-age setting to avoid package versions that are newer than a few days old to avoid most attacks in practice like this. You can set it to two days with `npm config set min-release-age=2` for example. https://cooldowns.dev/ has info about equivalent settings in other dependency managers like PyPI and Cargo.
pre- and post- install scripts should just be abolished. It should require a special dispensation from npm to even publish one.
Yes, I choose to use pnpm but opt-in safety isn't going to get the developer community to herd immunity.
I wonder if npm could run a program where package uploads are automatically delayed for ~10min while they get distributed to an ecosystem of third-party code auditing companies for automatic checks. You could have a public leaderboard of which auditors detect problems fastest and most reliably, or even monetary compensation.
In the fictional universe of William Gibson's Sprawl trilogy, it is legal and normal for defenders to go kinetic on cyberattackers. How long until it is simply easier for governments and big business in the countries victimised by these criminal groups, to find the path of least resistance and go after them personally?
Vendor your dependencies, clone or port them where needed, and freeze them. Most good packages these days do not have a deep dependency tree, and we should stop using the ones that do.
I spent a week with claude and codex re-implementing several packages which had dependency trees deeper than I would like.
Most of these packages are trivial to clone.
"But now you're not getting the upstream fixes" they will say.
"So what?" I reply
writing your own code is only harbor in this storm. vanilla js cries out into the night sky. will you answer?
I can't wait for npm/github to do literally anything at all to mitigate these attacks. Literally anything. Have we considered a basic WAF-style block on some postinstall script strings? LLM-assisted code scanning on publish? Is there anyone home? No I suspect not.
What would be the required budget to host an alternative registry? I'm surprised any GAFAM still hasn't stepped-in and started building their alternative, at least for NPM to up its game in order not to become completely irrelevant.
PSA - you can run something like `npm install -g npm@11.10.0; npm config set min-release-age=3` to update to a version of npm that supports the min-release-age configuration
As similar to 1st wave of Shai Hulud, this also got it through opentionalDependency. intresting
Libc still unaffected. Write native code. Your users will thank you
npm, the ecosystem: https://npm-the-ecosystem.pagey.site/
i run all my stuff in vm's built with nix
not as easy as docker, but i have a few bash scripts that simplify things for me a lot
i hope that this protects me from the sweep attacks at least
I’m honestly at a point where I’m afraid to update any of my project’s dependencies, and I’m also afraid to run the locally without some locked down VM
If you are using NPM for business, you should be paying for a repository which was checked by antivirus company and not rely on free repository supported by unpaid volunteers.
Because of course it’s npm
it seems obvious to me the ability to push code to public repositories shluld be tied to real human identity.
are these fixed removed now?
another day, another npm hack.
‘No way to prevent this’, Says Only Development Community Where This Regularly Happens
— <https://itnext.io/no-way-to-prevent-this-says-only-developme...>