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

181–190 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#181

Post by vinnymac »

tom1337 wrote: post #67
voidUpdate wrote: post #53

One thing I've never understood is why NPM allows packages to run code immediately after they are installed. What's the use case for that? A package should just be some code you can call on at runtime

Some packages need to build native dependencies. sharp for example needs to build libvips on the system [0] to work 0: https://github.com/lovell/sharp/blob/main/install/build.js

I’ve always felt this automation shouldn’t exist at all, but should rather be selectively controlled via a hook. The hooks yarn offers out of the box for example can be used to run any code you need to after install. Putting the project owner in control instead of the dependency.

Re: Malicious npm packages detected across Red Hat Cloud Services

#183

Post by CoastalCoder »

Someone1234 wrote: post #86
Kuinox wrote: post #72

Earlier quoted context omitted.

Mosts packages manager, allow that. pnpm can still be exposed, afterall the worm simply have to wait you run tests locally.

I suppose. But that's a "Perfect is the enemy of good"-like argument. Wherein: Why even reduce an easy to exploit attack surface when there could be holes elsewhere?! Because, you know, it makes things much more secure even if imperfect. Plus, to me, it is a culture issue. npm just doesn't take security seriously, so we don't see these improvements, and if there was additional test hardening later, I don't expect we'…

> Why even reduce an easy to exploit attack surface when there could be holes elsewhere?! Because, you know, it makes things much more secure even if imperfect.

I'm still trying to calibrate my take on this view.

If attacks are randomly chosen from the set of all potential vulnerabilities, without the attacker knowing which ones had been patched, then that logic clearly makes sense.

But in an adversarial situation where the attacker can guess which vulnerabilities you still have unpatched, or can try many different attack vectors, then having already patched some other vulnerabilities doesn't matter so much.

I guess reality is more complicated though.

Re: Malicious npm packages detected across Red Hat Cloud Services

#184

Post by t-sauer »

king_zee wrote: post #40

I've made it a habit now to use the --before=2026-05-30 flag when installing packages, where it'll pick the version released before the date you specify, I usually pick around 5 days ago

If you use npm 11, you can simplify your workflow by setting min-release-age to 5. https://docs.npmjs.com/cli/v11/using-npm/config#min-release-...

Re: Malicious npm packages detected across Red Hat Cloud Services

#185

Post by jruohonen »

pipo234 wrote: post #128
Bilal_io wrote: post #95

Earlier quoted context omitted.

The problem would be the dependencies of your dependencies, and keep going many levels.

But presumably, you only include dependencies that you trust and those dependencies themselves do their trusting more strictly than you. Trust is built on vetting, signatures and reputation. That is, at least what we do, in theory. In practice, we cross fingers and let the LLM pick dependencies, are satisfied if it just works and we either update our deps frequently or infrequently.

> Trust is built on vetting, signatures and reputation.

https://news.ycombinator.com/item?id=47017833

Well, now with an irony, but sadly, of course.

Re: Malicious npm packages detected across Red Hat Cloud Services

#186

Post by saturn_vk »

matheusmoreira wrote: post #10
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_...

All programming language package managers are vulnerable. They all have the exact same caveats as the Arch Linux User Repository. There are no trusted maintainers taking responsibility for things. Any random person can make an account and push packages.

IIRC, go cannot run arbitrary code at build time, so that should not make it vulnerable

Re: Malicious npm packages detected across Red Hat Cloud Services

#187

Post by genxy »

armanckeser wrote: post #120
darth_avocado wrote: post #23

Earlier quoted context omitted.

And somehow poetry doesn’t in 2026.

I don't use poetry anymore but do check the updates before claiming such things https://python-poetry.org/blog/announcing-poetry-2.4.0/

May 3rd 2026. Release too new, didn't read.

Re: Malicious npm packages detected across Red Hat Cloud Services

#188

Post by renox »

rochak wrote: post #149

If this is what will take for folks to move away from JS ecosystem, I'll take it.

Bah, I think that these kind of vulnerabilities exist in any "packaging ecosystem" where the base language offer "ambient authorities"(any library can access your filesystem) which is .. all of them! AFAIK only research languages do not provide these ambient authorities :-(

Re: Malicious npm packages detected across Red Hat Cloud Services

#189

Post by no-name-here »

iwhalen wrote: post #9
dmix wrote: post #5

Our company uses yarn 4 which has an option to prevent you from installing an npm package for the first number of days of its release. Most of these seem to be caught within that timeframe (1-3 days). https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...

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

Sadly I haven't seen that Visual Studio/Rider/dotnet/VS Code have such a feature for the C#/dotnet/nuget ecosystem.

Re: Malicious npm packages detected across Red Hat Cloud Services

#190

Post by genxy »

JoshTriplett wrote: post #20
phoronixrly wrote: post #7

Earlier quoted context omitted.

What happens when everyone adopts this policy? You just change it to two weeks?

A large array of automated and semi-automated security scanners are finding things quickly. The main benefit of waiting before updating is to give those scanners time to work.

Would be nice if cargo had a cooldown flag and could respect lockfiles by default.
Post reply on HN