10 ms·

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

452 points by alligatorplum 4mo ago

qrush 4mo ago
[flagged]
- rileymat2 4mo ago
  I read it as a comparison of the attitude of helplessness around it, not the acts themselves. So it was a bit meta, but unremarkably inoffensive.
- mrandish 4mo ago
  But it's not comparing to school shootings, it's satirizing supposedly responsible parties who continue to deny responsibility despite repeated catastrophic failures which are their responsibility.
- mikepurvis 4mo ago
  I don't think it's comparing them directly or arguing for equivalent seriousness. It is identifying a similarity of mindset where those who have their hands on the levers of power that could materially improve the situation act like there's nothing they can do.
- p-e-w 4mo ago
  You’re right. Major supply chain attacks affect far more people than school shootings do, and can potentially cost more lives through downstream effects. It’s 2026. Software is critical infrastructure for global civilization now. Lives and livelihoods depend on it working reliably. The “it’s just bits on a computer” quip has been outdated for 20 years now.
deleted 4mo ago
[deleted]
btown 4mo ago
For those unfamiliar with the context: https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_Says_Only_Nation_Where_This_Regularly_Happens https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...
- Modified3019 4mo ago
  Same vibe: https://www.youtube.com/watch?v=lOTyUfOHgas https://www.youtube.com/watch?v=lOTyUfOHgas
- yieldcrv 4mo ago
  the onion article is still up could link that
  - jvolkman 4mo ago
    https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_Says_Only_Nation_Where_This_Regularly_Happens#Bibliography https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_... Which one?
  - fragmede 4mo ago
    https://theonion.com/no-way-to-prevent-this-says-only-nation-where-this-r-1848971668/ https://theonion.com/no-way-to-prevent-this-says-only-nation...
p-e-w 4mo ago
With the recent high-profile attacks on PyPI packages, it’s no longer true that npm is the “only package manager where this regularly happens”. In fact, pip is much more dangerous than npm because it lacks a lockfile. uv fixes that, but adoption is proceeding at a snail’s pace.
- godzillabrennus 4mo ago
  UV adoption is happening, though. NPM is still the only name in town.
  - manquer 4mo ago
    Huh ? uv is a package manager not a registry. In JS world there is plenty of competition for package managers pnpm/ yarn/ burn all viable alternatives to npm the package manager. Public registries for languages tend to coalesce around one service . Nobody wants to publish their library to 4 different registries .
- fragmede 4mo ago
  I don't know about snails, but everything I'm in contact with has moved over to uv, and I can't imagine I'm the only one.
- esafak 4mo ago
  Apparently it does now: https://packaging.python.org/en/latest/specifications/pylock-toml/ https://packaging.python.org/en/latest/specifications/pylock... https://pip.pypa.io/en/stable/cli/pip_lock/ https://pip.pypa.io/en/stable/cli/pip_lock/ But who cares about pip, uv is here.
- lateral5 4mo ago
  [flagged]
aselimov3 4mo ago
What are the actual guarantees that go/Rust make that Python/npm don’t? It seems like it might just be that Python/npm are juicier targets? I’m starting to try and avoid all third party packages
- cookiengineer 4mo ago
  I suppose that go's go:generate workflow can also be abused to land a worm like the ones spreading via npm, as you can build programs that just scrape the whole hard drive for git projects and patch the go.mod dependencies there, and you could also just write this in go as a toolchain script, for example. NPM's achilles is the pre/postinstall step which can run arbitrary commands and shell scripts without the user having any way to intervene. Dependencies must be run in isolated chroot sandboxes or better, inside containers. That would be the only way to mitigate this problem, as the filesystem of the operating system must be separated from the filesystem of the development workflow. On top of that most host based firewalls are per-binary instead of per-cmdline. That leads to the warnings and rules relying on that e.g. "python" or "nodejs" getting network access allowlisted, instead of say "nodejs myworm.js". So firewalls in general are pretty useless against this type of malware.
  - yegle 4mo ago
    `go:generate` is for the package provider, the command never runs when someone `go install` or `go get` the package.
    - cookiengineer 4mo ago
      Note that the NPM worms are spreading because the package providers are developing on their libraries without them noticing a malicious dependency. It is not users/consumers spreading the worm, it is developers spreading it. Your mismatch is that you think in policies, not assessments here. Nothing in my normal go workflow will ask me if I want to run "curl download whatever from the internet" when I run go build. Though I agree with the difference in workflow, there is not a single mechanism in go catching this. go.mod files can be just patched by the worm, and/or hidden behind a /v123 folder or whatever to play shenanigans on API differences.
