9 ms·

NPM flooded with malicious packages downloaded more than 86k times

364 points by jnord 1y ago

edoceo 1y ago
Happy I keep a mirror of my deps, that I have to "manually" update. But also, the download numbers are not really accurate for actual install count - for example each test run could increment.
robpco 1y ago
Alternate article with more detailed description of exploit: https://www.bleepingcomputer.com/news/security/phantomraven-attack-floods-npm-with-credential-stealing-packages/ https://www.bleepingcomputer.com/news/security/phantomraven-...
crtasm 1y ago
>When you run npm install, npm doesn't just download packages. It executes code. Specifically, it runs lifecycle scripts defined in package.json - preinstall, install, and postinstall hooks. What's the legitimate use case for a package install being allowed to run arbitrary commands on your computer? Quote is from the researchers report https://www.koi.ai/blog/phantomraven-npm-malware-hidden-in-invisible-dependencies https://www.koi.ai/blog/phantomraven-npm-malware-hidden-in-i... edit: I was thinking of this other case that spawned terminals, but the question stands: https://socket.dev/blog/10-npm-typosquatted-packages-deploy-credential-harvester https://socket.dev/blog/10-npm-typosquatted-packages-deploy-...
- j1elo 1y ago
  Easy example that I know of: the Mediasoup project is a library written in C++ for streaming video over the internet. It is published as a Node package and offers a JS API. Upon installing, it would just download the appropriate C++ sources and compile them on the spot. The project maintainers wanted to write code, not manage precompiled builds, so that was the most logical way of installing it. Note that a while ago they ended up adding downloadable builds for the most common platforms, but for anything else the expectation still was (and is, I guess) to build sources at install time.
  - exe34 1y ago
    how hard would it be to say "upon first install, run do_sketchy_shit.sh to install requirements"?
    - lelandbatey 1y ago
      People want package managers to do that for them. As much as I think it's often a mistake (if your stuff requires more than expanding archives different folders to install, then somewhere in the stack something has gone quite wrong), I will concede that because we live in an imperfect world, other folks will want the possibility to "just run the thing automatically to get it done." I hope we can get to a world where such hooks are no longer required one day.
      - exe34 1y ago
        yes that's why npm is for them. I'd rather download the libraries that I need one by one.
    - SoftTalker 1y ago
      But most users would do that without inspecting it at all, and a fair number would prefix it with “sudo” out of habit.
      - cindyllm 1y ago
        [dead]
      - nkrisc 1y ago
        But that’s at least a conscious and explicit action the user chooses to make and is explicitly aware of making.
      - hombre_fatal 1y ago
        That's fine, and it's still better than doing it on install.
      - 1y ago
- squidsoup 1y ago
  pnpm v10 disables all lifecycle scripts by default and requires the user to whitelist packages. https://github.com/orgs/pnpm/discussions/8945 https://github.com/orgs/pnpm/discussions/8945
  - chrisweekly 1y ago
    One of the many reasons there is no good reason to use npm; pnpm is better in every way.
  - sroussey 1y ago
    It’s just security theater in the end. You can just as easily put all that stuff in the package files since a package is installed to run code. You have that code then do all the sketchy stuff. What’s needed is an entitlements system so a package you install doesn’t do runtime stuff like install crypto mining software. Even then…
    - theodorejb 1y ago
      I would expect to be able to download a package and then inspect the code before I decide to import/run any of the package files. But npm by default will run arbitrary code in the package before developers have a chance to inspect it, which can be very surprising and dangerous.
      - sroussey 1y ago
        npm used to do that. bun never did. No idea about the past for pnpm or yarn.
    - Mogzol 1y ago
      A package, especially a javascript package, is not necessarily installed to run code, at least not on the machine installing the package. Many packages will only be run in the browser, which is already a fairly safe environment compared to running directly on the machine like lifecycle scripts would. So preventing lifecycle scripts certainly limits the number of packages that could be exploited to get access to the installing machine. It's common for javascript apps to have hundreds of dependencies, but only a handful of them will ever actually run as code on the machine that installed them.
- vorticalbox 1y ago
  One use case is downloading of binaries. For example mongo-memory-server [0] will download the mongoDB binary after you have installed it. [0] https://www.npmjs.com/package/mongodb-memory-server https://www.npmjs.com/package/mongodb-memory-server
  - 8note 1y ago
    why would i want that though, compared to downloading that binary in the install download? the npm version is decoupled from the binary version, when i want them locked together
    - jonhohle 1y ago
      I think it falls into a few buckets: A) maintainers don’t know any better and connect things with string and gum until it most works and ship it B) people who are smart, but naive and think it will be different this time C) package manager creators who think they’re creating something that hasn’t been done before, don’t look at prior art or failures, and fall into all of the same holes literally every other package manager has fallen into and will continue to fall into because no one in this industry learns anything.
  - madeofpalk 1y ago
    And now optional dependencies negate the need for this. Your package manager can just download platform-specific binaries automatically https://docs.npmjs.com/cli/v7/configuring-npm/package-json#optionaldependencies https://docs.npmjs.com/cli/v7/configuring-npm/package-json#o...
- DangitBobby 1y ago
  I seem to recall Husky at one point using lifecycle hooks to install the git hooks configured in your repository when running NPM install.
  - mock-possum 1y ago
    Playwright does it too. Or at least, I’ve worked a place that used npm install hooks to setup husky and install playwright browser binaries
- interstice 1y ago
  Notable times this has bitten me include compiling image compression tools for gulp and older versions of sass, oh and a memorable one with openssl. Downloading a npm package should ideally not also require messing around with c compilation tools.
- deleted 1y ago
  [deleted]
- zahlman 1y ago
  > doesn't just download packages. It executes code. Specifically, it It pains me to remember that the reason LLMs write like this is because many humans did in the training data.
  - jsrozner 1y ago
    That whole koi blog post is sloppy AI garbage, even if it's accurate. So obnoxious.
  - marcus_holmes 1y ago
    Is the objection the small sentence that could have been a clause?
    - zahlman 1y ago
      The objection is to the redundant, flowery prose overall, and the overall inaccuracy. (Of course the installer "doesn't just download packages"; installation at minimum would also involve unpacking the archive and putting the files in the right place....) In about as much text, we could explain far better why and how NPM's behaviour is risky: > When you install a package using `npm install`, NPM may also run arbitrary code from the package, from multiple hook scripts specified in `package.json`, before you can even audit the code.
- ChrisMarshallNY 1y ago
  Swift Package Manager[0] executes a Swift script. The Package.swift file[1] (the manifest) is actually an executed source file. I assume that it's heavily sandboxed, though, so it may be difficult to leverage. [0] https://docs.swift.org/swiftpm/documentation/packagemanagerdocs/ https://docs.swift.org/swiftpm/documentation/packagemanagerd... [1] https://developer.apple.com/documentation/packagedescription https://developer.apple.com/documentation/packagedescription
- bandrami 1y ago
  OK but have you seen how many projects' official installation instructions are some form of curl | bash?
  - codedokode 1y ago
    In most cases to use a library you just need to download files and place them into a directory.
  - dns_snek 1y ago
    Both post-install scripts and curl|bash scripts are just scapegoats of supply chain security with similar faulty reasoning.
