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