exabrial 4mo ago
I really don't understand why the npm project cannot embrace PGP as an ambulatory 'good enough' solution.
- loloquwowndueo 4mo ago
  The NIH mentality in the ecosystem would result in a JavaScript pgp library which itself would be an npm package and subject to supply chain attacks. lol.
  - panzi 4mo ago
    A good part of it is already implemented in web crypto, which is supported by browsers and node. There is a chance that npm could implement something there without extra dependencies. Maybe I'm too optimistic?
- Gigachad 4mo ago
  Would that help? Most of these recent attacks, the attackers have gained access to the system that builds the packages. So it would have just signed the malicious build the same.
  - raggi 4mo ago
    nope, doesn't help. signatures and removal of script points have zero net effect on the value of the target that the ecosystem has, or how easy/hard it is to write a worm. the package code gets run, this is statistically true, and the exploited developers/environments will sign packages, this is also statistically true.
  - Macha 4mo ago
    In some ways the push towards trusted publishing has made these attacks more likely as the credentials are sitting in a standardized, always on CI system, rather than in a locked down corporate CI system for big packages or a developers machine or developers head for smaller open source packages.
- saghm 4mo ago
yegle 4mo ago
Vendorizing using git submodule should be a robust mitigation for this problem.
- raggi 4mo ago
  subtree is better for this case, you want to encourage actual reading before running. reading won't catch everything but it catches a lot, and the burden isn't as high as people always complain about before they try it.
- saghm 4mo ago
  This feels like the modern analog of the king, the mice, and the cheese. What cats do I need to bring in to eat my git submodules?
- no-name-here 4mo ago
  Wouldn't locking dependencies be far more likely for dependency-users to do, and be approximately as effective for those that do?
827a 4mo ago
There is no legitimate reason why postinstall scripts need to exist. The npm team needs to grow up and declare "starting with npm version whatever, npm will only run postinstall scripts for versions of packages published before ${today}".
- Rohansi 4mo ago
  This doesn't really fix the issue though because package code is also executed at build time and during testing. Just maybe restricts the scope a little bit.
  - tkel 4mo ago
    If you look at the last N npm worms, they all used postinstall scripts.
    - cluckindan 4mo ago
      Is that even true?
      - tkel 4mo ago
        shai-hulud and variants https://www.stepsecurity.io/blog/mini-shai-hulud-is-back-a-self-spreading-supply-chain-attack-hits-the-npm-ecosystem https://www.stepsecurity.io/blog/mini-shai-hulud-is-back-a-s...
        cluckindan 4mo ago
        So N=1? 2? 3?
        tkel 4mo ago
        at least 3 that i can remember off the top my head in these last couple months. If you look further back you will find more.
  - 4mo ago
eulgro 4mo ago
These satire articles on cybersecurity are really entertaining. The other one a few days ago was also good: https://nesbitt.io/2026/02/03/incident-report-cve-2024-yikes.html https://nesbitt.io/2026/02/03/incident-report-cve-2024-yikes...
joeblubaugh 4mo ago
There has been a lot of pain at my various jobs installing a safe global npm config on every developer machine, asking people not to disable it, checking it with mdm tools. A safer out-of-the-box configuration is long overdue.
- tkel 4mo ago
  Just dont use npm. Use a package manager which doesn't execute postinstall by default. The switch is incredibly simple.
  - cluckindan 4mo ago
    Which package manager is that, and what caveats does it offer?
    - timfsu 4mo ago
      Pnpm - installs are faster to boot. We haven’t missed anything
    - ricardo_lien 4mo ago
      pnpm
  - joeblubaugh 4mo ago
    It’s hard to enforce on developer machines - there are lots of ways to install npm even if you never use it for managing development dependencies.
- 10000truths 4mo ago
  What do you mean by safe config? If you're trying to mandate a cooldown period or a whitelist/blacklist of packages, the correct approach is to configure a company-controlled registry that pulls from the upstream npm registry while enforcing your desired policies.
  - tkel 4mo ago
numbsafari 4mo ago
[flagged]
germandiago 4mo ago
I use C++ and Conan with my own recipes and pre-built artifacts. This mitigates things to a great extent. I do not know who thought that having your dependencies depend on the internet with a zillion users doing stuff to each package was a good idea for enterprise environments... It is crazy how much things can get endangered this way.
brooksc 4mo ago
Thoughts and Prayers to those affected
- themafia 4mo ago
  We wish them well.