- Timshel 1y ago
  There is the "--ignore-scripts" option and had no issue using it for now.
- maxloh 1y ago
  Many front end tools are written in a faster language. For example, the next version of TypeScript compiler, SASS, SWC (minifier), esbuild (bundler used by Vite), Biome (formatter and linter), Oxc (linter, formatter and minifier), Turbopack (bundler), dprint (formatter), etc. They use proinstall script to fetch pre-built binaries, or compile from source if your environment isn't directly supported.
- styanax 1y ago
  > What's the legitimate use case for a package install being allowed to run arbitrary commands on your computer? The paradigm itself has been in package managers since DEB and RPM were invented (maybe even Solaris packages before that? it's been a minute since I've Sun'd); it's not the same as NPM, a more direct comparison is the Arch Linux AUR - and the AUR has been attacked to try and inject malware all year (2025) just like NPM. As of the 26th (5 days ago) uploads are disabled as they get DDOSed again. https://status.archlinux.org/ https://status.archlinux.org/ (spirit: it's the design being attacked, pain shared between AUR and NPM as completely disparate projects). More directly to an example: the Linux kernel package. Every Linux distribution I'm aware of runs a kernel package post-install script which runs arbitrary (sic) commands on your system. This is, of course, to rebuild any DKMS modules, build a new initrd / initramfs, update GRUB bootloader entries, etc. These actions are unique outputs to the destination system and can't be packaged. I have no data in front of me, but I'd speculate 70% (?) of DEB/RPM/PKG packages include pre / post install/uninstall scriptlets, it's very common in the space and you see it everywhere in use.
  - cozzyd 1y ago
    Right every library will want to run ldconfig for example.
  - a96 1y ago
    There's a huge difference between running a script inside an audited package from a curated source and the curl | sh installers.
- matheusmoreira 1y ago
  There's nothing inherently wrong with that. The problem is npm allows any random person to upload packages. It's completely untrusted. Contrast that with Linux distributions which have actual maintainers who take responsibility for their packages. They don't generally allow malware to make it into the official software repositories. In many cases they went as far as meeting each other in person just to set up a decentralized root of trust with PGP. It's so much better and more trustworthy. The truth is npm, pip, rubygems, cargo and all the other programming language package managers are just fancier versions of the silly installation instructions you often find in README files that tell people to curl some script and pipe it into bash.
  - graemep 1y ago
    Even when random people are allowed to contribute (AUR, PPAs) there seems to be more scrutiny and fewer incidents. Possibly because they are secondary to the main repos and possibly because the people who use them are made aware of the risks. NPM etc. are a bit like Arch would be if everything was in AUR.
    - cozzyd 1y ago
      With PPAs or COPR (or third party repositories, e.g. slack) you have to explicitly enable each repository too. Even if a repository is enabled by package you are prompted the first time a new repository is used (actually I don't know if that's true when gpgcheck is disabled? If not this would be an easy fix in apt/dnf)
ghusto 1y ago
When people ask me what's so wrong with lowering the bar of entry for engineering, I point to things like this.
- The_President 1y ago
  Engineering used as a title should be regulated in the software industry; it was always a title reserved for a role that requires accountability. In software, it became used so casually without legal restriction that full stack developers started using it.
  - michaelcampbell 1y ago
    This is most often pushed on the person by their company. I don't have an Eng degree nor certification, but my company forces my title to be "... Engineer", which I dislike, but I've been told this is just how it is.
cxr 1y ago
Imagine if we had a system where you could just deposit the source code for a program you work on into a "depository". You could set it up so your team could "admit" the changes that have your approval, but it doesn't allow third parties to modify what's in your depository (even if it's a library that you're using that they wrote). When you build/deploy your program, you only compile/run third-party versions that have been admitted to the depository, and you never just eagerly fetch other versions that purport to be updates right before build time. If there is an update, you can download a copy and admit it to your repo at the normal time that you verify that your program actually needs the update. Even if it sounds far-fetched, I imagine we could get by with a system like this.
- edoceo 1y ago
  That is exactly what I do.
- anthk 1y ago
  You are describing BSD ports from the 90's. FreeBSD ports date back to 1993.
  - ok123456 1y ago
    Also, Gentoo dating back to 2003.
  - SoftTalker 1y ago
    And today.
- chrisweekly 1y ago
  You're describing a custom registry. These exist IRL (eg jFrog Artifactory). Useful for managing allow-listed packages which have met whatever criteria you might have (eg CVE-free based on your security tool of choice). Use of a custom registry, and a sane package manager (pnpm, not npm), and its lockfile, will significantly enhance your supply-chain security.
  - 1y ago
650REDHAIR 1y ago
As a hobbyist how do I stay protected and in the loop for breaches like this? I often follow guides that are popular and written by well-respected authors and I might be too flippant with installing dependencies trying to solve a pain point that has derailed my original project. Somewhat related, I also have a small homelab running local services and every now and then I try a new technology. occasionally I’ll build a little thing that is neat and could be useful to someone else, but then I worry that I’m just a target for some bot to infiltrate because I’m not sophisticated enough to stop it. Where do I start?
- ajross 1y ago
  > As a hobbyist how do I stay protected and in the loop for breaches like this? For the case of general software, "Don't use node" would be my advice, and by extension any packaging backend without external audit and validation. PyPI has its oopses too, Cargo is theoretically just as bad but in practice has been safe. The gold standard is Use The Software Debian Ships (Fedora is great too, arch is a bit down the ladder but not nearly as bad as the user-submitted madness outside Linux). But it seems like your question is about front end web development, and that's not my world and I have no advice beyond sympathy. > occasionally I’ll build a little thing that is neat and could be useful to someone else, but then I worry that I’m just a target for some bot Pretty much that's the problem exactly. Distributing software is hard. It's a lot of work at a bunch of different levels of the process, and someone needs to commit to doing it. If you aren't willing to commit your time and resources, don't distribute it in a consumable way (obviously you can distribute what you built with it, and if it's appropriately licensed maybe someone else will come along and productize it). NPM thought they could hack that overhead and do better, but it turns out to have been a moved-too-fast-and-broke-things situation in hindsight.
  - squidsoup 1y ago
    Having spent a year trying to develop against dependencies only provided by a debian release, it is really painful in practice. At some point you're going to need something that is not packaged, or newer than the packaged version in your release.
throwaway81523 1y ago
"It's always NPM."
- LtWorf 1y ago
  Eh sometimes it's pypi
