10 ms·

Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

391 points by theanonymousone 5mo ago

dmitrygr 5mo ago
Libc still unaffected. Write native code. Your users will thank you
kunalsin9h 5mo ago
As similar to 1st wave of Shai Hulud, this also got it through opentionalDependency. intresting
nextstep 5mo ago
[dead]
moi2388 5mo ago
Because of course it’s npm
- type0 5mo ago
  Does npm stand for "newly packaged malware"?
  - wolfi1 5mo ago
    should be a meme
  - Ygg2 5mo ago
    Akshully, "Node Packaged Malware."
    - thrownthatway 5mo ago
      Needs more recursion. NPM - NPM Packaged Malware
- matheusmoreira 5mo ago
  Every programming language package manager is affected. Any random person can sign up and push packages. They are all equivalent to the Arch Linux User Repository and have the exact same caveats.
  - grey-area 5mo ago
    I last added a new dependency to a large project I work on a couple of years ago. So no, not all ecosystems are the same. The culture makes a difference.
  - stephenr 5mo ago
    How many other languages of any kind have a standard library that is so bizarrely lacking as JS? Now how many other mainstream languages of any kind have a standard library that is so lacking? Now how many other mainstream languages have a swathe of front-end developers that suddenly realised they can run code in a CLI or on a server, and spent exactly 0 minutes learning about how to make it not shit? Now how many other languages get used in scenarios where it makes absolutely zero sense because the developer only knows javascript?
    - matheusmoreira 5mo ago
      This has nothing to do with standard libraries or popularity. It's about trust. I signed up for an npm account and pushed packages. Same for PyPI. Same for Ruby gems. There's no actual reason why anyone should believe I pushed anything but malware in there.
      - stephenr 5mo ago
        Did you not read point 3? Developer experience level is a part of the problem.
        matheusmoreira 5mo ago
        Yes, and it makes no sense. It's not a "swathe of front-end developers" problem. Developers in general want to push packages. They don't want to experience friction while doing it. They especially don't want to have to do things like engage with Linux distribution maintainers in order to get their packages into official software repositories. They want to just run $pkgr publish on their repo and that's it. So they invariably end up creating their own distribution mechanisms with zero maintainers involved. Just untrusted randoms making accounts and pushing random stuff. It's easy, so naturally what happens is the repositories get filled with software. It's only natural to use the stuff that is out there, so the packages get added to projects as dependencies despite the fact none of it is even slightly trusted. Developers hate friction when using libraries too. They very much want to just run $pkgr install x on their repositories and be done with it. They don't want to do things like read the source code or verify that it actually corresponds to what they've downloaded. That's somebody else's problem. On Linux distrubutions, that somebody else is the package maintainer, the exact person the programming language package managers aim to eliminate.
fnoef 5mo ago
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
- exiguus 5mo ago
  I also was at this point, and I decided to add cooldowns to every project.
  - fnoef 5mo ago
    Yeah, I agree, but then you are at the mercy of whatever vulnerability is found in the current version(s). It just feels like a lose-lose situation no matter what you do.
    - tpetry 5mo ago
      You can still update to new versions even if the new release is still in cooldown phase. You just have to be explicit that you want the new release. pnpm audit —fix for example will whitelist releases in cooldown phase when theres a known security issue for a version you currently use.
    - thrownthatway 5mo ago
      So long as we insist on everything from a light switch, the vacuum cleaner, security camera, clothes dryer, TV, car, and mobile phone being an always on, always online, Universal Turing Machine we’re not going to find a solution.
- darkwi11ow 5mo ago
  I use Tanstack in my projects. Last week when Tanstack got compromised, it was only my laziness that saved me -- was thinking about doing pnpm upgrade but got lazy and played some dota... Finished game was just going to pnpm upgrade, opened hacker news and boom! news hit. Since then, I had set up libvirt/qemu based VM with another Linux running in it specifically for development. Now I run all of docker, kubernetes, IDE, pnpm, uv, etc in that VM and removed them from host. The only write capable secret VM has access to, is my passphrase protected ssh key, which I can quickly revoke from my Github account in case of compromise. Feels much safer now.
wlkr 5mo ago
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.
- cess11 5mo ago
  Wondering about Mr Bones' Wild Ride and suspecting it might be a reference to the 1991 movie Nothing But Trouble I took a look, and found I had remembered it wrong. The roller coaster in that movie was called Mr Bonestripper, https://www.youtube.com/watch?v=NEZEgd8GjJc https://www.youtube.com/watch?v=NEZEgd8GjJc . Instead it comes from Roller Coaster Tycoon 2, https://knowyourmeme.com/memes/mr-bones-wild-ride https://knowyourmeme.com/memes/mr-bones-wild-ride . As for the comparison with spam, there we kind of settled on making people accept spam by vacuuming up their email addresses in pretty much every commercial and social computer network setting, giving it a veneer of legitimacy. I think it is likely to happen in this area too, perhaps some combination of Oracle licensing surveillance agent style software and automated dependency management, i.e. 'solving' supply chain malware by whitelisting some other malware.
  - breezerbottles 5mo ago
    There's also Mr. Toad's Wild Ride at Disney parks, https://en.wikipedia.org/wiki/Mr._Toad%27s_Wild_Ride https://en.wikipedia.org/wiki/Mr._Toad%27s_Wild_Ride
    - 5mo ago
ares623 5mo ago
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.
- throwa356262 5mo ago
  Security by giving up
mentalgear 5mo ago
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.
- wolfi1 5mo ago
  how do containers solve the problem? if they are connected to the internet (and they are) you have got the same problem, if the credentials can be read by the container, at least to my understanding
  - mentalgear 5mo ago
    For credential stealing, that is true, but at least it would protect your local machine. But I just read these worms also try container escape ...
    - silon42 5mo ago
      We need to prevent direct connections to internet for containers... once you have a proxy, predefined credentials (api keys) can maybe be added there (per container/target).
      - cyanydeez 5mo ago
        the model most people are talking about is in the cloud. for the harness to do useful work, it needs to talk to the cloud the trouble is, we need protocols that are software determined that force AI interaxtions into limited scope but currently theyre all just bash adjacent and inherit your tools.
    - fnoef 5mo ago
      You need to use full isolated VM with its own kernel. But then again, I've read somewhere that this malware is also trying to escape the VM isolation as well...
mentalgear 5mo ago
> 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) !
- jeswin 5mo ago
  > Make sure you're running a rootless VM engine (e.g. podman instead of docker) ! Aren't most people running docker rootless (at least on Linux)? Does podman do more?
  - Maakuth 5mo ago
    The docker CLI tool is normally executed with user privileges, but there's dockerd, a daemon running as root that actually does the container execution.
    - cyanydeez 5mo ago
      im not sure people understand the security vectors. a user with docker permissions effectively has root permissions. often, docker in docker is used to manage docker orchestration. putinng a user in a docker and peoviding docker access is security through obscurity. on the flip side, i see people blindly installing tools and skills not understanding they are pushing context and capabilities without any significant security features. Imagine mythos is actually exceptional hacker. if you give it a well crafted malicious prompt, its going to even more insecure. the double edged sword is really fascinating to think about
      - jeswin 5mo ago
        Docker has not required root for a long time, at least on Linux. There's even a convenience script for it: https://get.docker.com/rootless https://get.docker.com/rootless Almost everyone I know installs docker rootless.
    - 5mo ago