eranation 4mo ago
I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cooldowns? Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days (1 day can work, 3 days is ok, 7 days is a bit of an overkill but works too) How to set them up? - use latest pnpm, they added 1 day cooldown by default https://pnpm.io/supply-chain-security https://pnpm.io/supply-chain-security - or if you want a one click fix, use https://depsguard.com https://depsguard.com (cli that adds cooldowns + other recommended settings to npm, pnpm, yarn, bun, uv, dependabot and, I’m the maintainer) - or use https://cooldowns.dev https://cooldowns.dev which is more focused on, well, cooldowns, with also a script to help set it up locally All are open source / free. If you know how to edit your ~/.npmrc etc, you don't really need any of them, but if you have a loved one who just needs a one click fix, these can likely save them from the next attack. Caveat - if you need to patch a new critical CVE, you need to bypass the cooldown, but each of them have a way to do so. In the past few weeks, while I don't have hard numbers, it seems more risk has come from Software Supply Chain attacks (malicious versions pushed) than from new zero day CVEs (even in the age of Mythos driven vulnerability discovery)
- tkel 4mo ago
  yes, props to pnpm for adding 1 day cooldown by default in v11.
- wesselbindt 4mo ago
  Seems like you dropped something: > Disclaimer: I maintain depsguard
  - eranation 4mo ago
    Yikes. You are correct. Honest truth, I got a few downvotes (after a few more upvotes), thought this was the cause, but you’re right. Didn’t think that it matters much, I’ll add it back. Had no idea anyone noticed. Fair enough, thanks for keeping me honest. Edit: added it back, inline.
skeledrew 4mo ago
No surprise here. That's what you get when you have a language/ecosystem where core devs refuse to fix fundamental flaws, cuz for them breaking backwards compatibility is the worse crime that can ever be committed. And so all that happens in JS-land will eternally be layering lipstick on the pig in the cesspool. Too afraid of going through something similar to the Python 2 -> 3 fiasco, I guess because too many web devs and site admins would be incensed at being forced to fix their broken universe; as if it isn't already broken in its current condition.
spaqin 4mo ago
It's a cultural issue, always feeling the urge to update to the newest possible package for things that are already working fine, without even reading the changelog to see if it's applicable. Cooldowns are only a way to force a bit of patience onto the maintainers... and they work.
- anonzzzies 4mo ago
  That, and package owners updating stuff that needs no updating just to look not stale/unupdated. I can use lisp packages without changes for 15 years fine, but a js one is unmaintained! oh no! Even though it was done 15 years ago, so they add nothing, sometimes a breaking change, to up a version on npm and github and look maintained. And then everything will update.
- morbicer 4mo ago
  If you have some sort of compliance requirements, you need to update because of the onslaught of CVE vulnerabilities in the older versions. They are mostly bogus like "regexp DOS" but you have to satisfy the process and update anyway.
7e 4mo ago
The answer is LLM inspection. Which, sadly, raises the cost of software, especially once evil LLMs start hiding the backdoors better. Long term the answer should be CHERI, in my opinion.
dh2022 4mo ago
Kudos to the author : this article read like something out of The Onion.
- peterashford 4mo ago
  Its a reference to an Onion article about gun violence in the US
joshka 4mo ago
...so far...
deleted 4mo ago
[deleted]
computersuck 4mo ago
Do not fucking use npm. Stay the fuck away from it. Want to write JS? AI can now write vanilla JS for you with no libraries. Own your code.
- kulahan 4mo ago
  I don't like vanilla JS though. I like easier-to-read abstracted JS.
yangm97 4mo ago
I’m using nix for managing npm dependencies in a project and it seems like I accidentally got some protection from these attacks because of the nix sandbox. Looks like I got more than I begged for.
slopinthebag 4mo ago
I think people are overlooking the fact that the javascript ecosystem is run by perpetual beginners who are probably using 5 different SAAS credential managers and still manage to check their creds into a public git repo. No wonder there are so many breaches. Rust developers otoh are typically experts and don't get pwned so easily.
swang 4mo ago
Ah yes, only `npm` has ever suffered an attack. Ever. RubyGems: https://www.sonatype.com/blog/anatomy-of-the-rubygems-rest-client-hack-and-getting-creative-about-open-source-security https://www.sonatype.com/blog/anatomy-of-the-rubygems-rest-c... PyPi: literally the latest attack included publishing malicious packages on PyPi XZ Tools, a part of nearly every Linux distribution nearly merged in code to backdoor SSH: https://www.akamai.com/blog/security-research/critical-linux-backdoor-xz-utils-discovered-what-to-know https://www.akamai.com/blog/security-research/critical-linux... It is just easy pickings to blame npm specifically. Yes, while they do share some part of the blame, no package manager is immune from attack and certainly not ones where the attackers exploited being able to extract out secrets from a developer's environment variables or files. Seems more like developers should be managing their secrets better? I also find that using the meme that this title snowclones is in bad taste too.
- skydhash 4mo ago
  Security doesn't exist in absolute. It's about relative effort. Exploiting Debian's package management requires quite a bit of effort, NPM, while being funded by Microsoft, only need to have a token stolen. And postinstall scripts were decried as a security risk for a long time