gbransgrove 1y ago
Because these are fetching dependencies in the lifecycle hooks, even if they are legitimate at the moment there is no guarantee that it will stay that way. The owner of those dependencies could get compromised, or themselves be malicious, or be the package owner waiting to flip the switch to make existing versions become malicious. It's hard to see how the lifecycle hooks on install can stay in their current form.
severino 1y ago
I wonder what could one do if he wants to use NPM for programming with a very popular framework (like Angular or Vue) and stay safe. Is just picking a not very recent version of the top level framework (Angular, etc.) enough? Is it possible to somehow isolate NPM so the code it runs, like those postinstall hooks, doesn't mess with your system, while at the same time allowing you to use it normally?
- theodorejb 1y ago
  One option to make it a little safer is to add ignore-scripts=true to a .npmrc file in your project root. Lifestyle scripts then won't run automatically. It's not as nice as Pnpm or Bun, though, since this also prevents your own postinstall scripts from running (not just those of dependencies), and there's no way to whitelist trusted packages.
worik 1y ago
This has been going on for years now. I have used Node, I would not go near the NPM auto install Spyware service. How is it possible that people keep this service going, when it has been compromised so regularly? How's it possible that people keep using it?
ashishb 1y ago
Here's my `npm` command these days. It reduces the attack surface drastically. alias npm='docker run --rm -it -v ${PWD}:${PWD} --net=host --workdir=${PWD} node:25-bookworm-slim npm' - No access to my env vars - No access to anything outside my current directory (usually a JS project). - No access to my .bashrc or other files. Ref: https://ashishb.net/programming/run-tools-inside-docker/ https://ashishb.net/programming/run-tools-inside-docker/
- sthuck 1y ago
  That definitely helps and worth doing. On Mac though I guess you need to move the entire development to containers due to native dependencies.
  - chuckadams 1y ago
    My primary dev environment is containers, but you can do a hell of a lot with nix on a mac.
