Malicious versions of Nx and some supporting plugins were published • Hacker News Board

Re: Malicious versions of Nx and some supporting plugins were published

#171

Post by fooqux » Wed, Aug 27, 2025, 3:29 PM UTC

echelon wrote: post #127

CER10TY wrote: post #36

Earlier quoted context omitted.

Personally, I'd expect Claude Code not to have such far-reaching access across my filesystem if it only asks me for permission to work and run things within a given project.

This confusion is even more call for a response from these companies. I don't understand why HN is trying to laugh at this security and simultaneously flag the call for action. This is counterproductive.

Probably because "HN" is not an entity with a single mind, but rather a group of millions each with their own backgrounds, experiences, desires, and biases?

Frankly it's amazing there's ever a consensus.

Re: Malicious versions of Nx and some supporting plugins were published

#172

Post by tln » Wed, Aug 27, 2025, 3:29 PM UTC

How can we stop having post-install scripts with such access?

Can I turn off those post install scripts globally?

Are there alternatives to npm that do a better job here?

Re: Malicious versions of Nx and some supporting plugins were published

#173

Post by jMyles » Wed, Aug 27, 2025, 3:29 PM UTC

So... who's got the hot guide on running Claude Code isolated in a project-level container of some kind? Doesn't need to be a full-blown VM, but I definitely want to be done letting it have read access to ~.

Re: Malicious versions of Nx and some supporting plugins were published

#174

Post by saberience » Wed, Aug 27, 2025, 3:29 PM UTC

OJFord wrote: post #86

saberience wrote: post #80

Earlier quoted context omitted.

So what? It doesn't run by itself, you have to choose to run it. We have tons of apps with loads of permissions. The terminal can also mess with your filesystem and run commands... sure, but it doesn't open by itself and run commands itself. You have to literally run claude code and tell it to do stuff. It's not some living, breathing demon that's going to destroy your computer while you're at work. Claude Code is th…

It doesn't have to be a deliberate 'attack', Claude can just do something absurdly inappropriate that wasn't what you intended. You're absolutely right! I should not have `rm -rf /bin`d!

I would say this is a feature, not a bug.

Terminal and Bash or any shell can do this, if the user sucks. I want Claude Code to be able to do anything and everything, that's why it's so powerful. Sure, I can also make it do bad stuff, but that's like any tool. We don't ban knives because sometimes they kill people, because they're useful.

Re: Malicious versions of Nx and some supporting plugins were published

#175

Post by zingababba » Wed, Aug 27, 2025, 3:31 PM UTC

echelon wrote: post #53

dpoloncsak wrote: post #29

Earlier quoted context omitted.

What does Google or Antropic have to do with anything here? NX was compromised. Threat actors are using this access to leverage CLI LLMs to search the computer for you. Is this any different than if they just ran a big /find? Should the AI Assistant NOT reply to the request it was given? Why shouldn't it?

> Should the AI Assistant NOT reply to the request it was given? Why shouldn't it? LLMs are not a dumb interpreter. At minimum, they are a client-server architecture that can be used as a control plane. But they are much more than that and can likely employ advanced detection and classification heuristics. The vendors have the capability of (1) stopping this in its tracks, (2) understanding the extent of the attack a…

Here's one using gpt-oss:20b - https://x.com/esetresearch/status/1960365364300087724

Re: Malicious versions of Nx and some supporting plugins were published

#176

Post by zingababba » Wed, Aug 27, 2025, 3:31 PM UTC

mathiaspoint wrote: post #13

I always assumed malware like this would bring its own model and do inference itself. When malware adopts new technology I'm always a little surprised by how "lazy"/brazen the authors are with it.

Here's one using gpt-oss:20b - https://x.com/esetresearch/status/1960365364300087724

Re: Malicious versions of Nx and some supporting plugins were published

#177

Post by zingababba » Wed, Aug 27, 2025, 3:32 PM UTC

CER10TY wrote: post #36

fooqux wrote: post #21

Earlier quoted context omitted.

> Hopefully the LLM vendors issue security statements shortly. If they don't, that'll be pretty damning. Why would it be damning? Their products are no more culpable than Git or the filesystem. It's a piece of software installed on the computer whose job is to do what it's told to do. I wouldn't expect it to know that this particular prompt is malicious.

Personally, I'd expect Claude Code not to have such far-reaching access across my filesystem if it only asks me for permission to work and run things within a given project.

Apparently they were using --dangerously-skip-permissions, --yolo, --trust-all-tools etc. The Wiz post has some more details - https://www.wiz.io/blog/s1ngularity-supply-chain-attack

Re: Malicious versions of Nx and some supporting plugins were published

#178

Post by cluckindan » Wed, Aug 27, 2025, 3:36 PM UTC

freedomben wrote: post #142

djent wrote: post #134

Earlier quoted context omitted.

malware isn't remote. therefore it isn't remote code execution

If you can execute code on some machine without having access to that machine, then it's RCE. Whether you gain RCE through an exploit in a bad network protocol or through tricking the user into running your code (i.e. this attack) is merely a delivery mechanism. It's still RCE

Not exactly. A supply chain attack can be used to deliver RCE enabling payloads such as a reverse shell, but in itself, it is not considered RCE.

RCE implies ability to remotely execute arbitrary code on an affected system at will.

Re: Malicious versions of Nx and some supporting plugins were published

#179

Post by CER10TY » Wed, Aug 27, 2025, 3:39 PM UTC

zingababba wrote: post #177

CER10TY wrote: post #36

Earlier quoted context omitted.

Personally, I'd expect Claude Code not to have such far-reaching access across my filesystem if it only asks me for permission to work and run things within a given project.

Apparently they were using --dangerously-skip-permissions, --yolo, --trust-all-tools etc. The Wiz post has some more details - https://www.wiz.io/blog/s1ngularity-supply-chain-attack

That's a good catch. I knew these flags existed, but I figured they'd require at least a human in the loop to verify, similar to how Claude Code currently asks for permission to run code in the current directory.

Re: Malicious versions of Nx and some supporting plugins were published

#180

Post by 3036e4 » Wed, Aug 27, 2025, 3:47 PM UTC

hvb2 wrote: post #121

3036e4 wrote: post #114

Earlier quoted context omitted.

Small, trivial, things, each solving a very specific problem, and that can be fully understood, sounds pretty amazing though. Much better than what we have now.

That's what a package is supposed to solve, no? Sure there are packages trying to solve 'the world' and as a result come with a whole lot of dependencies, but isn't that on whoever installs it to check? My point was that git clone of the source can't be the solution, or you own all the code... And you can't. You always depend on something....

Your dependencies are also part of your product and your full responsibility. No one you deliver a product to will accept "it wasn't my code, it was in a dependency of one of my dependencies" as an excuse. Of course you need to depend on things, but it is insane to not keep that to a minimum.