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

381–390 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#381

Post by Pxtl »

Uvix wrote: post #363
Pxtl wrote: post #360

Earlier quoted context omitted.

It never made sense the other way. If I reference a package, logically I'm also referencing its dependencies at the version that the package uses. Forcing the user to also reference dependencies of dependencies of dependencies means the package reference lists aren't DRY.

But just the dependency list isn't sufficient to pick a specific version, thanks to dependency ranges. If Package A depends on Package B >= 1.0, and Package B has v1.0 and v1.1 available, it will use v1.0. But if Package B suddenly unlists v1.0, then future restores will change to v1.1.

Ah, I see the worry. A supply-chain attacker can use de-listing to force an upgrade to the malicious version if clients have dependency ranges that reach into the future.

I didn't know about that one.

In general, any dependency system that allows "you can silently upgrade to versions of the package that did not exist at the time the packagereference list was created" seems to be a vulnerability.

It's frustrating since this vuln seems trivially simple to fix, at a glance... although it would require an API change in PackageReference. Mandatory lockfiles by default, or getting rid of the floating versions misfeature. BindingRedirects let you override declared dependency versions anyways, they're not a blood pact.

Re: Malicious npm packages detected across Red Hat Cloud Services

#382

Post by throwawayffffas »

0xbadcafebee wrote: post #229
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...

The package event-stream was compromised and went unnoticed for 60 days: https://medium.com/intrinsic-blog/compromised-npm-package-ev... The package axios was compromised, and hijacked the author's credentials, so every attempt at a fix was unfixed. https://www.trendmicro.com/en_us/research/26/c/axios-npm-pac... The xz utility was backdoored for 2 months: https://gigazine.net/gsc_news/en/20240403-timeline-of-xz-ope..…

Ok so no external dependencies, or pull versions from 2021 and apply security patches?

Re: Malicious npm packages detected across Red Hat Cloud Services

#383

Post by AgentME »

ajross wrote: post #357
mnahkies wrote: post #352

In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair. There's plenty of comments mentioning delay lines, and the other good stuff pnpm (and others) have implemented in response to protect package consumers. That bit that's getting less conversation is the tools on the package maintai…

IMHO those are both lipstick on a pig solutions. Ultimately all this stuff is just a variation of "make releases harder to publish", which isn't going to do anything but train people to evade them. Notably, neither would have prevented the xz-utils backdoor from reaching package distribution, which remains the gold standard for sophisticated upstream compromise. The bug here isn't that we need to better authenticate…

But there is a second level of people reviewing packages on npm. They're the ones that report issues like the github issue this HN thread is linked to, and they very frequently get malicious npm packages taken down within a day of publishing. The big issue is just that not everyone is using a cooldown to avoid packages less than a day old and so people who install new packages at unlucky times don't get the benefit of that layer of review.

Re: Malicious npm packages detected across Red Hat Cloud Services

#384

Post by 0xbadcafebee »

throwawayffffas wrote: post #382
0xbadcafebee wrote: post #229

Earlier quoted context omitted.

The package event-stream was compromised and went unnoticed for 60 days: https://medium.com/intrinsic-blog/compromised-npm-package-ev... The package axios was compromised, and hijacked the author's credentials, so every attempt at a fix was unfixed. https://www.trendmicro.com/en_us/research/26/c/axios-npm-pac... The xz utility was backdoored for 2 months: https://gigazine.net/gsc_news/en/20240403-timeline-of-xz-ope..…

Ok so no external dependencies, or pull versions from 2021 and apply security patches?

- Best practice for both reliability and security is to not immediately upgrade to latest versions. Only immediately upgrade to security-patched versions. If your software doesn't need a new version, you can remain on the old version.

- When a feature you're developing, or a transitive dependency, requires an upgraded version, you can upgrade to the latest stable version that satisfies the dependency. But as each of those then requires an additional transitive dependency to be upgraded, you have more and more components upgraded to "latest", and the attack surface widens. So there are two alternatives:

1) (preferred) Upgrade to the latest version of the next-to-latest minor version, within the oldest major version that is supported, if that is available. This is the least number of changes that provides the needed functionality.

2) Upgrade only to the oldest version that gives you the functionality you need. If this ends up being the first version of a new major or minor version, this can cause bugs (initial releases of new major/minor always has bugs), so in that case you might as well use the latest version of that major/minor version.

This all affects security by avoiding upgrading to the latest version. It affects reliability by minimizing the amount of changes between your current version and upgraded version (changes lead to bugs).

The argument against all that, and for always upgrading to the latest versions, is intended to make software development easier. You avoid all the complexity of picking versions or reading changelogs by using software that is probably (but not always) all compatible. But it makes reliability and security worse. So you need to choose: do you want security and reliability, or an easier time writing code?

Re: Malicious npm packages detected across Red Hat Cloud Services

#385

Post by cozzyd »

SSLy wrote: post #76
dralley wrote: post #47

Earlier quoted context omitted.

How would that help? These are not general purpose, base system libraries, these are libraries specific to a product that uses them. Either you're not using them and hence they would not be installed in the first place, or you're using them because you have the product installed. Though I would expect that Insights uses RPM packages to ship components and not the public NPM packages.

it wouldn't surprise me if insights was in fact a wrapper around npm install

https://access.redhat.com/articles/7139622

Re: Malicious npm packages detected across Red Hat Cloud Services

#386

Post by mercurywells »

jmb99 wrote: post #358
Normal_gaussian wrote: post #319

Earlier quoted context omitted.

> Changing your own car's oil is actually not that hard It is. Changing oil requires a place where you have sufficient access to the vehicle to drain it; the right equipment; the right disposal solutions. Most people who have cars do not have that. And it takes significantly more time to change your own oil than to have someone else do it as part of other specialist maintenance. > Think of QR codes, people hardly use…

Changing oil requires > a place where you have sufficient access to the vehicle to drain it Probably the only valid argument for people who park on the street. > the right equipment One $5 wrench, one $10 filter wrench (optional). One set of ramps ($40), or jack stands ($30) if you already have a jack. One drain pan, $10 (or free if you're resourceful). Total cost max $65. Cheaper if you look for deals, buy used, bor…

Good job, you forgot a new crush washer and now your oil pan will leak

Re: Malicious npm packages detected across Red Hat Cloud Services

#388

Post by EGreg »

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

https://qbix.com/blog/2026/04/01/no-way-to-prevent-this-says...

Re: Malicious npm packages detected across Red Hat Cloud Services

#389

Post by olejorgenb »

lights0123 wrote: post #163
olejorgenb wrote: post #156

Earlier quoted context omitted.

Except most of the attacks so far has not landed actually source code changes to git IIRC. They have targeting the release files directly.

Software vulnerabilities are often not placed maliciously, and are present in the original source. If you don't patch them if discovered later, you'll be vulnerable to them.

Yes. Isn't that "giant PITA" is referring to here?

> your own repo reviewing and merging from upstream as needed. Would be a giant PITA though

Re: Malicious npm packages detected across Red Hat Cloud Services

#390

Post by grugdev42 »

runtime_terror wrote: post #177
bdcravens wrote: post #148

Earlier quoted context omitted.

Yes, none of npm's lifecycle hooks. You're just pulling bytes over the wire.

Except now you're making http calls to remote servers that could be compromised.

This is a solved problem.

Use HTTPS and use the integrity attribute.

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

Also, what's more likely? Someone hacking jsDelivr/cdnjs OR some random NPM packages getting hacked?

Post reply on HN