- genpfault 1y ago
  > triple-backtick code blocks If only :(
- phiresky 1y ago
  That seems a bit excessive to sandbox a command that really just downloads arbitrary code you are going to execute immediately afterwards anyways? Also I can recommend pnpm, it has stopped executing lifecycle scripts by default so you can whitelist which ones to run.
  - simpaticoder 1y ago
    pnpm has lots of other good attributes: it is much faster, and also keeps a central store of your dependencies, reducing disk usage and download time, similar to what java/mvn does.
  - ashishb 1y ago
    > That seems a bit excessive to sandbox a command that really just downloads arbitrary code you are going to execute immediately afterwards anyways? I won't execute that code directly on my machine. I will always execute it inside the Docker container. Why do you want to run commands like `vite` or `eslint` directly on your machine? Why do they need access to anything outside the current directory?
noosphr 1y ago
A day ago I got down voted to hell for saying that the JavaScript ecosystem has rotted the minds of developers and any tools that emulate npm should be shunned as much as possible - they are not solutions, they are problems. I don't usually get to say 'I told you so' within 24 hours of a warning, but JS is special like that.
- cogman10 1y ago
  There's nothing really specially about the JS ecosystem that creates this problem. Plenty of others could fall in the same way, including C++ (see xz). The problem is we've been coasting on an era where blind trust was good enough an programming was niche enough.
  - procaryote 1y ago
    There's a culture of micro-dependencies. In c++, most people wouldn't publish a library that does the equivalent of (1 == value % 2). Even if they did, almost no one would use it. For npm, that library will not only exist, it will have several dependencies and millions of downloads
    - cogman10 1y ago
      That increases the surface area, which is certainly bad. But that doesn't really mean the risk isn't similarly there for C++. A few years back, the university of Minnesota was banned from the kernel (are they still banned?) for testing this exact theory. They tried to figure out how hard it would be to inject an intentional CVE into the kernel. [1] https://www.bleepingcomputer.com/news/security/linux-bans-university-of-minnesota-for-committing-malicious-code/ https://www.bleepingcomputer.com/news/security/linux-bans-un...
      - procaryote 1y ago
        Of course, it's a risk with any dependency, but for a small number of dependencies you're more likely to be able to do some level of vetting. The university of Minnesota would have had a much easier time not getting caught if there had been a tree of thousands of independently maintained dependencies
jtokoph 1y ago
Keep in mind that the vast majority of the 86,000 downloads are probably automated downloads by tools looking for malicious code, or other malicious tools pulling every new package version looking for leaked credentials. When I iterate with new versions of a package that I’ve never promoted anywhere, each version gets hundreds of downloads in the first day or two of being published. 86,000 people did not get pwnd, possibly even zero.
- userbinator 1y ago
  Or it's some poor idiot's CI repeatedly downloading them, and for a zombie project that no one will ever use.
- marcus_holmes 1y ago
  As TFA says, they're targeting package names that are somewhere in LLM training data but don't actually exist, so are being hallucinated by LLMs. And there's now a large number of folks with zero clue busy vibe-coding their killer app with no idea that bad things can happen. I would not be surprised to find that 80%+ of those 86,000 people got pwned.
- hinkley 1y ago
  When I published a library it got about 300 downloads a week for the first few and then dropped down to about 100. That would be a lot of weeks. > Many of the dependencies used names that are known to be “hallucinated” by AI chatbots. There’s more here than that.
Uptrenda 1y ago
I dub thee "node payload manager."
akagusu 1y ago
Unpopular opinion: why not reduce the dependency on 3rd party packages? Why not reduce the number of dependencies so you can know what code you are using?
- BobbyTables2 1y ago
  I’ve wondered this for so long, I questioned my own sanity.
- gavmor 1y ago
  Because then I would have to test, write, and maintain that code—and it becomes susceptible to leaky abstractions!
- alt227 1y ago
  You have a choice, reinvent the wheel or use someone elses wheel.
deleted 1y ago
[deleted]
ab_testing 1y ago
Given the recent npm attacks, is it even safe to develop using npm. Whenever I start a react project, it downloads hundreds of additional packages which I have mo idea about what they do. As a developer who has learnt programming as a hobby, is it better to stick to some other safe ways to develop front end like thyme leaf or plain js or something else. When I build backend in flask or Django, I specifically type the python packages that I need. But front end development seems like a Pandora box of vulnerabilities
- fragmede 1y ago
  Just a heads up that Pypi isn't immune from the same attack, with "Pypi supply chain attack" into Google revealing a (much smaller) number of packages that turned out to be malware. Some were not misspellings either, with one being a legitimate package that got hacked via GitHub Actions and a malicious payload added to the otherwise legitimate package.
  - tjpnz 1y ago
    No language ecosystem is but NPM/Node still encourages this idea (borrowed elsewhere and interpreted poorly) that everything must be its own tiny package and that it's acceptable to author libraries consisting of thousands of transitive dependencies from potentially dubious sources. Just this week I saw one (unmaintained dependency of a popular package) which consisted of a list of a dozen SQL operators. Anywhere else you would just write the damn code, maybe add a comment that these are the SQL-92 operators and be done with it literally forever. But in Node land that would be viewed as an antipattern which only another package can fix. It's a security and maintenance nightmare that can only be explained by laziness and outright stupidity.
    - silverwind 1y ago
      It's a misconception that NPM or Node encourage this, because they don't. There are a few package authors that are doing it that way (some even paid by download count), but that's their opinion. Recently there is a trend towards minimal-dependency packages and I would certainly recommend auditing every package for its dependencies before using it.
creativeSlumber 1y ago
> Many of the dependencies used names that are known to be “hallucinated” by AI chatbots. Developers frequently query these bots for the names of dependencies they need. LLM developers and researchers have yet to understand the precise cause of hallucinations or how to build models that don’t make mistakes. After discovering hallucinated dependency names, PhantomRaven uses them in the malicious packages downloaded from their site. I found it very interesting that they used common AI hallucinated package names.
bytefish 1y ago
I feel super uneasy developing Software with Angular, Vue or any framework using npm. The amount of dependencies these frameworks take is absolutely staggering. And just by looking at the dependency tree and thousands of packages in my node_modules folder, it is a disaster waiting to happen. You are basically one phishing attack on a poor open source developer away from getting compromised. To me the entire JavaScript ecosystem is broken. And a typo in your “npm -i” is sufficient to open up yourself for a supply-chain attack. Could the same happen with NuGet or Maven? Sure! But at least in these languages and environments I have a huge Standard Library and very few dependencies to take. It makes me feel much more in control.
- kigiri 1y ago
  Deno solves this, it's not a JavaScript Issue, it's a Node.JS / NPM issue.
  - Sander_Marechal 1y ago
    How does Deno solve this? Genuine question by the way. I'm not trying to be snarky.
    - bytefish 1y ago
      It provides a runtime, that sandboxes your application and requires you to give explicit permissions for file system operations and network requests. This limits the attack surface, when it comes to installing malicious dependencies, that npm happily installs for you. So yes, I was wrong and my previous comment a hyperbole. A big problem is npm, and not JavaScript. My point about the staggering amount of dependencies still holds though.
      - int_19h 1y ago
        Of course, this only works so long as the sandbox is secure. There have been attempts to do this kind of sandboxing before. Java and .NET both used to have it. Both dropped it because it turns out that properly sandboxing stuff is hard.
xaxaxa123 1y ago
js is a fucking disaster
codedokode 1y ago
I am surprised that anyone in this year runs scripts from random people from Github without sandboxing. As a wise proverb says, a peasant won't cross himself until the thunder bursts out. Spend a couple hours setting up a sandbox and be safer.
deleted 1y ago
[deleted]
lordofgibbons 1y ago
Is the solution to this problem Golang style package management where you specify the git repo?
- vasco 1y ago
  Any string can be typosquatted unfortunately.
  - Orygin 1y ago
    Even worse, LLM hallucinations can be squatted to the same effect.
- gus_ 1y ago
  probably no: https://github.com/evilsocket/opensnitch/discussions/1290 https://github.com/evilsocket/opensnitch/discussions/1290 that malware campaign is still active.
2d8a875f-39a2-4 1y ago
The npm ecosystem's approach to supply chain security is criminally negligent. For the critical infrastructure that underpins the largest attack surface on the Internet you would think that this stuff would be priority zero. But nope, it's failing in ways that are predictable and were indeed predicted years ago. I'm not closely involved enough with the npm community to suggest what the next steps should be but something has to change, and soon.
jwr 1y ago
I always wondered why people found it acceptable to just run npm on their systems for anything they do, and have it download anything on any build. Coming from "make" with repeatable and predictable builds, I was appalled that you run this thing and you have no idea what it will download and what it will produce. Could be something different the next time you run it! Who knows! I also found it bizarre that even for things that just generate CSS, you are expected to integrate it into your npm thing. I mean, generating CSS from a configuration is a function. It's a make recipe. Why does it need to be an npm library dependency with all the associated mess? I managed to work around it for a number of packages by freezing entire npm setups inside docker containers, which gave me reproducible builds — but it's a losing battle.
- gear54rus 1y ago
  > entire npm setups inside docker containers Did you then spend a month or two inspecting that setup? Did you do that after every dependency upgrade? Also both NPM and PNPM already freeze dependencies for you by default without any arcane docker setups.
  - jwr 1y ago
    > Did you then spend a month or two inspecting that setup? Did you do that after every dependency upgrade? TBH, I never updated some of the setups. What's the point? Their job was to generate a CSS. Why would I want to upgrade dependencies or inspect that setup? > arcane docker setups I take issue with "arcane" — I have much more "arcane" setups than these :-)
- Havoc 1y ago
  The entire Front end dev seems like trust me bro Wild West to me. All feels like endless layers of duct tape. Which I guess in a way it is given the evolution of browsers
  - graemep 1y ago
    it seems a lot worse with NPM for some reason, but the underlying weaknesses apply to language package managers in general too.
amiga386 1y ago
"No Way To Prevent This" Says Only Package Manager Where This Regularly Happens
heelix 1y ago
Is there a way to detect/filter dependencies that use HTTP URLs as dependency specifiers as part of an NPM install? Since you can send specific requesters different payloads, I can see how this would bypass most of the normal scanning tools.
contrahax 1y ago
This ultimately needs to get addressed at the OS level. Why is a random JS file on disk allowed to read my browser cookies without my awareness? Why is a native extension downloaded from S3? This goes across all package managers (npm, pypi, cargo). I think security controls on macOS have been trending in the right direction to tackle these types of things comprehensively with secure domains, sandboxing, etc. but there is always a war of how much friction is too much when it comes to security. We saw the same thing with 2SV where people were vehemently against it, and now many are clamoring that it should be the only way to be able to do things like publish packages (I agree! I have no issue jumping through some extra hoops when I publish something a million people will install). This might be a hot take but I think a lot of loud mouths with their personal preferences have been holding security in this space back for a while, and recently people seem to be getting tired of it and pushing through. The engineering leadership that won't just make these types of high impact security decisions because it might irritate a handful of highly opinionated workflows is unfortunate!
- alt227 1y ago
  Whats to stop OS builds from being infiltrated either upstream or in build tooling?
  - contrahax 1y ago
    Really good internal security practices by the people who make the OS :) I don't think an attacker would be able to pull off disabling features like secure domains, secure enclave, etc. in macOS without anyone noticing seeing as it takes months of approvals, testing, etc. for a single build to even hit the beta channel.
TZubiri 1y ago
"No way to prevent this" - Only ecosystem where this consistently happens.
mayhemducks 1y ago
Cybersecurity professionals are police officers and detectives first, technologists second. They are supposed to catch criminals who abuse technology. I find it distasteful to blame a tool and an entire community for things that criminals are responsible for. There is nothing about Go, or Cargo, or Nuget, or any of the other systems that prevents criminals from committing crimes. Some cleverness can slow them down, or block certain roads to exploiting these systems, but managing risk in a supply chain is essential no matter which technology ecosystem is used. Let's stop name-calling and throwing shade at specific tools and communities and get better at educating new-comers to the trade, and shaming and ostracizing the cyber-criminals who are causing the problems.
- ozim 1y ago
  Just this year Microsoft removed 300 NuGet packages by mistake as they were trying to automate defenses. They got pretty bad press after that so you will get bad comments one way or the other. NPM ecosystem is very open it is not a bug it is a feature. There are of course issues from being open but NPM already has a lot of security features in place.
belikebakar 1y ago
These malicious npm packages often “phone home” during install or runtime, opening C2 channels, exfiltrating env vars, or beaconing quietly in the background. Static checks and SBOMs rarely catch that kind of dynamic behavior. With AI-generated or auto-installing code pipelines, that risk gets amplified since installs happen more often and less predictably. Watching what packages do at runtime feels like the next frontier here.