jonkoops 5mo ago
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]. 1. https://pnpm.io/settings#allowbuilds https://pnpm.io/settings#allowbuilds 2. https://pnpm.io/cli/approve-builds https://pnpm.io/cli/approve-builds
- wereHamster 5mo ago
  After I upgraded pnpm to v11, I set all allowBuilds to false and have not observed any failures. Made me wonder why the packages even need build scripts. My guess is for obscure or old platforms, but for most users running on Linux or Darwin build scripts seem to be unnecessary.
  - Tade0 5mo ago
    > Made me wonder why the packages even need build scripts. Historically it was to accommodate packages like the original SASS compiler: https://sass-lang.com/ruby-sass/ https://sass-lang.com/ruby-sass/ Other times it was to avoid shipping binaries due to, erm, safety concerns. The package would include code in a different language, which in turn would compile into a binary library or executable.
  - n_e 5mo ago
    > Made me wonder why the packages even need build scripts As the name implies it's for building stuff. Most (all?) packages that use C++ FFI with node-gyp need it. A popular package that needs it is re2. Many newer packages bundle prebuilt native code as transitive dependencies, so build scripts are less needed than before.
- perkovsky 5mo ago
  Agree. Postinstall scripts should be explicit opt-in, not ambient capability. Most packages should not need arbitrary code execution during install. And when they do, that should be obvious during review. The default should probably be: install files, don’t run code.
knlsn 5mo ago
are these fixed removed now?
- Brybry 5mo ago
  Seems like it is fixed/removed: https://github.com/antvis/.github/commit/cb641113703e531ee43591d15cee52bc8a38e0c9 https://github.com/antvis/.github/commit/cb641113703e531ee43... Some are still on npm but marked "deprecated": https://www.npmjs.com/package/size-sensor/v/1.0.4?activeTab=code https://www.npmjs.com/package/size-sensor/v/1.0.4?activeTab=... As the article states, you can see in the package.json that the optionalDependencies references "@antv/setup": "github:antvis/G2#7cb42f57561c321ecb09b4552802ae0ac55b3a7a" I'm pretty sure those commits have been removed from github: https://github.com/antvis/G2/issues/7401#issuecomment-4484808335 https://github.com/antvis/G2/issues/7401#issuecomment-448480... https://github.com/antvis/G2/issues/7394 https://github.com/antvis/G2/issues/7394
somelamer567 5mo ago
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?
- thrownthatway 5mo ago
  We can’t even prevent shop lifting.
  - somelamer567 5mo ago
    Shoplifting isn't a national security matter.
    - thrownthatway 5mo ago
      It’s an issue affecting the nation.
    - mminer237 5mo ago
      Most malware isn't either, especially with Node.
  - sitkack 5mo ago
    Compared to what?
    - redsocksfan45 5mo ago
      [dead]
    - thrownthatway 5mo ago
      Are you ok? Compared to calling in air support on cyber criminals. How’s your reading comprehension coming along?
Outlook5813 5mo ago
another day, another npm hack.
AgentME 5mo ago
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/ https://cooldowns.dev/ has info about equivalent settings in other dependency managers like PyPI and Cargo.
- sevenzero 5mo ago
  Or just use dependencies from 6 years ago and never update them like most companies i ever worked for.
  - halfcat 5mo ago
    Accidental true leadership
- tom2tomtomtom 5mo ago
  [dead]
rubnogueira 5mo ago
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 https://aube.en.dev/package-manager/jailed-builds.html But this feels like a cat/mouse game.
- cyanydeez 5mo ago
  dino was wired with security in mind, but you can see developers dont tend towards aecurity
  - rubnogueira 5mo ago
    Because there is a time and effort cost to swap over to another framework/runtime even if it brings benefits, and security is always considered "good for now" unfortunately. That is what made Bun popular, and tools like uv/pip, oxlint/eslint, orbstack/docker desktop, and the list goes on. Drop-in replacements where we get 10x with little effort.
  - epicide 5mo ago
    Because employers don't tend towards security. In fact, many actively punish somebody for "sandbagging" or simply taking too long if they even suggest a security concern.
  - esafak 5mo ago
    What is dino?
- no-name-here 5mo ago
  > aube (npm/yarn/pnpm drop-in alternative) now has a "jailBuilds" flag that restricts access to network/filesystem access. 1. It seems like the restrictions are only for lifecycle scripts, so wouldn't help if/when the package's actual code had malicious code inserted? 2. Package managers like pnpm seem to entirely block lifecycle scripts by default, so I guess this is an in-between solution. Still, I guess it's a step in the right direction for those want or need to run lifecycle scripts specifically.
CafeRacer 5mo ago
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
aa-jv 5mo ago
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.
jgrahamc 5mo ago
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-coding.html https://blog.jgc.org/2026/04/raspberry-pi-as-isolated-ai-cod...
- Shank 5mo ago
  I mean that's lovely, but you still store confidential data, I assume, like credentials on your development machine? This doesn't solve anything but the least important "reinstall the OS post-compromise" step.
  - jgrahamc 5mo ago
    On that machine there's Claude's authentication for my account so I can run Claude on it, a public key so I can SSH to the box, and a private key for GitHub access.
Havoc 5mo ago
Pretty wary of the entire JS/nodejs ecosystem at this stage.
- matheusmoreira 5mo ago
  Same. At this point I just started using virtual machines for any project that pulls in packages from outside Linux distribution repositories.
- michalsustr 5mo ago
  Given general software quality of the js ecosystem, the proliferation of supply chain attacks was just matter of time. I’m curious how other ecosystems will hold (eg Rust)
  - freakynit 5mo ago
    And now, vibe-coding is just gonna take this to a whole another level.
  - tadfisher 5mo ago
    NPM is an easy target because every package has the capability of interacting with your development environment by default, via pre/post-install scripts. Cargo has something similar with build.rs scripts, as does Cabal (Haskell). In JVM-land, thanks to binary distribution being the default, the number of packages you can usurp to achieve the same compromise is fairly small; essentially Maven and Gradle plugins. Which is why you should be extremely wary when, say, Sentry tells you to add them as a dependency by setting up their Gradle plugin. Not sure about sbt. Clojure source dependencies can provide "prep" scripts, which are not automatically run as part of a build, but still execute code on your machine. There's a pattern here: some build tools incorporate dependency-provided code as part of the consumer project's build, and that is a juicy attack surface. Packages which include such code, or are recently updated to include it, should be treated with extra scrutiny.
- cozzyd 5mo ago
  Yes... The only things I use from the JS ecosystem are {Claude,gemini}-cli which I fear will be compromised. Fortunately I run in them in their own user accounts with no e.g. ssh credentials, but I dead that's not enough especially for Gemini which probably has access to my entire Google account somehow.
nojs 5mo ago
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.
- quantumleaper 5mo ago
  This is what many AI supply-chain security startups (like the one that posted the article) are already doing with all NPM packages, so save yourself the Claude tokens. All of these compromises were detected within minutes, but it takes some time (<1 hour) for NPM to unpublish all of the affected packages.
  - PAndreew 5mo ago
    Sorry for my ignorance, but then couldn't we build this into NPM itself? So before a package is publicly available it would be quaranteened and checked.
