Malicious versions of Nx and some supporting plugins were published

So any process on my computer could just start using Claude Code for their own purposes or what? o_O

While this feels obvious once its pointed out, I don't think many people have considered it or its implications.

Yes. It's a whole new attack vector.

This should be a SEV0 at Google and Anthropic and they need to be all-hands in monitoring this and communicating this to the public.

Their communications should be immediate and fully transparent.

Any postinstall script can add anything to your bashrc. I sometimes wonder how the modern world hasn't fallen apart yet.

Yeah but so what? A process on your computer could do whatever it wants anyway. The article claims:

> What's novel about using LLMs for this work is the ability to offload much of the fingerprintable code to a prompt. This is impactful because it will be harder for tools that rely almost exclusively on Claude Code and other agentic AI / LLM CLI tools to detect malware.

But I don't buy it. First of all the prompt itself is still fingerprintable, and second it's not very difficult to evade fingerprinting anyway. Especially on Linux.

Even before AI the authors could have embeded shells in their software and manually done the same thing. This changes surprisingly little.

Edit: Was not supposed to create a flamewar about semantics...

It's not a SEV0 for LLM providers. If you already have code execution on some system, you've lost already, and whatever process the malware happens to start next is not at fault.

It’s not an RCE, it is a supply chain attack.

Ah, I didn't know that claude code has headless mode...

It's an RCE delivered via supply chain attack

If that's your definition then most of modern software is an RCE. Mac OSX is also an RCE, so is Windows 11, Chrome etc.

It 100% is, and I posted my rationale here [1]. I would stake my reputation on this being the appropriate stance.

[1] https://news.ycombinator.com/item?id=45039442

realistically, how many times has this happened in eg homebrew? Hard to be worried tbh.

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

I don't think this solves the world but as a quickfix for this particular exploit I ran:

sudo chattr -i $HOME/.shrc

sudo chattr -i $HOME/.profile

to make them immutable. I also added:

alias unlock-shrc="sudo chattr -i $HOME/.shrc"

alias lock-shrc="sudo chattr +i $HOME/.shrc"

To my profile to make it a bit easier to lock/unlock.

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.

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

Yes, as I tried to make clear above, these are orthogonal. The supply chain attack is NOT an RCE, it's a delivery mechanism. The RCE is the execution of the attacker's code, regardless how it got there.

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

We'll have to disagree on this one, unless one of us can cite a definition from a source we can agree on. Yes frequently RCE is something an attacker can push without requiring the user to do something, but I don't think that changes the nature of the fact that you are achieving remote code execution. Whether the user triggers the execution of your code by `npm install`ing your infected package or whether the attacker triggers it by sending an exploitative packet to a vulnerable network service isn't a big enough nuance in my opinion to make it not be RCE. From that perspective, the user had to start the vulnerable service in the first place, or even turn the computer on, so it still requires some user (not the attacker) action before it's vulnerable.