364 points by jnord 1y ago

Happy I keep a mirror of my deps, that I have to "manually" update. But also, the download numbers are not really accurate for actual install count - for example each test run could increment.

robpco 1y ago

Alternate article with more detailed description of exploit: https://www.bleepingcomputer.com/news/security/phantomraven-attack-floods-npm-with-credential-stealing-packages/ https://www.bleepingcomputer.com/news/security/phantomraven-...

crtasm 1y ago

>When you run npm install, npm doesn't just download packages. It executes code. Specifically, it runs lifecycle scripts defined in package.json - preinstall, install, and postinstall hooks. What's the legitimate use case for a package install being allowed to run arbitrary commands on your computer? Quote is from the researchers report https://www.koi.ai/blog/phantomraven-npm-malware-hidden-in-invisible-dependencies https://www.koi.ai/blog/phantomraven-npm-malware-hidden-in-i... edit: I was thinking of this other case that spawned terminals, but the question stands: https://socket.dev/blog/10-npm-typosquatted-packages-deploy-credential-harvester https://socket.dev/blog/10-npm-typosquatted-packages-deploy-...

j1elo 1y ago
Easy example that I know of: the Mediasoup project is a library written in C++ for streaming video over the internet. It is published as a Node package and offers a JS API. Upon installing, it would just download the appropriate C++ sources and compile them on the spot. The project maintainers wanted to write code, not manage precompiled builds, so that was the most logical way of installing it. Note that a while ago they ended up adding downloadable builds for the most common platforms, but for anything else the expectation still was (and is, I guess) to build sources at install time.
- exe34 1y ago
  how hard would it be to say "upon first install, run do_sketchy_shit.sh to install requirements"?
  - lelandbatey 1y ago
    People want package managers to do that for them. As much as I think it's often a mistake (if your stuff requires more than expanding archives different folders to install, then somewhere in the stack something has gone quite wrong), I will concede that because we live in an imperfect world, other folks will want the possibility to "just run the thing automatically to get it done." I hope we can get to a world where such hooks are no longer required one day.
    - exe34 1y ago
      yes that's why npm is for them. I'd rather download the libraries that I need one by one.
  - SoftTalker 1y ago
    But most users would do that without inspecting it at all, and a fair number would prefix it with “sudo” out of habit.
    - cindyllm 1y ago
      [dead]
    - nkrisc 1y ago
      But that’s at least a conscious and explicit action the user chooses to make and is explicitly aware of making.
    - hombre_fatal 1y ago
      That's fine, and it's still better than doing it on install.
    - 1y ago
squidsoup 1y ago
pnpm v10 disables all lifecycle scripts by default and requires the user to whitelist packages. https://github.com/orgs/pnpm/discussions/8945 https://github.com/orgs/pnpm/discussions/8945
- chrisweekly 1y ago
  One of the many reasons there is no good reason to use npm; pnpm is better in every way.
- sroussey 1y ago
  It’s just security theater in the end. You can just as easily put all that stuff in the package files since a package is installed to run code. You have that code then do all the sketchy stuff. What’s needed is an entitlements system so a package you install doesn’t do runtime stuff like install crypto mining software. Even then…
  - theodorejb 1y ago
    I would expect to be able to download a package and then inspect the code before I decide to import/run any of the package files. But npm by default will run arbitrary code in the package before developers have a chance to inspect it, which can be very surprising and dangerous.
    - sroussey 1y ago
      npm used to do that. bun never did. No idea about the past for pnpm or yarn.
  - Mogzol 1y ago
    A package, especially a javascript package, is not necessarily installed to run code, at least not on the machine installing the package. Many packages will only be run in the browser, which is already a fairly safe environment compared to running directly on the machine like lifecycle scripts would. So preventing lifecycle scripts certainly limits the number of packages that could be exploited to get access to the installing machine. It's common for javascript apps to have hundreds of dependencies, but only a handful of them will ever actually run as code on the machine that installed them.
vorticalbox 1y ago
One use case is downloading of binaries. For example mongo-memory-server [0] will download the mongoDB binary after you have installed it. [0] https://www.npmjs.com/package/mongodb-memory-server https://www.npmjs.com/package/mongodb-memory-server
- 8note 1y ago
  why would i want that though, compared to downloading that binary in the install download? the npm version is decoupled from the binary version, when i want them locked together
  - jonhohle 1y ago
    I think it falls into a few buckets: A) maintainers don’t know any better and connect things with string and gum until it most works and ship it B) people who are smart, but naive and think it will be different this time C) package manager creators who think they’re creating something that hasn’t been done before, don’t look at prior art or failures, and fall into all of the same holes literally every other package manager has fallen into and will continue to fall into because no one in this industry learns anything.
- madeofpalk 1y ago
  And now optional dependencies negate the need for this. Your package manager can just download platform-specific binaries automatically https://docs.npmjs.com/cli/v7/configuring-npm/package-json#optionaldependencies https://docs.npmjs.com/cli/v7/configuring-npm/package-json#o...
DangitBobby 1y ago
I seem to recall Husky at one point using lifecycle hooks to install the git hooks configured in your repository when running NPM install.
- mock-possum 1y ago
  Playwright does it too. Or at least, I’ve worked a place that used npm install hooks to setup husky and install playwright browser binaries
interstice 1y ago
Notable times this has bitten me include compiling image compression tools for gulp and older versions of sass, oh and a memorable one with openssl. Downloading a npm package should ideally not also require messing around with c compilation tools.
deleted 1y ago
[deleted]
zahlman 1y ago
> doesn't just download packages. It executes code. Specifically, it It pains me to remember that the reason LLMs write like this is because many humans did in the training data.
- jsrozner 1y ago
  That whole koi blog post is sloppy AI garbage, even if it's accurate. So obnoxious.
- marcus_holmes 1y ago
  Is the objection the small sentence that could have been a clause?
  - zahlman 1y ago
    The objection is to the redundant, flowery prose overall, and the overall inaccuracy. (Of course the installer "doesn't just download packages"; installation at minimum would also involve unpacking the archive and putting the files in the right place....) In about as much text, we could explain far better why and how NPM's behaviour is risky: > When you install a package using `npm install`, NPM may also run arbitrary code from the package, from multiple hook scripts specified in `package.json`, before you can even audit the code.
ChrisMarshallNY 1y ago
Swift Package Manager[0] executes a Swift script. The Package.swift file[1] (the manifest) is actually an executed source file. I assume that it's heavily sandboxed, though, so it may be difficult to leverage. [0] https://docs.swift.org/swiftpm/documentation/packagemanagerdocs/ https://docs.swift.org/swiftpm/documentation/packagemanagerd... [1] https://developer.apple.com/documentation/packagedescription https://developer.apple.com/documentation/packagedescription
bandrami 1y ago
OK but have you seen how many projects' official installation instructions are some form of curl | bash?
- codedokode 1y ago
  In most cases to use a library you just need to download files and place them into a directory.