- madamelic 5mo ago
  Super dumb question as someone who has been using some form of AI for dev since 2023: How does having an AI audit external code help? Can they not be prompt injected to ignore a malicious change? I guess I am sort of concerned that they are a pretty thin layer and even if you put "DO NOT ALLOW PROMPT INJECTION", it's a bit like saying "make no mistakes". There _is_ a priority between `system` and `user` level messages as I had recalled, so a specifically made tool that has its own system prompt should prevent injection while asking Claude CLI could still allow for prompt injection. What are your thoughts and experience?
  - Yokohiii 5mo ago
    There are prompt guard classifiers that can detect prompt injections, but they are not perfect (false positives, obfuscation) and should be only a part of the defense. The concern is real and unsolved. I think security researchers have an advantage here because they still can fall back to manual audits if their automated analysis (or scores thereof) is off.
mashijian 5mo ago
[flagged]
teddyh 5mo ago
‘No way to prevent this’, Says Only Development Community Where This Regularly Happens — <https://itnext.io/no-way-to-prevent-this-says-only-development-community-where-this-regularly-happens-8ef59e6836de?gi=4f635bc98645 https://itnext.io/no-way-to-prevent-this-says-only-developme...>
- deleted 5mo ago
  [deleted]
- anonym29 5mo ago
  "A well administered supply chain, being necessary to the freedom of an open internet, the right of the developers to keep and bear hundreds of uninspected transitive dependencies, shall not be infringed."
- ajross 5mo ago
  The Node ecosystem happens to be more vulnerable for social and software design reasons, it's true. But people need to be aware that PyPI and Cargo et. al. are not in any fundamental way less vulnerable. This will happen there too.
  - zarzavat 5mo ago
    To expand on this, PyPI is slightly less vulnerable because Python users tend to install mega packages (such as numpy or django) and do not frequently interact with their package manager. There is also not a culture of using sub-dependencies. Cargo is essentially the same as NPM though, it's only "safer" because it's less popular. Although the situation on NPM is extremely uncomfortable, you're probably less likely to get hit if you take reasonable precautions than on PyPI, simply because NPM is getting scanned more often. Most of these attacks on NPM have been detected and pulled days before my min age kicks in. A sleeper attack on PyPI could be devastating.
  - zahlman 5mo ago
    In fact, attacks like Shai-Hulud explicitly attempt to get into PyPI, and have succeeded to a lesser extent. But aside from the package-size / -complexity issue pointed out in a sibling comment, PyPI also tries a fair bit to monitor for incoming malware (and there's a "report project as malware" button on each project page). Also, there are no post-install scripts (of course, the code can detect when it's being run for the first time in the installed environment); and pre-install scripts are only included in sdists[0]. So you can easily[1] configure your installer such that you at least won't get pwned at install time, at the cost that some[2] packages can't be installed that way. And then you can go inspect, run a security scanner over, etc. whatever got installed; wheel installations just copy things to well-defined locations and generate simple wrapper scripts by strict rules. [0]: I.e., when the project is "being built from source", which generally is only necessary when it includes non-Python code directly and the maintainer hasn't pre-built that code for your system. [1]: Notwithstanding that, with pip, many actions that you'd expect not to get you pwned totally can. Such as, for example, explicitly telling it to download an sdist and not install it; as I discussed in https://zahlman.github.io/posts/python-packaging-3/ https://zahlman.github.io/posts/python-packaging-3/ . [2]: In practice, a pretty small fraction of what typical developers would actually care about, at least outside of specific niches. I'm told there are some niches where it's a big problem, but honestly they're lucky that this kind of build-install orchestration sort-of works at all.
kixxauth 5mo ago
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
- no-name-here 5mo ago
  Wouldn't just having devs pin/not upgrade packages accomplish about as much, have the added benefit that if a package is discovered malicious it would be removed from npm but if already vendored you’d still have the vulnerability on your vendored copy, and pinning versions seems like it would be more likely for devs to do than vendoring?
  - cj 5mo ago
    Pinning the version also avoids the risk of accidentally introducing new vulnerabilities while reimplementing the package yourself.
  - erikerikson 5mo ago
    Not to support the GPs choices (they are not mine) but pinned dependencies can get grumpy over time with endless LTS migrations.
  - kixxauth 5mo ago
    Yeah, pinning dependencies is very similar to vendoring or cloning them. By cloning, you get to know the code better and how it is structured, plus you cherry pick only the features you want. But, like you said, you are at risk of introducing new vulnerabilities. I'd just prefer making that bet on myself than someone I don't know
alex1sa 5mo ago
[flagged]
827a 5mo ago
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.
- pier25 5mo ago
  Third parties can detect compromised packages. It’s ridiculous Microsoft doesn’t.
  - lyu07282 5mo ago
    They can and do indeed detect those attacks, it's just from Microsoft's POV a feature of Microsoft Defender (on Windows and Cloud) they sell: https://www.microsoft.com/en-us/security/blog/2025/12/09/shai-hulud-2-0-guidance-for-detecting-investigating-and-defending-against-the-supply-chain-attack/ https://www.microsoft.com/en-us/security/blog/2025/12/09/sha... https://azure.microsoft.com/en-us/pricing/details/defender-for-cloud/ https://azure.microsoft.com/en-us/pricing/details/defender-f... So this is presumably why they will never address this in npm itself.
    - grim_io 5mo ago
      Maybe they should prove their shit works first. What a wonderful marketing opportunity! Leave it to Microsoft to blindly ignore it.
      - lyu07282 5mo ago
        No look at the article of this post, it's by SafeDep they are in the same business as Microsoft with their Defender product line. They both publish near identical post mortems with subtle hints at how their product would've defended you against the attack. Why should Microsoft fix the cause instead of selling the cure to each business individually?
        5mo ago
morpheos137 5mo ago
it seems obvious to me the ability to push code to public repositories shluld be tied to real human identity.
- wang_li 5mo ago
  Using code from these repositories should be considered the same as licking toilet seats at highway rest stops. There’s something wrong with you if you do it.
