Live data from Hacker News

Malicious npm packages detected across Red Hat Cloud Services

github.com

21–30 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#21
post #15

Earlier quoted context omitted.

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

You rely on the security companies scanning the packages.

Well, if that actually works, it should be part of the release process, before the packages get placed onto the regular channels.

Re: Malicious npm packages detected across Red Hat Cloud Services

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

I think this is a thought-terminating cliche, and false equivalences. Stating "This area where problems occur at a high rate is not a problem, as problems can happen elsewhere too" is a curt dismissal of a valid concern. It implies the course of action, rather than to address a high-problem area, is to ignore any solutions which aren't global, or equate it to lower-incidence areas.

You bring up a good point that this class of problem, or related ones can occur with other package managers. It was frustrating how long it took the Crates.io team (Rust manager) to address name squatting, in what appeared to be a "no perfect solution exists, so we won't act" line of reasoning.

Re: Malicious npm packages detected across Red Hat Cloud Services

#23
post #9
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...

And somehow poetry doesn’t in 2026.

Re: Malicious npm packages detected across Red Hat Cloud Services

#24
This repository itself had to previously update from the axios supply chain attack [0] (co-authored by Claude lol). But just by looking at the change itself, the package is unpinned and won't solve the problem if another malicious security update happens again.

So if you have an unpinned version of this package and you run 'npm install', you immediately downloaded the compromised version and that's that.

[0] https://github.com/RedHatInsights/javascript-clients/commit/...

Re: Malicious npm packages detected across Red Hat Cloud Services

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

While true, tarring Arch here is a little unfair. AUR isn't enabled by default. It can't even be used via the same package front end, and in fact the "official" usage model requires that you clone the source yourself.

Indeed, AUR is bad as a software distribution mechanism (really it's best understood as a proving ground for baby packages before they get real maintainers and distro blessing), but it's less bad than NPM which puts the malware in the trusted/default/automated path.

Re: Malicious npm packages detected across Red Hat Cloud Services

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

Re: Malicious npm packages detected across Red Hat Cloud Services

#28
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_...

The big attacks of today are spread across several package ecosystems: TrapDoor and Shai-Hulud have been hitting npm, pypi, composer, and crates with the same malware.

And all of them "thought" of security as an after-after-after-after-after-thought.

Re: Malicious npm packages detected across Red Hat Cloud Services

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

Eh, it's worse than that. The GP comment is repeating a joke derived from an Onion headline about gun control. Where the very poignant message is about political will to make change. However, the npm ecosystem is very much willing and has already made several changes. If we're going to engage in discussion instead of meme-posting, the GP should have (imo) included real commentary _in addition to_ the meme they really wanted to post. What is the policy they want? Why do they see the NPM ecosystem as still resistant to change?

Re: Malicious npm packages detected across Red Hat Cloud Services

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

There is something to be said about the need to keep all the packages as the latest and the greatest at all times. Every minor version update doesn’t need to be immediately applied. And maybe high and critical vulnerabilities don’t need to be a minor version upgrade.
Post reply on HN