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

341–350 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#341

Post by yread »

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

Nuget/.NET ecosystem just handles it so much better. Netvips assumes libvips is available and they provide packages for common platforms. No need to waste electricity rebuilding stuff, or install native build chains, build and test deps. Similar for Skia or Sqlite or whatever.

Re: Malicious npm packages detected across Red Hat Cloud Services

#342

Post by insanitybit »

spockz wrote: post #335
insanitybit wrote: post #135

Just some suggestions: 1. Dependency cooldowns of 1-2 days seem to be extremely effective without negatively impacting your ability to patch for CVEs. 2. Anywhere you have `npm install` or `npm test` or anything where code executes , that should happen in an environment that has no privileges. In your github actions you can do this semi-straightforwardly by using two separate jobs - one to build the artifacts and tes…

Should we instead of these cooldowns just run builds in isolated contexts? I’m running a maven proxy locally. All builds happen inside containers. I only use public repos for python, npm, and go. So these builds happen also in containers but don’t need a repository proxy.

> Should we instead of these cooldowns just run builds in isolated contexts?

I'd suggest both. Cooldown for 1-2 days is very cheap and you likely won't even notice it, so it's quite harmless and from what I've seen even just 24 hours is enough to let security companies pick up malware.

But yeah, isolation is a must-have.

Re: Malicious npm packages detected across Red Hat Cloud Services

#343

Post by rixed »

tremon wrote: post #264
rixed wrote: post #204

Earlier quoted context omitted.

One hour ago, while looking casually at a package.json, I saw this and was horrified: rm -rf pkg/snippets & rmdir pkg\\snippets /s /q & wasm-pack build --target bundler && node prepare-web.js Looked like a strange mix of unix shell and msdos batch that would, on my box, try to rmdir "/s" and "/q". I asked Claude about this, and he replied something like "Yes that's a standard and clever hack to delete a directory tha…

To meekly defend the indefensible here: it's not like rmdir on Linux (I won't speak for all Unixen) can cause loss of data, since it only removes empty directories.

Yep, but that could still cause issues (those entries could be used as signals, or be mount points for currently unmounted partitions, etc). rmdir anything that start with "/" should be an absolute no-go.

To say nothing about running a sequence of shell commands without the -e option.

Re: Malicious npm packages detected across Red Hat Cloud Services

#344

Post by red-iron-pine »

Waterluvian wrote: post #62
darth_avocado wrote: post #30

Earlier quoted context omitted.

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.

I’m having a real problem at work with security theatre and the growing push to obsess over numbers of “vulnerabilities” in our projects. And then auto Dependabot PRs that encourage churn to fix issues that if an informed person actually reviews easily concludes it doesn’t affect us in the slightest.

[dead]

Re: Malicious npm packages detected across Red Hat Cloud Services

#345

Post by ZiiS »

make3 wrote: post #340
eranation wrote: post #234

Hope it's ok I hijack this thread again about setting up cooldowns... (copy pasting my last comment when tanstack was compromised): I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, (+ @redhat-cloud-services) and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cool…

theoretical question, do cooldowns still work if everyone has them?

Less well maybe but yes. Security researchers still proactively test them, and the maintainer has a much better chance of catching it themselves.

Re: Malicious npm packages detected across Red Hat Cloud Services

#346

Post by chillax »

make3 wrote: post #340
eranation wrote: post #234

Hope it's ok I hijack this thread again about setting up cooldowns... (copy pasting my last comment when tanstack was compromised): I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, (+ @redhat-cloud-services) and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cool…

theoretical question, do cooldowns still work if everyone has them?

Companies such as socket and safedep will still scan new packages and alert on malware (if they are able to detect it) so the packages are taken down before they pass your cool down

Re: Malicious npm packages detected across Red Hat Cloud Services

#347

Post by beart »

exabrial wrote: post #191

NPM broken by design. And the NIH syndrom that runs rampant in the community wont let them do anything simple.

I don't follow your second sentence. Doesn't npm have the opposite problem of 'not invented here'? By adopting many external packages rather than developing in-house, npm projects tend to have large, complex dependency trees. It has long been the complaint that packages such as https://www.npmjs.com/package/is-windows create potential vulnerabilities and maintenance headaches, when writing the same piece of code directly is so simple.

Re: Malicious npm packages detected across Red Hat Cloud Services

#348

Post by darth_avocado »

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/

Fair, I didn’t do a “as of this morning check”. Should’ve done better. It’s sad because I moved away exactly because this feature was missing and now I’m not going back.

Re: Malicious npm packages detected across Red Hat Cloud Services

#349

Post by megous »

Someone1234 wrote: post #295
jmull wrote: post #271

Earlier quoted context omitted.

> That's an INSANE default. I agree that not running arbitrary installation scripts is the right default, but it's just an incremental improvement. The practical difference between code that runs at installation and code that runs when the package is executed is, very typically, a small amount of time. IMO, the hyperbole here hurts because it distracts from more effective efforts.

> IMO, the hyperbole here hurts because it distracts from more effective efforts. For example?

Can I just run npm update diff and see all changes across all updates compared to the last reviewed code in node_modules? Why not?

Re: Malicious npm packages detected across Red Hat Cloud Services

#350

Post by rectang »

About a week ago, I uninstalled Node from my laptop, which felt great. :)

I'm trying to do all work in dev containers (or other sandboxes), limiting the blast radius if I'm unlucky enough to be hit by an exploit. The attackers may get a Claude token, but they won't easily be able to escape the container and scan my home dir.

Cooldowns and allow-listing of installer scripts are good additions to layered security, especially for CI. However, I think the fundamental thing that needs to change is the OS permissions model. The default of trusting third-party software with everything your user has access is no longer workable.

Post reply on HN