gherkinnn 5mo ago
> 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. 0 - https://docs.deno.com/runtime/reference/std/ https://docs.deno.com/runtime/reference/std/
- tln 5mo ago
  I'm not sure any of the packages here would be part of a "better standard library". Do any language standard libraries have a "3 hours ago" formatter? Thats what timeago.js does Maybe slice.js, which just does python-style indexing with negative numbers. TC39 already made array.at() and array.slice() handle negative numbers.
  - WorldMaker 5mo ago
    > Do any language standard libraries have a "3 hours ago" formatter? Thats what timeago.js does There's also a platform feature for that now: Intl.RelativeTimeFormat: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/RelativeTimeFormat https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... It asks you to do the basic time math to determine your granularity so there's still a role for a library, but also that time math gets easier with Temporal: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... (Specifically `Temporal.Now.instant().since(somePastInstant)` returns a Temporal.Duration that you can relatively easily determine the highest granularity you want and pass that to an Intl.RelativeTimeFormat instance. Also Intl.DurationFormat which is what a Temporal.Duration's `toLocaleString()` uses may also be good enough in many "x hours ago" type situations, though it is over-precise for them.)
    - tln 5mo ago
      Thanks for that! So, back to the GP post - TC39 should make a bigger stdlib. Lets say timeago.js is warranted (as a polyfill and terser API) AND TC39 is taking action. On slice.js, TC39 took action AND usage is unwarranted since the functionality is widely available. Maybe a stride.js would be needed. There are 2 modules where npm's culture of "tiny modules because the stdlib is impoverished" holds - but the issue isn't TC39 really. There are 312 modules that aren't related to npm's culture of "tiny modules because the stdlib is impoverished".
btown 5mo ago
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?
- peterldowns 5mo ago
  Yes. This is partially why other ecosystems don’t see as many supply chain attacks.
- zahlman 5mo ago
  > and trust that NPM at least gets their "you can't republish to an old version" bare-minimum constraint right? ... Does NPM not create full lockfiles, with hashes and pinned transitive dependencies and everything?
  - btown 5mo ago
    Yes, and the problem here is that most projects have automated systems that automatically update those lockfiles on every upstream release of a library, under an assumption that minor releases are either security patches or bugfixes that would immediately be useful to the consuming project. IMO this is built on a pre-ShaiHulud, pre-AI set of assumptions, and should be evaluated from first principles with today's security situation.
    - zahlman 5mo ago
      My point was the "with hashes" part. You aren't in fact "trusting" NPM to ensure that old versions aren't replaced if the package installer is verifying the hash.
  - esafak 5mo ago
    https://docs.npmjs.com/cli/v11/configuring-npm/package-lock-json https://docs.npmjs.com/cli/v11/configuring-npm/package-lock-...
mrgoldenbrown 5mo ago
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.
troad 5mo ago
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.
- austin-cheney 5mo ago
  If you serve any third party logic, such as advertisements, your code is just as potentially compromised.
  - troad 5mo ago
    Only the frontend, which is already untrusted. Any risk would be restricted to individual users who used the compromised frontend to communicate something sensitive, and while that's not great, it is significantly better than the backend being compromised. A very significant reduction in blast radius. Funnily enough, I don't actually think I do serve third party JS, though. Don't serve ads, don't use external telemetry, don't use JS CDNs. I don't think you have to go quite as far as I do, though - I imagine if your ads are Google AdSense or something, you're probably going to be fine.
- ZiiS 5mo ago
  It is your development machine's AWS keys they want. The server's keys should be too finly scooped anyway.
  - troad 5mo ago
    Not likely to be a major risk if you update every few months, to some major version that's already over a month old.
  - 5mo ago
freakynit 5mo ago
[flagged]
KolmogorovComp 5mo ago
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.
- ruined 5mo ago
  at amazon, they maintain a private internal registry of packages with approved licenses and audits. this has been in place for several years. i assume other big corps enforce similar policies
  - philipwhiuk 5mo ago
    If your company not running an internal proxy at minimum you're stupid - you have no audit function for what libraries are being pulled.
    - HDBaseT 5mo ago
      Not every company has tons of available funds to run 300 different internal services to "protect" itself.
  - a1o 5mo ago
    Do you know if they are using any product like JFrog for this or rolling their own?
    - jon-wood 5mo ago
      This is Amazon, the company where the stuff they rolled their own now makes more money than the business it was rolled for: https://aws.amazon.com/codeartifact/ https://aws.amazon.com/codeartifact/
perdomon 5mo ago
writing your own code is only harbor in this storm. vanilla js cries out into the night sky. will you answer?
- pmdr 5mo ago
  That and vendored HTMX. Nobuild. JS on the backend looks more and more like a very bad idea.
a1o 5mo ago
[dead]
timfsu 5mo ago
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
freakynit 5mo ago
Collected all the attacks that happened in the npm ecosystem in past 1 year here: https://npm-supply-chain-attacks-25-26.pagey.site/ https://npm-supply-chain-attacks-25-26.pagey.site/
- kjok 5mo ago
  Please also collect responses from people, you'd find a pattern: a new attack is launched, people make noise, and later go back to installing packages the same way. Enterprises already use private registries to combat such attacks, vulnerable folks include individual devs and small teams.
  - freakynit 5mo ago
    Want to.. but I'll need to first integrate social-media and forum scanning in my tool. Haven't done that yet. But, it's a good feature to have. Thanks.. gonna integrate now :)
- HDBaseT 5mo ago
  Did Claude generate this site? The scroll seems to jump all over the place on my device.
  - freakynit 5mo ago
    yep... fixed it in new version. Thanks for mentioning.
    - HDBaseT 5mo ago
      No worries, works fine on my end now!
tln 5mo ago
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.
nepthar 5mo ago
“No way to prevent this” says only package manager where this regularly happens.
- bakugo 5mo ago
  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?
  - freakynit 5mo ago
    Yep. 1. Every day there's a new package. 2. Then five more packages appear so you don't have to write that one terrifying line of JavaScript yourself. 3. Then someone writes a wrapper around those five packages. 4. Then someone writes a "modern, lightweight, zero-config" wrapper around the wrapper. 5. Then a framework adopts it, a build tool requires it, and suddenly your todo app has a dependency graph that looks like international diplomacy. 6. Out of 100 devs building the same product, there are now 300 different dependency combinations, all somehow involving 'left-pad' spiritually if not literally. 7. Half the packages are maintained by one person, unpaid, at 2 a.m., after getting yelled at in GitHub issues. 8. The other half were abandoned three years ago but still have 40 million weekly downloads because removing them would break civilization. 9. Pinning dependencies sounds nice until the ecosystem tells you, "sorry, this package only works with Node 22, this plugin needs Node 18, and this transitive dependency has discovered ESM enlightenment." 10. So everyone lives on the bleeding edge, except nobody agrees where the edge is, and the bleeding part is very real. So yeah, npm is not uniquely cursed because JavaScript devs are worse. It's cursed because it turned code reuse into a lifestyle, dependency trees into rainforests, and 'npm install' into an act of faith.
    - MadnessASAP 5mo ago
      > 7. Half the packages are maintained by one person, unpaid, at 2 a.m., after getting yelled at in GitHub issues. By a manager for for a >$1 billion market cap corporation who doesnt understand that the one person isnt an employee.
smsm42 5mo ago
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)?
- staticassertion 5mo ago
  The solution is to do exactly what you suggest - separate access. In CI this is a matter of having your "build/test" jobs happen separately from your "deploy/publish" jobs. The trickier part is dev environments, but ideally you take a similar approach. The place that devs do `npm install` should be isolated from, say, your browser / ssh keys etc. Package manager support would be an amazing win here since you'd have an easier time managing the isolation but you can do this today.
freakynit 5mo ago
npm, the ecosystem: https://npm-the-ecosystem.pagey.site/ https://npm-the-ecosystem.pagey.site/
tomxor 5mo ago
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.
- hirako2000 5mo ago
  Or simply use pnpm.
  - tomxor 5mo ago
    That's helpful to prevent individual secret harvesting, however it does not protect you from potential silent downstream effects in packages. i.e. inclusion of malicious code in libraries you depend on, this could be as simple as inserting a cryptominer, or as severe as data exfil in a front end package. This default can affect all consumers of NPM packages, regardless of whether you use yarn, pnpm or npm itself, because most package maintainers use NPM. This is why it's NPM's responsibility to change this default in order to prevent spread of malware in packages.
- deleted 5mo ago
  [deleted]
- bakkoting 5mo ago
  There's an RFC for this: https://github.com/npm/rfcs/pull/868 https://github.com/npm/rfcs/pull/868
