Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malicious npm packages detected across Red Hat Cloud Services

github.com

Post reply on HN
Print view View original

101–110 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#101

Post by skydhash »

ImPostingOnHN wrote: post #74
Someone1234 wrote: post #34

Earlier quoted context omitted.

Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes. That's an INSANE default. pnpm, by contrast, allows you to essentially "opt-in" only specific packages that need this (e.g. four out of thirty, in one of our projects). Then tacks on tons of oth…

Nearly every package manager I've ever used had post-install scripts. Most run as root, since that's what usually what the package manager runs as. It's not unreasonable: you're already installing software, which presents risks. If post-install scripts were not a thing, a payload could still run because you ran the software you installed. Or because the installer added it to auto-run. Or because the installer placed…

I think it’s just a bundle of issues. Deep graph of dependencies, distribution of minimized code (java has jars, but I don’t remember scripts), and nearly impossible to audit. With most projects in other ecosytems, you only have to interact with a few developer/orgs. But with npm, you add one library and you need to essentially trust 10s of entities on the internet.

Re: Malicious npm packages detected across Red Hat Cloud Services

#102

Post by nailer »

jofzar wrote: post #3

'No Way to Prevent This,' Says Only package manager Where This Regularly Happens Edit: some people don't understand that it's a defence to https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...

I've deleted and am rewriting this, to be more explicit, because HN downmodded the first comment to hell but I know I'm right and the crowd is wrong.

So, explicitly:

- pip

- Cargo

- apt/dpkg

- dnf/yum

- Homebrew

- RubyGems

- Composer (limited)

- Maven

...all allow scripts.

We understand the reference, it's just not correct: most package managers allow scripts, npm is the most successful package manager.

npm shouldn't allow scripts, but exploits happen everywhere.

Re: Malicious npm packages detected across Red Hat Cloud Services

#104

Post by stingraycharles »

kalcode wrote: post #27
jofzar wrote: post #3

'No Way to Prevent This,' Says Only package manager Where This Regularly Happens Edit: some people don't understand that it's a defence to https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...

People make this joke often. It's package managers and how loose we are with installing them, not NPM. Cargo,PyPi,Nuget,PHP has had these recent too. It's not just only NPM. It's frequently repeated here just cause of the average bias against Node. But this problem isn't isolated to NPM.

How many package managers allow executing arbitrary code as part of the installation process by default?

Re: Malicious npm packages detected across Red Hat Cloud Services

#105

Post by Ajedi32 »

dns_snek wrote: post #64
Someone1234 wrote: post #34

Earlier quoted context omitted.

Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes. That's an INSANE default. pnpm, by contrast, allows you to essentially "opt-in" only specific packages that need this (e.g. four out of thirty, in one of our projects). Then tacks on tons of oth…

> since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes. This is semi-common and in no way unique to NPM.

And even in the ones that don't, having to wait until the project executes to begin its attack is a minor inconvenience for malware.

Re: Malicious npm packages detected across Red Hat Cloud Services

#106

Post by okanat »

Defletter wrote: post #37
kalcode wrote: post #27

Earlier quoted context omitted.

People make this joke often. It's package managers and how loose we are with installing them, not NPM. Cargo,PyPi,Nuget,PHP has had these recent too. It's not just only NPM. It's frequently repeated here just cause of the average bias against Node. But this problem isn't isolated to NPM.

The problem is compounded with NPM though thanks to lifecycle scripts: yes, any and all package managers create a risk of supply-chain attack, but NPM makes it dangerous to merely open a project up in an IDE.

It is the same for Crates.io and PyPI they also supply scripts without asking the user so opening an IDE will run them. For PyPI you need to even execute scripts to discover the dependencies!

Re: Malicious npm packages detected across Red Hat Cloud Services

#107

Post by johannes1234321 »

bob1029 wrote: post #69
Someone1234 wrote: post #34

Earlier quoted context omitted.

Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes. That's an INSANE default. pnpm, by contrast, allows you to essentially "opt-in" only specific packages that need this (e.g. four out of thirty, in one of our projects). Then tacks on tons of oth…

Furthering the idea that not all package managers are the same, there are entire cycles of the moon where I don't open nuget once. Some ecosystems simply don't need to vendor out very often, and these are the ones where you generally find the least news like this. In about 99% of cases, I have the option to pick between Microsoft, a 3rd party or myself. I'm picking that first option every time I can. If M$ can't hand…

> Furthering the idea that not all package managers are the same, there are entire cycles of the moon where I don't open nuget once. Some ecosystems simply don't need to vendor out very often, and these are the ones where you generally find the least news like this.

This however is only to some degree the package manager's fault. The JavaScript culture is strongly ordering tiny packages by individual people doing small things (left pad) rather than larger utilit libraries maintained by a larger community.

A larger community contributing to a larger library would mean that a larger community feels responsible and checks it.

That small package mentality a trace to web usage: JavaScirpt code is often sent to the client, not having a huge library but having small dedicated libraries means that it is a lot simpler for the bundler to not bundle dead code which is sent to the browser client.

With server side Node.js this lead to tons of dependencies ... which is worsened by npm allowing to have multiple versions of the same package in parallel. So if something depends on leftpad 1.0 and something else in leftpad 1.1 both are fetched and both are available.

Re: Malicious npm packages detected across Red Hat Cloud Services

#108

Post by dns_snek »

Defletter wrote: post #37
kalcode wrote: post #27

Earlier quoted context omitted.

People make this joke often. It's package managers and how loose we are with installing them, not NPM. Cargo,PyPi,Nuget,PHP has had these recent too. It's not just only NPM. It's frequently repeated here just cause of the average bias against Node. But this problem isn't isolated to NPM.

The problem is compounded with NPM though thanks to lifecycle scripts: yes, any and all package managers create a risk of supply-chain attack, but NPM makes it dangerous to merely open a project up in an IDE.

> but NPM makes it dangerous to merely open a project up in an IDE.

It does not. Opening a project in an IDE has always been dangerous because there are about a thousand language server and analysis tools that run in the background. This is why IDEs ask you whether you trust the contents of a repository.

An even if some automated background execution initiated by the IDE doesn't get you, running `npm run test` 15 seconds later will.

Re: Malicious npm packages detected across Red Hat Cloud Services

#109

Post by dist-epoch »

darth_avocado wrote: post #23
iwhalen wrote: post #9

Earlier quoted context omitted.

uv supports the same for any Python developers out there: https://docs.astral.sh/uv/concepts/resolution/#dependency-co...

And somehow poetry doesn’t in 2026.

so? nobody uses it anymore

Re: Malicious npm packages detected across Red Hat Cloud Services

#110

Post by chrisweekly »

Someone1234 wrote: post #34
jofzar wrote: post #3

'No Way to Prevent This,' Says Only package manager Where This Regularly Happens Edit: some people don't understand that it's a defence to https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...

Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes. That's an INSANE default. pnpm, by contrast, allows you to essentially "opt-in" only specific packages that need this (e.g. four out of thirty, in one of our projects). Then tacks on tons of oth…

Yes, this.

Regarding npm CLIENTS, PNPM is fundamentally different from (and superior to) npm or yarn.

Strongest possible recommendation to use pnpm.

It's also a good idea to use a private registry (eg via jfrog), acting as a proxy / pull-through cache, and point trad SAST and maybe AI scanners at it.

But dropping the npm client in favor of pnpm is a no-brainer. Speed, disk space, security, determinism, flexibility, fine-grained control over your dependency graph...

Post reply on HN