- dns_snek 1y ago
  Both post-install scripts and curl|bash scripts are just scapegoats of supply chain security with similar faulty reasoning.
Timshel 1y ago
There is the "--ignore-scripts" option and had no issue using it for now.
maxloh 1y ago
Many front end tools are written in a faster language. For example, the next version of TypeScript compiler, SASS, SWC (minifier), esbuild (bundler used by Vite), Biome (formatter and linter), Oxc (linter, formatter and minifier), Turbopack (bundler), dprint (formatter), etc. They use proinstall script to fetch pre-built binaries, or compile from source if your environment isn't directly supported.
styanax 1y ago
> What's the legitimate use case for a package install being allowed to run arbitrary commands on your computer? The paradigm itself has been in package managers since DEB and RPM were invented (maybe even Solaris packages before that? it's been a minute since I've Sun'd); it's not the same as NPM, a more direct comparison is the Arch Linux AUR - and the AUR has been attacked to try and inject malware all year (2025) just like NPM. As of the 26th (5 days ago) uploads are disabled as they get DDOSed again. https://status.archlinux.org/ https://status.archlinux.org/ (spirit: it's the design being attacked, pain shared between AUR and NPM as completely disparate projects). More directly to an example: the Linux kernel package. Every Linux distribution I'm aware of runs a kernel package post-install script which runs arbitrary (sic) commands on your system. This is, of course, to rebuild any DKMS modules, build a new initrd / initramfs, update GRUB bootloader entries, etc. These actions are unique outputs to the destination system and can't be packaged. I have no data in front of me, but I'd speculate 70% (?) of DEB/RPM/PKG packages include pre / post install/uninstall scriptlets, it's very common in the space and you see it everywhere in use.
- cozzyd 1y ago
  Right every library will want to run ldconfig for example.
- a96 1y ago
  There's a huge difference between running a script inside an audited package from a curated source and the curl | sh installers.
matheusmoreira 1y ago
There's nothing inherently wrong with that. The problem is npm allows any random person to upload packages. It's completely untrusted. Contrast that with Linux distributions which have actual maintainers who take responsibility for their packages. They don't generally allow malware to make it into the official software repositories. In many cases they went as far as meeting each other in person just to set up a decentralized root of trust with PGP. It's so much better and more trustworthy. The truth is npm, pip, rubygems, cargo and all the other programming language package managers are just fancier versions of the silly installation instructions you often find in README files that tell people to curl some script and pipe it into bash.
- graemep 1y ago
  Even when random people are allowed to contribute (AUR, PPAs) there seems to be more scrutiny and fewer incidents. Possibly because they are secondary to the main repos and possibly because the people who use them are made aware of the risks. NPM etc. are a bit like Arch would be if everything was in AUR.
  - cozzyd 1y ago
    With PPAs or COPR (or third party repositories, e.g. slack) you have to explicitly enable each repository too. Even if a repository is enabled by package you are prompted the first time a new repository is used (actually I don't know if that's true when gpgcheck is disabled? If not this would be an easy fix in apt/dnf)

ghusto 1y ago

When people ask me what's so wrong with lowering the bar of entry for engineering, I point to things like this.

The_President 1y ago
Engineering used as a title should be regulated in the software industry; it was always a title reserved for a role that requires accountability. In software, it became used so casually without legal restriction that full stack developers started using it.
- michaelcampbell 1y ago
  This is most often pushed on the person by their company. I don't have an Eng degree nor certification, but my company forces my title to be "... Engineer", which I dislike, but I've been told this is just how it is.

cxr 1y ago

Imagine if we had a system where you could just deposit the source code for a program you work on into a "depository". You could set it up so your team could "admit" the changes that have your approval, but it doesn't allow third parties to modify what's in your depository (even if it's a library that you're using that they wrote). When you build/deploy your program, you only compile/run third-party versions that have been admitted to the depository, and you never just eagerly fetch other versions that purport to be updates right before build time. If there is an update, you can download a copy and admit it to your repo at the normal time that you verify that your program actually needs the update. Even if it sounds far-fetched, I imagine we could get by with a system like this.

edoceo 1y ago
That is exactly what I do.
anthk 1y ago
You are describing BSD ports from the 90's. FreeBSD ports date back to 1993.
- ok123456 1y ago
  Also, Gentoo dating back to 2003.
- SoftTalker 1y ago
  And today.
chrisweekly 1y ago
You're describing a custom registry. These exist IRL (eg jFrog Artifactory). Useful for managing allow-listed packages which have met whatever criteria you might have (eg CVE-free based on your security tool of choice). Use of a custom registry, and a sane package manager (pnpm, not npm), and its lockfile, will significantly enhance your supply-chain security.
- 1y ago

650REDHAIR 1y ago

As a hobbyist how do I stay protected and in the loop for breaches like this? I often follow guides that are popular and written by well-respected authors and I might be too flippant with installing dependencies trying to solve a pain point that has derailed my original project. Somewhat related, I also have a small homelab running local services and every now and then I try a new technology. occasionally I’ll build a little thing that is neat and could be useful to someone else, but then I worry that I’m just a target for some bot to infiltrate because I’m not sophisticated enough to stop it. Where do I start?

ajross 1y ago
> As a hobbyist how do I stay protected and in the loop for breaches like this? For the case of general software, "Don't use node" would be my advice, and by extension any packaging backend without external audit and validation. PyPI has its oopses too, Cargo is theoretically just as bad but in practice has been safe. The gold standard is Use The Software Debian Ships (Fedora is great too, arch is a bit down the ladder but not nearly as bad as the user-submitted madness outside Linux). But it seems like your question is about front end web development, and that's not my world and I have no advice beyond sympathy. > occasionally I’ll build a little thing that is neat and could be useful to someone else, but then I worry that I’m just a target for some bot Pretty much that's the problem exactly. Distributing software is hard. It's a lot of work at a bunch of different levels of the process, and someone needs to commit to doing it. If you aren't willing to commit your time and resources, don't distribute it in a consumable way (obviously you can distribute what you built with it, and if it's appropriately licensed maybe someone else will come along and productize it). NPM thought they could hack that overhead and do better, but it turns out to have been a moved-too-fast-and-broke-things situation in hindsight.
- squidsoup 1y ago
  Having spent a year trying to develop against dependencies only provided by a debian release, it is really painful in practice. At some point you're going to need something that is not packaged, or newer than the packaged version in your release.

throwaway81523 1y ago

"It's always NPM."

LtWorf 1y ago
Eh sometimes it's pypi

gbransgrove 1y ago

Because these are fetching dependencies in the lifecycle hooks, even if they are legitimate at the moment there is no guarantee that it will stay that way. The owner of those dependencies could get compromised, or themselves be malicious, or be the package owner waiting to flip the switch to make existing versions become malicious. It's hard to see how the lifecycle hooks on install can stay in their current form.

severino 1y ago

I wonder what could one do if he wants to use NPM for programming with a very popular framework (like Angular or Vue) and stay safe. Is just picking a not very recent version of the top level framework (Angular, etc.) enough? Is it possible to somehow isolate NPM so the code it runs, like those postinstall hooks, doesn't mess with your system, while at the same time allowing you to use it normally?