- josephg 5mo ago
  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.
codedokode 5mo ago
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.
urbandw311er 5mo ago
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-c9j4-9m59-847w 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 :-(
HALtheWise 5mo ago
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.

dmitrygr 5mo ago

Libc still unaffected. Write native code. Your users will thank you

kunalsin9h 5mo ago

As similar to 1st wave of Shai Hulud, this also got it through opentionalDependency. intresting

nextstep 5mo ago

[dead]

moi2388 5mo ago

Because of course it’s npm

type0 5mo ago
Does npm stand for "newly packaged malware"?
- wolfi1 5mo ago
  should be a meme
- Ygg2 5mo ago
  Akshully, "Node Packaged Malware."
  - thrownthatway 5mo ago
    Needs more recursion. NPM - NPM Packaged Malware
matheusmoreira 5mo ago
Every programming language package manager is affected. Any random person can sign up and push packages. They are all equivalent to the Arch Linux User Repository and have the exact same caveats.
- grey-area 5mo ago
  I last added a new dependency to a large project I work on a couple of years ago. So no, not all ecosystems are the same. The culture makes a difference.
- stephenr 5mo ago
  How many other languages of any kind have a standard library that is so bizarrely lacking as JS? Now how many other mainstream languages of any kind have a standard library that is so lacking? Now how many other mainstream languages have a swathe of front-end developers that suddenly realised they can run code in a CLI or on a server, and spent exactly 0 minutes learning about how to make it not shit? Now how many other languages get used in scenarios where it makes absolutely zero sense because the developer only knows javascript?
  - matheusmoreira 5mo ago
    This has nothing to do with standard libraries or popularity. It's about trust. I signed up for an npm account and pushed packages. Same for PyPI. Same for Ruby gems. There's no actual reason why anyone should believe I pushed anything but malware in there.
    - stephenr 5mo ago
      Did you not read point 3? Developer experience level is a part of the problem.
      - matheusmoreira 5mo ago
        Yes, and it makes no sense. It's not a "swathe of front-end developers" problem. Developers in general want to push packages. They don't want to experience friction while doing it. They especially don't want to have to do things like engage with Linux distribution maintainers in order to get their packages into official software repositories. They want to just run $pkgr publish on their repo and that's it. So they invariably end up creating their own distribution mechanisms with zero maintainers involved. Just untrusted randoms making accounts and pushing random stuff. It's easy, so naturally what happens is the repositories get filled with software. It's only natural to use the stuff that is out there, so the packages get added to projects as dependencies despite the fact none of it is even slightly trusted. Developers hate friction when using libraries too. They very much want to just run $pkgr install x on their repositories and be done with it. They don't want to do things like read the source code or verify that it actually corresponds to what they've downloaded. That's somebody else's problem. On Linux distrubutions, that somebody else is the package maintainer, the exact person the programming language package managers aim to eliminate.

fnoef 5mo ago

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

exiguus 5mo ago
I also was at this point, and I decided to add cooldowns to every project.
- fnoef 5mo ago
  Yeah, I agree, but then you are at the mercy of whatever vulnerability is found in the current version(s). It just feels like a lose-lose situation no matter what you do.
  - tpetry 5mo ago
    You can still update to new versions even if the new release is still in cooldown phase. You just have to be explicit that you want the new release. pnpm audit —fix for example will whitelist releases in cooldown phase when theres a known security issue for a version you currently use.
  - thrownthatway 5mo ago
    So long as we insist on everything from a light switch, the vacuum cleaner, security camera, clothes dryer, TV, car, and mobile phone being an always on, always online, Universal Turing Machine we’re not going to find a solution.
darkwi11ow 5mo ago
I use Tanstack in my projects. Last week when Tanstack got compromised, it was only my laziness that saved me -- was thinking about doing pnpm upgrade but got lazy and played some dota... Finished game was just going to pnpm upgrade, opened hacker news and boom! news hit. Since then, I had set up libvirt/qemu based VM with another Linux running in it specifically for development. Now I run all of docker, kubernetes, IDE, pnpm, uv, etc in that VM and removed them from host. The only write capable secret VM has access to, is my passphrase protected ssh key, which I can quickly revoke from my Github account in case of compromise. Feels much safer now.

wlkr 5mo ago

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.

cess11 5mo ago
Wondering about Mr Bones' Wild Ride and suspecting it might be a reference to the 1991 movie Nothing But Trouble I took a look, and found I had remembered it wrong. The roller coaster in that movie was called Mr Bonestripper, https://www.youtube.com/watch?v=NEZEgd8GjJc https://www.youtube.com/watch?v=NEZEgd8GjJc . Instead it comes from Roller Coaster Tycoon 2, https://knowyourmeme.com/memes/mr-bones-wild-ride https://knowyourmeme.com/memes/mr-bones-wild-ride . As for the comparison with spam, there we kind of settled on making people accept spam by vacuuming up their email addresses in pretty much every commercial and social computer network setting, giving it a veneer of legitimacy. I think it is likely to happen in this area too, perhaps some combination of Oracle licensing surveillance agent style software and automated dependency management, i.e. 'solving' supply chain malware by whitelisting some other malware.
- breezerbottles 5mo ago
  There's also Mr. Toad's Wild Ride at Disney parks, https://en.wikipedia.org/wiki/Mr._Toad%27s_Wild_Ride https://en.wikipedia.org/wiki/Mr._Toad%27s_Wild_Ride
  - 5mo ago

ares623 5mo ago

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.

throwa356262 5mo ago
Security by giving up

mentalgear 5mo ago

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.

wolfi1 5mo ago
how do containers solve the problem? if they are connected to the internet (and they are) you have got the same problem, if the credentials can be read by the container, at least to my understanding
- mentalgear 5mo ago
  For credential stealing, that is true, but at least it would protect your local machine. But I just read these worms also try container escape ...
  - silon42 5mo ago
    We need to prevent direct connections to internet for containers... once you have a proxy, predefined credentials (api keys) can maybe be added there (per container/target).
    - cyanydeez 5mo ago
      the model most people are talking about is in the cloud. for the harness to do useful work, it needs to talk to the cloud the trouble is, we need protocols that are software determined that force AI interaxtions into limited scope but currently theyre all just bash adjacent and inherit your tools.
  - fnoef 5mo ago
    You need to use full isolated VM with its own kernel. But then again, I've read somewhere that this malware is also trying to escape the VM isolation as well...

mentalgear 5mo ago

> 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) !

jeswin 5mo ago
> Make sure you're running a rootless VM engine (e.g. podman instead of docker) ! Aren't most people running docker rootless (at least on Linux)? Does podman do more?
- Maakuth 5mo ago
  The docker CLI tool is normally executed with user privileges, but there's dockerd, a daemon running as root that actually does the container execution.
  - cyanydeez 5mo ago
    im not sure people understand the security vectors. a user with docker permissions effectively has root permissions. often, docker in docker is used to manage docker orchestration. putinng a user in a docker and peoviding docker access is security through obscurity. on the flip side, i see people blindly installing tools and skills not understanding they are pushing context and capabilities without any significant security features. Imagine mythos is actually exceptional hacker. if you give it a well crafted malicious prompt, its going to even more insecure. the double edged sword is really fascinating to think about
    - jeswin 5mo ago
      Docker has not required root for a long time, at least on Linux. There's even a convenience script for it: https://get.docker.com/rootless https://get.docker.com/rootless Almost everyone I know installs docker rootless.
  - 5mo ago