- lucketone 4mo ago
  XZ attacker spent half a year earning trust, doing real maintenance. Different order of magnitude effort spent during XZ attack.
deleted 4mo ago
[deleted]
xiaosong001 4mo ago
A 7-day cooldown feels like a low-effort band-aid. The real fix is probably reproducible builds + signed attestations, but most teams won't pay that tax until they've already been burned.
tylerchilds 4mo ago
[dead]
ramblurr 4mo ago
This link is clearly an AI laundered version of the long running joke from Xe Iaso. Shame. https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024-4323/ https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024... https://news.ycombinator.com/item?id=40438408 https://news.ycombinator.com/item?id=40438408
- sheept 4mo ago
  Both are parodies of The Onion's long-running series of articles.[0] [0]: https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_Says_Only_Nation_Where_This_Regularly_Happens https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...
- brontitall 4mo ago
  The form of wording goes back at least to 2014 in The Onion https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_Says_Only_Nation_Where_This_Regularly_Happens https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...
- xena 4mo ago
  I've honestly been thinking of doing the same kind of thing for a while, but I need to make sure that my generator is exactly 69 lines of code like it currently is: https://github.com/Xe/site/blob/main/cmd/no-way-to-prevent-this/main.go https://github.com/Xe/site/blob/main/cmd/no-way-to-prevent-t...
imrozim 4mo ago
Every node js project starts with npm install and suddenly you have a 500 packages you didnt ask for. Half of them haven't been touched in years.
theuniverseson 4mo ago
[flagged]
greatgib 4mo ago
There is a good old time, before rust and go mindset ruined everything pushing people to wget|bash --install random crap on the spot, when experienced people used to rely on linux OS distributions like debian and co to source package and libraries and ensure to have "stable" and "safe" software procurement for professional and serious infrastructure and deployment. But young blood mocked the fact to have to wait for Manual human review, safe gpg signatures, cool down periods and weeks of "testing" stage before being considered "stable". And now most companies data are leaked and on the wide, hackers and ransomware are thriving... This is crazy when you think about it because after so many years of software dev crafting experience, "modern safe" languages like go and rust, ..., typing, ... You would expect most software stack to be pretty solid and safe compare to 15 years ago.
holotherapper 4mo ago
Lately the security vulnerabilities around Node.js have been pretty rough, and at work I've been scrambling to deal with them.
erikerikson 4mo ago
This reads like an onion article > residents of the Node.js ecosystem stood unified in their belief that the malicious remote-code execution was a completely unpredictable tragedy Does anyone believe that claim? There's been so many counterexamples. It's a great dig on the ecosystem's failings but only entertainment. Perhaps a prompt for marketers to present their wares? Kinda like the maintainer of depsguard who removed, re-added, and then re-removed that admission from their post? At the time of this writing they have the top post.
- forgotTheLast 4mo ago
  Yes, it's derivative of the onion article on mass shootings: https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_Says_Only_Nation_Where_This_Regularly_Happens https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...
