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

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.

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.

>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-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-...

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.

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

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.

Alternate article with more detailed description of exploit: https://www.bleepingcomputer.com/news/security/phantomraven-...

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?

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.

> 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.

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.

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

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.

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?

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.

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.

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?

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?

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.

I dub thee "node payload manager."

js is a fucking disaster

"It's always NPM."

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