jonkoops 5mo ago

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]. 1. https://pnpm.io/settings#allowbuilds https://pnpm.io/settings#allowbuilds 2. https://pnpm.io/cli/approve-builds https://pnpm.io/cli/approve-builds

wereHamster 5mo ago
After I upgraded pnpm to v11, I set all allowBuilds to false and have not observed any failures. Made me wonder why the packages even need build scripts. My guess is for obscure or old platforms, but for most users running on Linux or Darwin build scripts seem to be unnecessary.
- Tade0 5mo ago
  > Made me wonder why the packages even need build scripts. Historically it was to accommodate packages like the original SASS compiler: https://sass-lang.com/ruby-sass/ https://sass-lang.com/ruby-sass/ Other times it was to avoid shipping binaries due to, erm, safety concerns. The package would include code in a different language, which in turn would compile into a binary library or executable.
- n_e 5mo ago
  > Made me wonder why the packages even need build scripts As the name implies it's for building stuff. Most (all?) packages that use C++ FFI with node-gyp need it. A popular package that needs it is re2. Many newer packages bundle prebuilt native code as transitive dependencies, so build scripts are less needed than before.
perkovsky 5mo ago
Agree. Postinstall scripts should be explicit opt-in, not ambient capability. Most packages should not need arbitrary code execution during install. And when they do, that should be obvious during review. The default should probably be: install files, don’t run code.

knlsn 5mo ago

are these fixed removed now?

Brybry 5mo ago
Seems like it is fixed/removed: https://github.com/antvis/.github/commit/cb641113703e531ee43591d15cee52bc8a38e0c9 https://github.com/antvis/.github/commit/cb641113703e531ee43... Some are still on npm but marked "deprecated": https://www.npmjs.com/package/size-sensor/v/1.0.4?activeTab=code https://www.npmjs.com/package/size-sensor/v/1.0.4?activeTab=... As the article states, you can see in the package.json that the optionalDependencies references "@antv/setup": "github:antvis/G2#7cb42f57561c321ecb09b4552802ae0ac55b3a7a" I'm pretty sure those commits have been removed from github: https://github.com/antvis/G2/issues/7401#issuecomment-4484808335 https://github.com/antvis/G2/issues/7401#issuecomment-448480... https://github.com/antvis/G2/issues/7394 https://github.com/antvis/G2/issues/7394

somelamer567 5mo ago

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?

thrownthatway 5mo ago
We can’t even prevent shop lifting.
- somelamer567 5mo ago
  Shoplifting isn't a national security matter.
  - thrownthatway 5mo ago
    It’s an issue affecting the nation.
  - mminer237 5mo ago
    Most malware isn't either, especially with Node.
- sitkack 5mo ago
  Compared to what?
  - redsocksfan45 5mo ago
    [dead]
  - thrownthatway 5mo ago
    Are you ok? Compared to calling in air support on cyber criminals. How’s your reading comprehension coming along?

Outlook5813 5mo ago

another day, another npm hack.

AgentME 5mo ago

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/ https://cooldowns.dev/ has info about equivalent settings in other dependency managers like PyPI and Cargo.

sevenzero 5mo ago
Or just use dependencies from 6 years ago and never update them like most companies i ever worked for.
- halfcat 5mo ago
  Accidental true leadership
tom2tomtomtom 5mo ago
[dead]

rubnogueira 5mo ago

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 https://aube.en.dev/package-manager/jailed-builds.html But this feels like a cat/mouse game.

cyanydeez 5mo ago
dino was wired with security in mind, but you can see developers dont tend towards aecurity
- rubnogueira 5mo ago
  Because there is a time and effort cost to swap over to another framework/runtime even if it brings benefits, and security is always considered "good for now" unfortunately. That is what made Bun popular, and tools like uv/pip, oxlint/eslint, orbstack/docker desktop, and the list goes on. Drop-in replacements where we get 10x with little effort.
- epicide 5mo ago
  Because employers don't tend towards security. In fact, many actively punish somebody for "sandbagging" or simply taking too long if they even suggest a security concern.
- esafak 5mo ago
  What is dino?
no-name-here 5mo ago
> aube (npm/yarn/pnpm drop-in alternative) now has a "jailBuilds" flag that restricts access to network/filesystem access. 1. It seems like the restrictions are only for lifecycle scripts, so wouldn't help if/when the package's actual code had malicious code inserted? 2. Package managers like pnpm seem to entirely block lifecycle scripts by default, so I guess this is an in-between solution. Still, I guess it's a step in the right direction for those want or need to run lifecycle scripts specifically.

CafeRacer 5mo ago

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

aa-jv 5mo ago

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.

jgrahamc 5mo ago

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-coding.html https://blog.jgc.org/2026/04/raspberry-pi-as-isolated-ai-cod...

Shank 5mo ago
I mean that's lovely, but you still store confidential data, I assume, like credentials on your development machine? This doesn't solve anything but the least important "reinstall the OS post-compromise" step.
- jgrahamc 5mo ago
  On that machine there's Claude's authentication for my account so I can run Claude on it, a public key so I can SSH to the box, and a private key for GitHub access.

Havoc 5mo ago

Pretty wary of the entire JS/nodejs ecosystem at this stage.

matheusmoreira 5mo ago
Same. At this point I just started using virtual machines for any project that pulls in packages from outside Linux distribution repositories.
michalsustr 5mo ago
Given general software quality of the js ecosystem, the proliferation of supply chain attacks was just matter of time. I’m curious how other ecosystems will hold (eg Rust)
- freakynit 5mo ago
  And now, vibe-coding is just gonna take this to a whole another level.
- tadfisher 5mo ago
  NPM is an easy target because every package has the capability of interacting with your development environment by default, via pre/post-install scripts. Cargo has something similar with build.rs scripts, as does Cabal (Haskell). In JVM-land, thanks to binary distribution being the default, the number of packages you can usurp to achieve the same compromise is fairly small; essentially Maven and Gradle plugins. Which is why you should be extremely wary when, say, Sentry tells you to add them as a dependency by setting up their Gradle plugin. Not sure about sbt. Clojure source dependencies can provide "prep" scripts, which are not automatically run as part of a build, but still execute code on your machine. There's a pattern here: some build tools incorporate dependency-provided code as part of the consumer project's build, and that is a juicy attack surface. Packages which include such code, or are recently updated to include it, should be treated with extra scrutiny.
cozzyd 5mo ago
Yes... The only things I use from the JS ecosystem are {Claude,gemini}-cli which I fear will be compromised. Fortunately I run in them in their own user accounts with no e.g. ssh credentials, but I dead that's not enough especially for Gemini which probably has access to my entire Google account somehow.

nojs 5mo ago

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.

quantumleaper 5mo ago
This is what many AI supply-chain security startups (like the one that posted the article) are already doing with all NPM packages, so save yourself the Claude tokens. All of these compromises were detected within minutes, but it takes some time (<1 hour) for NPM to unpublish all of the affected packages.
- PAndreew 5mo ago
  Sorry for my ignorance, but then couldn't we build this into NPM itself? So before a package is publicly available it would be quaranteened and checked.
