NPM packages from Red Hat have been compromised

Re:NPM packages from Red Hat have been compromised by Romario77 on Monday June 01, 2026 @10:59AM (#48357699)

I think another thing that affects security is that in javascript culture people often tie to the latest version instead of concrete version.

This makes it so an update to a popular library can compromise a huge number of packages that depend on it.

In Java for example almost all packages specify a concrete version, even if someone compromises the latest the blast radius is usually pretty small.

[ Parent | on HN ]

Re:NPM packages from Red Hat have been compromised by m4rtink on Monday June 01, 2026 @12:11PM (#48358794)

Won't pinning a version lead to dependency hell, not to mention potentially using vulnerable versions if you don't a new version after it has some CVE fixes ?

[ Parent | on HN ]

Re:NPM packages from Red Hat have been compromised by Pxtl on Monday June 01, 2026 @11:07AM (#48357854)

MS Nuget is also lock-by-default. Latest-by-default should be considered harmful unless the package manager is directly vouching for the veracity and reputability of the packages.

[ Parent | on HN ]

Re:NPM packages from Red Hat have been compromised by Uvix on Monday June 01, 2026 @01:01PM (#48359508)

NuGet is lock-by-default for the parent package, but with the move from packages.config to <PackageReference> it's no longer lock-by-default for dependencies.

[ Parent | on HN ]

Re:NPM packages from Red Hat have been compromised by Pxtl on Monday June 01, 2026 @01:56PM (#48360329)

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.

[ Parent | on HN ]

Re:NPM packages from Red Hat have been compromised by Uvix on Monday June 01, 2026 @02:12PM (#48360552)

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.

[ Parent | on HN ]

Re:NPM packages from Red Hat have been compromised by Pxtl on Monday June 01, 2026 @03:04PM (#48361178)

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.

[ Parent | on HN ]

Re:NPM packages from Red Hat have been compromised by Uvix on Monday June 01, 2026 @10:38PM (#48365306)

It seems trivially simple until you have two dependencies with conflicting exact version requirements... So I don't think you can get rid of floating versions entirely. They did add NPM-style lockfiles for PackageReference, but currently not mandatory.

The version numbers for BindingRedirects are orthogonal to the package versions. You can have multiple package versions use the same AssemblyVersion so that applications don't need to create BindingRedirects. (e.g. Newtonsoft.Json - 13.0.0, and 13.0.1 in NuGet are both 13.0.0.0 for binding redirect purposes) And .NET Core/5+ don't need BindingRedirects at all!

[ Parent | on HN ]