theodorejb 1y ago
One option to make it a little safer is to add ignore-scripts=true to a .npmrc file in your project root. Lifestyle scripts then won't run automatically. It's not as nice as Pnpm or Bun, though, since this also prevents your own postinstall scripts from running (not just those of dependencies), and there's no way to whitelist trusted packages.

worik 1y ago

This has been going on for years now. I have used Node, I would not go near the NPM auto install Spyware service. How is it possible that people keep this service going, when it has been compromised so regularly? How's it possible that people keep using it?

ashishb 1y ago

Here's my `npm` command these days. It reduces the attack surface drastically. alias npm='docker run --rm -it -v ${PWD}:${PWD} --net=host --workdir=${PWD} node:25-bookworm-slim npm' - No access to my env vars - No access to anything outside my current directory (usually a JS project). - No access to my .bashrc or other files. Ref: https://ashishb.net/programming/run-tools-inside-docker/ https://ashishb.net/programming/run-tools-inside-docker/

sthuck 1y ago
That definitely helps and worth doing. On Mac though I guess you need to move the entire development to containers due to native dependencies.
- chuckadams 1y ago
  My primary dev environment is containers, but you can do a hell of a lot with nix on a mac.
genpfault 1y ago
> triple-backtick code blocks If only :(
phiresky 1y ago
That seems a bit excessive to sandbox a command that really just downloads arbitrary code you are going to execute immediately afterwards anyways? Also I can recommend pnpm, it has stopped executing lifecycle scripts by default so you can whitelist which ones to run.
- simpaticoder 1y ago
  pnpm has lots of other good attributes: it is much faster, and also keeps a central store of your dependencies, reducing disk usage and download time, similar to what java/mvn does.
- ashishb 1y ago
  > That seems a bit excessive to sandbox a command that really just downloads arbitrary code you are going to execute immediately afterwards anyways? I won't execute that code directly on my machine. I will always execute it inside the Docker container. Why do you want to run commands like `vite` or `eslint` directly on your machine? Why do they need access to anything outside the current directory?

noosphr 1y ago

A day ago I got down voted to hell for saying that the JavaScript ecosystem has rotted the minds of developers and any tools that emulate npm should be shunned as much as possible - they are not solutions, they are problems. I don't usually get to say 'I told you so' within 24 hours of a warning, but JS is special like that.

cogman10 1y ago
There's nothing really specially about the JS ecosystem that creates this problem. Plenty of others could fall in the same way, including C++ (see xz). The problem is we've been coasting on an era where blind trust was good enough an programming was niche enough.
- procaryote 1y ago
  There's a culture of micro-dependencies. In c++, most people wouldn't publish a library that does the equivalent of (1 == value % 2). Even if they did, almost no one would use it. For npm, that library will not only exist, it will have several dependencies and millions of downloads
  - cogman10 1y ago
    That increases the surface area, which is certainly bad. But that doesn't really mean the risk isn't similarly there for C++. A few years back, the university of Minnesota was banned from the kernel (are they still banned?) for testing this exact theory. They tried to figure out how hard it would be to inject an intentional CVE into the kernel. [1] https://www.bleepingcomputer.com/news/security/linux-bans-university-of-minnesota-for-committing-malicious-code/ https://www.bleepingcomputer.com/news/security/linux-bans-un...
    - procaryote 1y ago
      Of course, it's a risk with any dependency, but for a small number of dependencies you're more likely to be able to do some level of vetting. The university of Minnesota would have had a much easier time not getting caught if there had been a tree of thousands of independently maintained dependencies

jtokoph 1y ago

Keep in mind that the vast majority of the 86,000 downloads are probably automated downloads by tools looking for malicious code, or other malicious tools pulling every new package version looking for leaked credentials. When I iterate with new versions of a package that I’ve never promoted anywhere, each version gets hundreds of downloads in the first day or two of being published. 86,000 people did not get pwnd, possibly even zero.

userbinator 1y ago
Or it's some poor idiot's CI repeatedly downloading them, and for a zombie project that no one will ever use.
marcus_holmes 1y ago
As TFA says, they're targeting package names that are somewhere in LLM training data but don't actually exist, so are being hallucinated by LLMs. And there's now a large number of folks with zero clue busy vibe-coding their killer app with no idea that bad things can happen. I would not be surprised to find that 80%+ of those 86,000 people got pwned.
hinkley 1y ago
When I published a library it got about 300 downloads a week for the first few and then dropped down to about 100. That would be a lot of weeks. > Many of the dependencies used names that are known to be “hallucinated” by AI chatbots. There’s more here than that.

Uptrenda 1y ago

I dub thee "node payload manager."

akagusu 1y ago

Unpopular opinion: why not reduce the dependency on 3rd party packages? Why not reduce the number of dependencies so you can know what code you are using?

BobbyTables2 1y ago
I’ve wondered this for so long, I questioned my own sanity.
gavmor 1y ago
Because then I would have to test, write, and maintain that code—and it becomes susceptible to leaky abstractions!
alt227 1y ago
You have a choice, reinvent the wheel or use someone elses wheel.

deleted 1y ago

[deleted]

ab_testing 1y ago

Given the recent npm attacks, is it even safe to develop using npm. Whenever I start a react project, it downloads hundreds of additional packages which I have mo idea about what they do. As a developer who has learnt programming as a hobby, is it better to stick to some other safe ways to develop front end like thyme leaf or plain js or something else. When I build backend in flask or Django, I specifically type the python packages that I need. But front end development seems like a Pandora box of vulnerabilities

fragmede 1y ago
Just a heads up that Pypi isn't immune from the same attack, with "Pypi supply chain attack" into Google revealing a (much smaller) number of packages that turned out to be malware. Some were not misspellings either, with one being a legitimate package that got hacked via GitHub Actions and a malicious payload added to the otherwise legitimate package.
- tjpnz 1y ago
  No language ecosystem is but NPM/Node still encourages this idea (borrowed elsewhere and interpreted poorly) that everything must be its own tiny package and that it's acceptable to author libraries consisting of thousands of transitive dependencies from potentially dubious sources. Just this week I saw one (unmaintained dependency of a popular package) which consisted of a list of a dozen SQL operators. Anywhere else you would just write the damn code, maybe add a comment that these are the SQL-92 operators and be done with it literally forever. But in Node land that would be viewed as an antipattern which only another package can fix. It's a security and maintenance nightmare that can only be explained by laziness and outright stupidity.
  - silverwind 1y ago
    It's a misconception that NPM or Node encourage this, because they don't. There are a few package authors that are doing it that way (some even paid by download count), but that's their opinion. Recently there is a trend towards minimal-dependency packages and I would certainly recommend auditing every package for its dependencies before using it.

creativeSlumber 1y ago

> Many of the dependencies used names that are known to be “hallucinated” by AI chatbots. Developers frequently query these bots for the names of dependencies they need. LLM developers and researchers have yet to understand the precise cause of hallucinations or how to build models that don’t make mistakes. After discovering hallucinated dependency names, PhantomRaven uses them in the malicious packages downloaded from their site. I found it very interesting that they used common AI hallucinated package names.

bytefish 1y ago

I feel super uneasy developing Software with Angular, Vue or any framework using npm. The amount of dependencies these frameworks take is absolutely staggering. And just by looking at the dependency tree and thousands of packages in my node_modules folder, it is a disaster waiting to happen. You are basically one phishing attack on a poor open source developer away from getting compromised. To me the entire JavaScript ecosystem is broken. And a typo in your “npm -i” is sufficient to open up yourself for a supply-chain attack. Could the same happen with NuGet or Maven? Sure! But at least in these languages and environments I have a huge Standard Library and very few dependencies to take. It makes me feel much more in control.

kigiri 1y ago
Deno solves this, it's not a JavaScript Issue, it's a Node.JS / NPM issue.
- Sander_Marechal 1y ago
  How does Deno solve this? Genuine question by the way. I'm not trying to be snarky.
  - bytefish 1y ago
    It provides a runtime, that sandboxes your application and requires you to give explicit permissions for file system operations and network requests. This limits the attack surface, when it comes to installing malicious dependencies, that npm happily installs for you. So yes, I was wrong and my previous comment a hyperbole. A big problem is npm, and not JavaScript. My point about the staggering amount of dependencies still holds though.
    - int_19h 1y ago
      Of course, this only works so long as the sandbox is secure. There have been attempts to do this kind of sandboxing before. Java and .NET both used to have it. Both dropped it because it turns out that properly sandboxing stuff is hard.

xaxaxa123 1y ago

js is a fucking disaster

codedokode 1y ago

I am surprised that anyone in this year runs scripts from random people from Github without sandboxing. As a wise proverb says, a peasant won't cross himself until the thunder bursts out. Spend a couple hours setting up a sandbox and be safer.

deleted 1y ago

[deleted]

lordofgibbons 1y ago

Is the solution to this problem Golang style package management where you specify the git repo?

vasco 1y ago
Any string can be typosquatted unfortunately.
- Orygin 1y ago
  Even worse, LLM hallucinations can be squatted to the same effect.
gus_ 1y ago
probably no: https://github.com/evilsocket/opensnitch/discussions/1290 https://github.com/evilsocket/opensnitch/discussions/1290 that malware campaign is still active.

2d8a875f-39a2-4 1y ago

The npm ecosystem's approach to supply chain security is criminally negligent. For the critical infrastructure that underpins the largest attack surface on the Internet you would think that this stuff would be priority zero. But nope, it's failing in ways that are predictable and were indeed predicted years ago. I'm not closely involved enough with the npm community to suggest what the next steps should be but something has to change, and soon.

jwr 1y ago

I always wondered why people found it acceptable to just run npm on their systems for anything they do, and have it download anything on any build. Coming from "make" with repeatable and predictable builds, I was appalled that you run this thing and you have no idea what it will download and what it will produce. Could be something different the next time you run it! Who knows! I also found it bizarre that even for things that just generate CSS, you are expected to integrate it into your npm thing. I mean, generating CSS from a configuration is a function. It's a make recipe. Why does it need to be an npm library dependency with all the associated mess? I managed to work around it for a number of packages by freezing entire npm setups inside docker containers, which gave me reproducible builds — but it's a losing battle.

gear54rus 1y ago
> entire npm setups inside docker containers Did you then spend a month or two inspecting that setup? Did you do that after every dependency upgrade? Also both NPM and PNPM already freeze dependencies for you by default without any arcane docker setups.
- jwr 1y ago
  > Did you then spend a month or two inspecting that setup? Did you do that after every dependency upgrade? TBH, I never updated some of the setups. What's the point? Their job was to generate a CSS. Why would I want to upgrade dependencies or inspect that setup? > arcane docker setups I take issue with "arcane" — I have much more "arcane" setups than these :-)
Havoc 1y ago
The entire Front end dev seems like trust me bro Wild West to me. All feels like endless layers of duct tape. Which I guess in a way it is given the evolution of browsers
- graemep 1y ago
  it seems a lot worse with NPM for some reason, but the underlying weaknesses apply to language package managers in general too.

amiga386 1y ago

"No Way To Prevent This" Says Only Package Manager Where This Regularly Happens

heelix 1y ago

Is there a way to detect/filter dependencies that use HTTP URLs as dependency specifiers as part of an NPM install? Since you can send specific requesters different payloads, I can see how this would bypass most of the normal scanning tools.

contrahax 1y ago

This ultimately needs to get addressed at the OS level. Why is a random JS file on disk allowed to read my browser cookies without my awareness? Why is a native extension downloaded from S3? This goes across all package managers (npm, pypi, cargo). I think security controls on macOS have been trending in the right direction to tackle these types of things comprehensively with secure domains, sandboxing, etc. but there is always a war of how much friction is too much when it comes to security. We saw the same thing with 2SV where people were vehemently against it, and now many are clamoring that it should be the only way to be able to do things like publish packages (I agree! I have no issue jumping through some extra hoops when I publish something a million people will install). This might be a hot take but I think a lot of loud mouths with their personal preferences have been holding security in this space back for a while, and recently people seem to be getting tired of it and pushing through. The engineering leadership that won't just make these types of high impact security decisions because it might irritate a handful of highly opinionated workflows is unfortunate!

alt227 1y ago
Whats to stop OS builds from being infiltrated either upstream or in build tooling?
- contrahax 1y ago
  Really good internal security practices by the people who make the OS :) I don't think an attacker would be able to pull off disabling features like secure domains, secure enclave, etc. in macOS without anyone noticing seeing as it takes months of approvals, testing, etc. for a single build to even hit the beta channel.