madamelic 5mo ago
Super dumb question as someone who has been using some form of AI for dev since 2023: How does having an AI audit external code help? Can they not be prompt injected to ignore a malicious change? I guess I am sort of concerned that they are a pretty thin layer and even if you put "DO NOT ALLOW PROMPT INJECTION", it's a bit like saying "make no mistakes". There _is_ a priority between `system` and `user` level messages as I had recalled, so a specifically made tool that has its own system prompt should prevent injection while asking Claude CLI could still allow for prompt injection. What are your thoughts and experience?
- Yokohiii 5mo ago
  There are prompt guard classifiers that can detect prompt injections, but they are not perfect (false positives, obfuscation) and should be only a part of the defense. The concern is real and unsolved. I think security researchers have an advantage here because they still can fall back to manual audits if their automated analysis (or scores thereof) is off.

mashijian 5mo ago

[flagged]

teddyh 5mo ago

‘No way to prevent this’, Says Only Development Community Where This Regularly Happens — <https://itnext.io/no-way-to-prevent-this-says-only-development-community-where-this-regularly-happens-8ef59e6836de?gi=4f635bc98645 https://itnext.io/no-way-to-prevent-this-says-only-developme...>

deleted 5mo ago
[deleted]
anonym29 5mo ago
"A well administered supply chain, being necessary to the freedom of an open internet, the right of the developers to keep and bear hundreds of uninspected transitive dependencies, shall not be infringed."
ajross 5mo ago
The Node ecosystem happens to be more vulnerable for social and software design reasons, it's true. But people need to be aware that PyPI and Cargo et. al. are not in any fundamental way less vulnerable. This will happen there too.
- zarzavat 5mo ago
  To expand on this, PyPI is slightly less vulnerable because Python users tend to install mega packages (such as numpy or django) and do not frequently interact with their package manager. There is also not a culture of using sub-dependencies. Cargo is essentially the same as NPM though, it's only "safer" because it's less popular. Although the situation on NPM is extremely uncomfortable, you're probably less likely to get hit if you take reasonable precautions than on PyPI, simply because NPM is getting scanned more often. Most of these attacks on NPM have been detected and pulled days before my min age kicks in. A sleeper attack on PyPI could be devastating.
- zahlman 5mo ago
  In fact, attacks like Shai-Hulud explicitly attempt to get into PyPI, and have succeeded to a lesser extent. But aside from the package-size / -complexity issue pointed out in a sibling comment, PyPI also tries a fair bit to monitor for incoming malware (and there's a "report project as malware" button on each project page). Also, there are no post-install scripts (of course, the code can detect when it's being run for the first time in the installed environment); and pre-install scripts are only included in sdists[0]. So you can easily[1] configure your installer such that you at least won't get pwned at install time, at the cost that some[2] packages can't be installed that way. And then you can go inspect, run a security scanner over, etc. whatever got installed; wheel installations just copy things to well-defined locations and generate simple wrapper scripts by strict rules. [0]: I.e., when the project is "being built from source", which generally is only necessary when it includes non-Python code directly and the maintainer hasn't pre-built that code for your system. [1]: Notwithstanding that, with pip, many actions that you'd expect not to get you pwned totally can. Such as, for example, explicitly telling it to download an sdist and not install it; as I discussed in https://zahlman.github.io/posts/python-packaging-3/ https://zahlman.github.io/posts/python-packaging-3/ . [2]: In practice, a pretty small fraction of what typical developers would actually care about, at least outside of specific niches. I'm told there are some niches where it's a big problem, but honestly they're lucky that this kind of build-install orchestration sort-of works at all.

kixxauth 5mo ago

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

no-name-here 5mo ago
Wouldn't just having devs pin/not upgrade packages accomplish about as much, have the added benefit that if a package is discovered malicious it would be removed from npm but if already vendored you’d still have the vulnerability on your vendored copy, and pinning versions seems like it would be more likely for devs to do than vendoring?
- cj 5mo ago
  Pinning the version also avoids the risk of accidentally introducing new vulnerabilities while reimplementing the package yourself.
- erikerikson 5mo ago
  Not to support the GPs choices (they are not mine) but pinned dependencies can get grumpy over time with endless LTS migrations.
- kixxauth 5mo ago
  Yeah, pinning dependencies is very similar to vendoring or cloning them. By cloning, you get to know the code better and how it is structured, plus you cherry pick only the features you want. But, like you said, you are at risk of introducing new vulnerabilities. I'd just prefer making that bet on myself than someone I don't know

alex1sa 5mo ago

[flagged]

827a 5mo ago

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.

pier25 5mo ago
Third parties can detect compromised packages. It’s ridiculous Microsoft doesn’t.
- lyu07282 5mo ago
  They can and do indeed detect those attacks, it's just from Microsoft's POV a feature of Microsoft Defender (on Windows and Cloud) they sell: https://www.microsoft.com/en-us/security/blog/2025/12/09/shai-hulud-2-0-guidance-for-detecting-investigating-and-defending-against-the-supply-chain-attack/ https://www.microsoft.com/en-us/security/blog/2025/12/09/sha... https://azure.microsoft.com/en-us/pricing/details/defender-for-cloud/ https://azure.microsoft.com/en-us/pricing/details/defender-f... So this is presumably why they will never address this in npm itself.
  - grim_io 5mo ago
    Maybe they should prove their shit works first. What a wonderful marketing opportunity! Leave it to Microsoft to blindly ignore it.
    - lyu07282 5mo ago
      No look at the article of this post, it's by SafeDep they are in the same business as Microsoft with their Defender product line. They both publish near identical post mortems with subtle hints at how their product would've defended you against the attack. Why should Microsoft fix the cause instead of selling the cure to each business individually?
      - 5mo ago

morpheos137 5mo ago

it seems obvious to me the ability to push code to public repositories shluld be tied to real human identity.

wang_li 5mo ago
Using code from these repositories should be considered the same as licking toilet seats at highway rest stops. There’s something wrong with you if you do it.

gherkinnn 5mo ago

> 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. 0 - https://docs.deno.com/runtime/reference/std/ https://docs.deno.com/runtime/reference/std/