- eranation 4mo ago
  I’m sure you mean well but I re-added it and kept it :) (It was re-added inline, right after the link. It says “I’m the maintainer”. I never re-removed it). I shouldn’t have removed it in the first place, and I re-added it right when someone called me out on it, and explained why I did it (https://news.ycombinator.com/item?id=48156765 https://news.ycombinator.com/item?id=48156765). But again, it’s not like it’s hidden, it’s right in my bio. But let’s say I didn’t add a disclaimer in the first place, and didn’t even disclose it in my bio, would it matter much? If the maintainer of pnpm would link to the first link I shared, would i care if they disclose it or not? If it works, it works. It’s a free tool. I know depsguard is not pnpm, and I do think disclosing “plugs” is the ethical thing to do, and that’s why I re-added it, but I don’t understand the obsession with disclosures on free and open source tools that are helping people. You get hated if you disclose it (people hate plugs…) and hated if you don’t. Again I understand the criticism, but I’m not a marketer, I’m someone who is tired of everyone posting on these attacks on LinkedIn for marketing (yes including me), and decided to do something about it (I put my company logo as I used my company laptop and resources) If the tool works, is free, and asks for nothing in return, is clear in my bio that I’m the maintainer, has now a clear disclaimer (inline) is it really that bad of a crime to build something useful for free and link to it in 2026?

452 points by alligatorplum 4mo ago

qrush 4mo ago

[flagged]

rileymat2 4mo ago
I read it as a comparison of the attitude of helplessness around it, not the acts themselves. So it was a bit meta, but unremarkably inoffensive.
mrandish 4mo ago
But it's not comparing to school shootings, it's satirizing supposedly responsible parties who continue to deny responsibility despite repeated catastrophic failures which are their responsibility.
mikepurvis 4mo ago
I don't think it's comparing them directly or arguing for equivalent seriousness. It is identifying a similarity of mindset where those who have their hands on the levers of power that could materially improve the situation act like there's nothing they can do.
p-e-w 4mo ago
You’re right. Major supply chain attacks affect far more people than school shootings do, and can potentially cost more lives through downstream effects. It’s 2026. Software is critical infrastructure for global civilization now. Lives and livelihoods depend on it working reliably. The “it’s just bits on a computer” quip has been outdated for 20 years now.

deleted 4mo ago

[deleted]

btown 4mo ago

For those unfamiliar with the context: https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_Says_Only_Nation_Where_This_Regularly_Happens https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...

Modified3019 4mo ago
Same vibe: https://www.youtube.com/watch?v=lOTyUfOHgas https://www.youtube.com/watch?v=lOTyUfOHgas
yieldcrv 4mo ago
the onion article is still up could link that
- jvolkman 4mo ago
  https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_Says_Only_Nation_Where_This_Regularly_Happens#Bibliography https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_... Which one?
- fragmede 4mo ago
  https://theonion.com/no-way-to-prevent-this-says-only-nation-where-this-r-1848971668/ https://theonion.com/no-way-to-prevent-this-says-only-nation...

p-e-w 4mo ago

With the recent high-profile attacks on PyPI packages, it’s no longer true that npm is the “only package manager where this regularly happens”. In fact, pip is much more dangerous than npm because it lacks a lockfile. uv fixes that, but adoption is proceeding at a snail’s pace.

godzillabrennus 4mo ago
UV adoption is happening, though. NPM is still the only name in town.
- manquer 4mo ago
  Huh ? uv is a package manager not a registry. In JS world there is plenty of competition for package managers pnpm/ yarn/ burn all viable alternatives to npm the package manager. Public registries for languages tend to coalesce around one service . Nobody wants to publish their library to 4 different registries .
fragmede 4mo ago
I don't know about snails, but everything I'm in contact with has moved over to uv, and I can't imagine I'm the only one.
esafak 4mo ago
Apparently it does now: https://packaging.python.org/en/latest/specifications/pylock-toml/ https://packaging.python.org/en/latest/specifications/pylock... https://pip.pypa.io/en/stable/cli/pip_lock/ https://pip.pypa.io/en/stable/cli/pip_lock/ But who cares about pip, uv is here.
lateral5 4mo ago
[flagged]

aselimov3 4mo ago

What are the actual guarantees that go/Rust make that Python/npm don’t? It seems like it might just be that Python/npm are juicier targets? I’m starting to try and avoid all third party packages

cookiengineer 4mo ago
I suppose that go's go:generate workflow can also be abused to land a worm like the ones spreading via npm, as you can build programs that just scrape the whole hard drive for git projects and patch the go.mod dependencies there, and you could also just write this in go as a toolchain script, for example. NPM's achilles is the pre/postinstall step which can run arbitrary commands and shell scripts without the user having any way to intervene. Dependencies must be run in isolated chroot sandboxes or better, inside containers. That would be the only way to mitigate this problem, as the filesystem of the operating system must be separated from the filesystem of the development workflow. On top of that most host based firewalls are per-binary instead of per-cmdline. That leads to the warnings and rules relying on that e.g. "python" or "nodejs" getting network access allowlisted, instead of say "nodejs myworm.js". So firewalls in general are pretty useless against this type of malware.
- yegle 4mo ago
  `go:generate` is for the package provider, the command never runs when someone `go install` or `go get` the package.
  - cookiengineer 4mo ago
    Note that the NPM worms are spreading because the package providers are developing on their libraries without them noticing a malicious dependency. It is not users/consumers spreading the worm, it is developers spreading it. Your mismatch is that you think in policies, not assessments here. Nothing in my normal go workflow will ask me if I want to run "curl download whatever from the internet" when I run go build. Though I agree with the difference in workflow, there is not a single mechanism in go catching this. go.mod files can be just patched by the worm, and/or hidden behind a /v123 folder or whatever to play shenanigans on API differences.

exabrial 4mo ago

I really don't understand why the npm project cannot embrace PGP as an ambulatory 'good enough' solution.

loloquwowndueo 4mo ago
The NIH mentality in the ecosystem would result in a JavaScript pgp library which itself would be an npm package and subject to supply chain attacks. lol.
- panzi 4mo ago
  A good part of it is already implemented in web crypto, which is supported by browsers and node. There is a chance that npm could implement something there without extra dependencies. Maybe I'm too optimistic?
Gigachad 4mo ago
Would that help? Most of these recent attacks, the attackers have gained access to the system that builds the packages. So it would have just signed the malicious build the same.
- raggi 4mo ago
  nope, doesn't help. signatures and removal of script points have zero net effect on the value of the target that the ecosystem has, or how easy/hard it is to write a worm. the package code gets run, this is statistically true, and the exploited developers/environments will sign packages, this is also statistically true.
- Macha 4mo ago
  In some ways the push towards trusted publishing has made these attacks more likely as the credentials are sitting in a standardized, always on CI system, rather than in a locked down corporate CI system for big packages or a developers machine or developers head for smaller open source packages.
saghm 4mo ago

yegle 4mo ago

Vendorizing using git submodule should be a robust mitigation for this problem.

raggi 4mo ago
subtree is better for this case, you want to encourage actual reading before running. reading won't catch everything but it catches a lot, and the burden isn't as high as people always complain about before they try it.
saghm 4mo ago
This feels like the modern analog of the king, the mice, and the cheese. What cats do I need to bring in to eat my git submodules?
no-name-here 4mo ago
Wouldn't locking dependencies be far more likely for dependency-users to do, and be approximately as effective for those that do?

827a 4mo ago

There is no legitimate reason why postinstall scripts need to exist. The npm team needs to grow up and declare "starting with npm version whatever, npm will only run postinstall scripts for versions of packages published before ${today}".

Rohansi 4mo ago
This doesn't really fix the issue though because package code is also executed at build time and during testing. Just maybe restricts the scope a little bit.
- tkel 4mo ago
  If you look at the last N npm worms, they all used postinstall scripts.
  - cluckindan 4mo ago
    Is that even true?
    - tkel 4mo ago
      shai-hulud and variants https://www.stepsecurity.io/blog/mini-shai-hulud-is-back-a-self-spreading-supply-chain-attack-hits-the-npm-ecosystem https://www.stepsecurity.io/blog/mini-shai-hulud-is-back-a-s...
      - cluckindan 4mo ago
        So N=1? 2? 3?
        tkel 4mo ago
        at least 3 that i can remember off the top my head in these last couple months. If you look further back you will find more.
- 4mo ago

eulgro 4mo ago

These satire articles on cybersecurity are really entertaining. The other one a few days ago was also good: https://nesbitt.io/2026/02/03/incident-report-cve-2024-yikes.html https://nesbitt.io/2026/02/03/incident-report-cve-2024-yikes...

joeblubaugh 4mo ago

There has been a lot of pain at my various jobs installing a safe global npm config on every developer machine, asking people not to disable it, checking it with mdm tools. A safer out-of-the-box configuration is long overdue.

tkel 4mo ago
Just dont use npm. Use a package manager which doesn't execute postinstall by default. The switch is incredibly simple.
- cluckindan 4mo ago
  Which package manager is that, and what caveats does it offer?
  - timfsu 4mo ago
    Pnpm - installs are faster to boot. We haven’t missed anything
  - ricardo_lien 4mo ago
    pnpm
- joeblubaugh 4mo ago
  It’s hard to enforce on developer machines - there are lots of ways to install npm even if you never use it for managing development dependencies.
10000truths 4mo ago
What do you mean by safe config? If you're trying to mandate a cooldown period or a whitelist/blacklist of packages, the correct approach is to configure a company-controlled registry that pulls from the upstream npm registry while enforcing your desired policies.
- tkel 4mo ago

numbsafari 4mo ago

[flagged]

germandiago 4mo ago

I use C++ and Conan with my own recipes and pre-built artifacts. This mitigates things to a great extent. I do not know who thought that having your dependencies depend on the internet with a zillion users doing stuff to each package was a good idea for enterprise environments... It is crazy how much things can get endangered this way.

brooksc 4mo ago

Thoughts and Prayers to those affected

themafia 4mo ago
We wish them well.

eranation 4mo ago

I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cooldowns? Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days (1 day can work, 3 days is ok, 7 days is a bit of an overkill but works too) How to set them up? - use latest pnpm, they added 1 day cooldown by default https://pnpm.io/supply-chain-security https://pnpm.io/supply-chain-security - or if you want a one click fix, use https://depsguard.com https://depsguard.com (cli that adds cooldowns + other recommended settings to npm, pnpm, yarn, bun, uv, dependabot and, I’m the maintainer) - or use https://cooldowns.dev https://cooldowns.dev which is more focused on, well, cooldowns, with also a script to help set it up locally All are open source / free. If you know how to edit your ~/.npmrc etc, you don't really need any of them, but if you have a loved one who just needs a one click fix, these can likely save them from the next attack. Caveat - if you need to patch a new critical CVE, you need to bypass the cooldown, but each of them have a way to do so. In the past few weeks, while I don't have hard numbers, it seems more risk has come from Software Supply Chain attacks (malicious versions pushed) than from new zero day CVEs (even in the age of Mythos driven vulnerability discovery)

tkel 4mo ago
yes, props to pnpm for adding 1 day cooldown by default in v11.
wesselbindt 4mo ago
Seems like you dropped something: > Disclaimer: I maintain depsguard
- eranation 4mo ago
  Yikes. You are correct. Honest truth, I got a few downvotes (after a few more upvotes), thought this was the cause, but you’re right. Didn’t think that it matters much, I’ll add it back. Had no idea anyone noticed. Fair enough, thanks for keeping me honest. Edit: added it back, inline.

skeledrew 4mo ago

No surprise here. That's what you get when you have a language/ecosystem where core devs refuse to fix fundamental flaws, cuz for them breaking backwards compatibility is the worse crime that can ever be committed. And so all that happens in JS-land will eternally be layering lipstick on the pig in the cesspool. Too afraid of going through something similar to the Python 2 -> 3 fiasco, I guess because too many web devs and site admins would be incensed at being forced to fix their broken universe; as if it isn't already broken in its current condition.

spaqin 4mo ago

It's a cultural issue, always feeling the urge to update to the newest possible package for things that are already working fine, without even reading the changelog to see if it's applicable. Cooldowns are only a way to force a bit of patience onto the maintainers... and they work.

anonzzzies 4mo ago
That, and package owners updating stuff that needs no updating just to look not stale/unupdated. I can use lisp packages without changes for 15 years fine, but a js one is unmaintained! oh no! Even though it was done 15 years ago, so they add nothing, sometimes a breaking change, to up a version on npm and github and look maintained. And then everything will update.
morbicer 4mo ago
If you have some sort of compliance requirements, you need to update because of the onslaught of CVE vulnerabilities in the older versions. They are mostly bogus like "regexp DOS" but you have to satisfy the process and update anyway.

7e 4mo ago

The answer is LLM inspection. Which, sadly, raises the cost of software, especially once evil LLMs start hiding the backdoors better. Long term the answer should be CHERI, in my opinion.

dh2022 4mo ago

Kudos to the author : this article read like something out of The Onion.

peterashford 4mo ago
Its a reference to an Onion article about gun violence in the US

joshka 4mo ago

...so far...

deleted 4mo ago

[deleted]

computersuck 4mo ago

Do not fucking use npm. Stay the fuck away from it. Want to write JS? AI can now write vanilla JS for you with no libraries. Own your code.

kulahan 4mo ago
I don't like vanilla JS though. I like easier-to-read abstracted JS.

yangm97 4mo ago

I’m using nix for managing npm dependencies in a project and it seems like I accidentally got some protection from these attacks because of the nix sandbox. Looks like I got more than I begged for.

slopinthebag 4mo ago

I think people are overlooking the fact that the javascript ecosystem is run by perpetual beginners who are probably using 5 different SAAS credential managers and still manage to check their creds into a public git repo. No wonder there are so many breaches. Rust developers otoh are typically experts and don't get pwned so easily.

swang 4mo ago

Ah yes, only `npm` has ever suffered an attack. Ever. RubyGems: https://www.sonatype.com/blog/anatomy-of-the-rubygems-rest-client-hack-and-getting-creative-about-open-source-security https://www.sonatype.com/blog/anatomy-of-the-rubygems-rest-c... PyPi: literally the latest attack included publishing malicious packages on PyPi XZ Tools, a part of nearly every Linux distribution nearly merged in code to backdoor SSH: https://www.akamai.com/blog/security-research/critical-linux-backdoor-xz-utils-discovered-what-to-know https://www.akamai.com/blog/security-research/critical-linux... It is just easy pickings to blame npm specifically. Yes, while they do share some part of the blame, no package manager is immune from attack and certainly not ones where the attackers exploited being able to extract out secrets from a developer's environment variables or files. Seems more like developers should be managing their secrets better? I also find that using the meme that this title snowclones is in bad taste too.

skydhash 4mo ago
Security doesn't exist in absolute. It's about relative effort. Exploiting Debian's package management requires quite a bit of effort, NPM, while being funded by Microsoft, only need to have a token stolen. And postinstall scripts were decried as a security risk for a long time
lucketone 4mo ago
XZ attacker spent half a year earning trust, doing real maintenance. Different order of magnitude effort spent during XZ attack.

deleted 4mo ago

[deleted]

xiaosong001 4mo ago

A 7-day cooldown feels like a low-effort band-aid. The real fix is probably reproducible builds + signed attestations, but most teams won't pay that tax until they've already been burned.

tylerchilds 4mo ago

[dead]

ramblurr 4mo ago

This link is clearly an AI laundered version of the long running joke from Xe Iaso. Shame. https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024-4323/ https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024... https://news.ycombinator.com/item?id=40438408 https://news.ycombinator.com/item?id=40438408

sheept 4mo ago
Both are parodies of The Onion's long-running series of articles.[0] [0]: https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_Says_Only_Nation_Where_This_Regularly_Happens https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...
brontitall 4mo ago
The form of wording goes back at least to 2014 in The Onion https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_Says_Only_Nation_Where_This_Regularly_Happens https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...
xena 4mo ago
I've honestly been thinking of doing the same kind of thing for a while, but I need to make sure that my generator is exactly 69 lines of code like it currently is: https://github.com/Xe/site/blob/main/cmd/no-way-to-prevent-this/main.go https://github.com/Xe/site/blob/main/cmd/no-way-to-prevent-t...

imrozim 4mo ago

Every node js project starts with npm install and suddenly you have a 500 packages you didnt ask for. Half of them haven't been touched in years.

theuniverseson 4mo ago

[flagged]

greatgib 4mo ago

There is a good old time, before rust and go mindset ruined everything pushing people to wget|bash --install random crap on the spot, when experienced people used to rely on linux OS distributions like debian and co to source package and libraries and ensure to have "stable" and "safe" software procurement for professional and serious infrastructure and deployment. But young blood mocked the fact to have to wait for Manual human review, safe gpg signatures, cool down periods and weeks of "testing" stage before being considered "stable". And now most companies data are leaked and on the wide, hackers and ransomware are thriving... This is crazy when you think about it because after so many years of software dev crafting experience, "modern safe" languages like go and rust, ..., typing, ... You would expect most software stack to be pretty solid and safe compare to 15 years ago.

holotherapper 4mo ago

Lately the security vulnerabilities around Node.js have been pretty rough, and at work I've been scrambling to deal with them.

erikerikson 4mo ago

This reads like an onion article > residents of the Node.js ecosystem stood unified in their belief that the malicious remote-code execution was a completely unpredictable tragedy Does anyone believe that claim? There's been so many counterexamples. It's a great dig on the ecosystem's failings but only entertainment. Perhaps a prompt for marketers to present their wares? Kinda like the maintainer of depsguard who removed, re-added, and then re-removed that admission from their post? At the time of this writing they have the top post.

forgotTheLast 4mo ago
Yes, it's derivative of the onion article on mass shootings: https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_Says_Only_Nation_Where_This_Regularly_Happens https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...
eranation 4mo ago
I’m sure you mean well but I re-added it and kept it :) (It was re-added inline, right after the link. It says “I’m the maintainer”. I never re-removed it). I shouldn’t have removed it in the first place, and I re-added it right when someone called me out on it, and explained why I did it (https://news.ycombinator.com/item?id=48156765 https://news.ycombinator.com/item?id=48156765). But again, it’s not like it’s hidden, it’s right in my bio. But let’s say I didn’t add a disclaimer in the first place, and didn’t even disclose it in my bio, would it matter much? If the maintainer of pnpm would link to the first link I shared, would i care if they disclose it or not? If it works, it works. It’s a free tool. I know depsguard is not pnpm, and I do think disclosing “plugs” is the ethical thing to do, and that’s why I re-added it, but I don’t understand the obsession with disclosures on free and open source tools that are helping people. You get hated if you disclose it (people hate plugs…) and hated if you don’t. Again I understand the criticism, but I’m not a marketer, I’m someone who is tired of everyone posting on these attacks on LinkedIn for marketing (yes including me), and decided to do something about it (I put my company logo as I used my company laptop and resources) If the tool works, is free, and asks for nothing in return, is clear in my bio that I’m the maintainer, has now a clear disclaimer (inline) is it really that bad of a crime to build something useful for free and link to it in 2026?