TZubiri 1y ago

"No way to prevent this" - Only ecosystem where this consistently happens.

mayhemducks 1y ago

Cybersecurity professionals are police officers and detectives first, technologists second. They are supposed to catch criminals who abuse technology. I find it distasteful to blame a tool and an entire community for things that criminals are responsible for. There is nothing about Go, or Cargo, or Nuget, or any of the other systems that prevents criminals from committing crimes. Some cleverness can slow them down, or block certain roads to exploiting these systems, but managing risk in a supply chain is essential no matter which technology ecosystem is used. Let's stop name-calling and throwing shade at specific tools and communities and get better at educating new-comers to the trade, and shaming and ostracizing the cyber-criminals who are causing the problems.

ozim 1y ago
Just this year Microsoft removed 300 NuGet packages by mistake as they were trying to automate defenses. They got pretty bad press after that so you will get bad comments one way or the other. NPM ecosystem is very open it is not a bug it is a feature. There are of course issues from being open but NPM already has a lot of security features in place.

belikebakar 1y ago

These malicious npm packages often “phone home” during install or runtime, opening C2 channels, exfiltrating env vars, or beaconing quietly in the background. Static checks and SBOMs rarely catch that kind of dynamic behavior. With AI-generated or auto-installing code pipelines, that risk gets amplified since installs happen more often and less predictably. Watching what packages do at runtime feels like the next frontier here.