tln 5mo ago
I'm not sure any of the packages here would be part of a "better standard library". Do any language standard libraries have a "3 hours ago" formatter? Thats what timeago.js does Maybe slice.js, which just does python-style indexing with negative numbers. TC39 already made array.at() and array.slice() handle negative numbers.
- WorldMaker 5mo ago
  > Do any language standard libraries have a "3 hours ago" formatter? Thats what timeago.js does There's also a platform feature for that now: Intl.RelativeTimeFormat: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/RelativeTimeFormat https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... It asks you to do the basic time math to determine your granularity so there's still a role for a library, but also that time math gets easier with Temporal: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... (Specifically `Temporal.Now.instant().since(somePastInstant)` returns a Temporal.Duration that you can relatively easily determine the highest granularity you want and pass that to an Intl.RelativeTimeFormat instance. Also Intl.DurationFormat which is what a Temporal.Duration's `toLocaleString()` uses may also be good enough in many "x hours ago" type situations, though it is over-precise for them.)
  - tln 5mo ago
    Thanks for that! So, back to the GP post - TC39 should make a bigger stdlib. Lets say timeago.js is warranted (as a polyfill and terser API) AND TC39 is taking action. On slice.js, TC39 took action AND usage is unwarranted since the functionality is widely available. Maybe a stride.js would be needed. There are 2 modules where npm's culture of "tiny modules because the stdlib is impoverished" holds - but the issue isn't TC39 really. There are 312 modules that aren't related to npm's culture of "tiny modules because the stdlib is impoverished".

btown 5mo ago

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?

peterldowns 5mo ago
Yes. This is partially why other ecosystems don’t see as many supply chain attacks.
zahlman 5mo ago
> and trust that NPM at least gets their "you can't republish to an old version" bare-minimum constraint right? ... Does NPM not create full lockfiles, with hashes and pinned transitive dependencies and everything?
- btown 5mo ago
  Yes, and the problem here is that most projects have automated systems that automatically update those lockfiles on every upstream release of a library, under an assumption that minor releases are either security patches or bugfixes that would immediately be useful to the consuming project. IMO this is built on a pre-ShaiHulud, pre-AI set of assumptions, and should be evaluated from first principles with today's security situation.
  - zahlman 5mo ago
    My point was the "with hashes" part. You aren't in fact "trusting" NPM to ensure that old versions aren't replaced if the package installer is verifying the hash.
- esafak 5mo ago
  https://docs.npmjs.com/cli/v11/configuring-npm/package-lock-json https://docs.npmjs.com/cli/v11/configuring-npm/package-lock-...

mrgoldenbrown 5mo ago

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.

troad 5mo ago

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.

austin-cheney 5mo ago
If you serve any third party logic, such as advertisements, your code is just as potentially compromised.
- troad 5mo ago
  Only the frontend, which is already untrusted. Any risk would be restricted to individual users who used the compromised frontend to communicate something sensitive, and while that's not great, it is significantly better than the backend being compromised. A very significant reduction in blast radius. Funnily enough, I don't actually think I do serve third party JS, though. Don't serve ads, don't use external telemetry, don't use JS CDNs. I don't think you have to go quite as far as I do, though - I imagine if your ads are Google AdSense or something, you're probably going to be fine.
ZiiS 5mo ago
It is your development machine's AWS keys they want. The server's keys should be too finly scooped anyway.
- troad 5mo ago
  Not likely to be a major risk if you update every few months, to some major version that's already over a month old.
- 5mo ago

freakynit 5mo ago

[flagged]

KolmogorovComp 5mo ago

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.

ruined 5mo ago
at amazon, they maintain a private internal registry of packages with approved licenses and audits. this has been in place for several years. i assume other big corps enforce similar policies
- philipwhiuk 5mo ago
  If your company not running an internal proxy at minimum you're stupid - you have no audit function for what libraries are being pulled.
  - HDBaseT 5mo ago
    Not every company has tons of available funds to run 300 different internal services to "protect" itself.
- a1o 5mo ago
  Do you know if they are using any product like JFrog for this or rolling their own?
  - jon-wood 5mo ago
    This is Amazon, the company where the stuff they rolled their own now makes more money than the business it was rolled for: https://aws.amazon.com/codeartifact/ https://aws.amazon.com/codeartifact/

perdomon 5mo ago

writing your own code is only harbor in this storm. vanilla js cries out into the night sky. will you answer?

pmdr 5mo ago
That and vendored HTMX. Nobuild. JS on the backend looks more and more like a very bad idea.

a1o 5mo ago

[dead]

timfsu 5mo ago

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

freakynit 5mo ago

Collected all the attacks that happened in the npm ecosystem in past 1 year here: https://npm-supply-chain-attacks-25-26.pagey.site/ https://npm-supply-chain-attacks-25-26.pagey.site/

kjok 5mo ago
Please also collect responses from people, you'd find a pattern: a new attack is launched, people make noise, and later go back to installing packages the same way. Enterprises already use private registries to combat such attacks, vulnerable folks include individual devs and small teams.
- freakynit 5mo ago
  Want to.. but I'll need to first integrate social-media and forum scanning in my tool. Haven't done that yet. But, it's a good feature to have. Thanks.. gonna integrate now :)
HDBaseT 5mo ago
Did Claude generate this site? The scroll seems to jump all over the place on my device.
- freakynit 5mo ago
  yep... fixed it in new version. Thanks for mentioning.
  - HDBaseT 5mo ago
    No worries, works fine on my end now!

tln 5mo ago

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.

nepthar 5mo ago

“No way to prevent this” says only package manager where this regularly happens.

bakugo 5mo ago
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?
- freakynit 5mo ago
  Yep. 1. Every day there's a new package. 2. Then five more packages appear so you don't have to write that one terrifying line of JavaScript yourself. 3. Then someone writes a wrapper around those five packages. 4. Then someone writes a "modern, lightweight, zero-config" wrapper around the wrapper. 5. Then a framework adopts it, a build tool requires it, and suddenly your todo app has a dependency graph that looks like international diplomacy. 6. Out of 100 devs building the same product, there are now 300 different dependency combinations, all somehow involving 'left-pad' spiritually if not literally. 7. Half the packages are maintained by one person, unpaid, at 2 a.m., after getting yelled at in GitHub issues. 8. The other half were abandoned three years ago but still have 40 million weekly downloads because removing them would break civilization. 9. Pinning dependencies sounds nice until the ecosystem tells you, "sorry, this package only works with Node 22, this plugin needs Node 18, and this transitive dependency has discovered ESM enlightenment." 10. So everyone lives on the bleeding edge, except nobody agrees where the edge is, and the bleeding part is very real. So yeah, npm is not uniquely cursed because JavaScript devs are worse. It's cursed because it turned code reuse into a lifestyle, dependency trees into rainforests, and 'npm install' into an act of faith.
  - MadnessASAP 5mo ago
    > 7. Half the packages are maintained by one person, unpaid, at 2 a.m., after getting yelled at in GitHub issues. By a manager for for a >$1 billion market cap corporation who doesnt understand that the one person isnt an employee.

smsm42 5mo ago

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)?

staticassertion 5mo ago
The solution is to do exactly what you suggest - separate access. In CI this is a matter of having your "build/test" jobs happen separately from your "deploy/publish" jobs. The trickier part is dev environments, but ideally you take a similar approach. The place that devs do `npm install` should be isolated from, say, your browser / ssh keys etc. Package manager support would be an amazing win here since you'd have an easier time managing the isolation but you can do this today.

freakynit 5mo ago

npm, the ecosystem: https://npm-the-ecosystem.pagey.site/ https://npm-the-ecosystem.pagey.site/

tomxor 5mo ago

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.

hirako2000 5mo ago
Or simply use pnpm.
- tomxor 5mo ago
  That's helpful to prevent individual secret harvesting, however it does not protect you from potential silent downstream effects in packages. i.e. inclusion of malicious code in libraries you depend on, this could be as simple as inserting a cryptominer, or as severe as data exfil in a front end package. This default can affect all consumers of NPM packages, regardless of whether you use yarn, pnpm or npm itself, because most package maintainers use NPM. This is why it's NPM's responsibility to change this default in order to prevent spread of malware in packages.
deleted 5mo ago
[deleted]
bakkoting 5mo ago
There's an RFC for this: https://github.com/npm/rfcs/pull/868 https://github.com/npm/rfcs/pull/868
josephg 5mo ago
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.

codedokode 5mo ago

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.

urbandw311er 5mo ago

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-c9j4-9m59-847w 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 :-(

HALtheWise 5mo ago

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.