Nx compromised: malware uses Claude code CLI to explore the filesystem
103 comments
·August 27, 2025JdeBP
dudeinjapan
Are you affected? Run the affected program. OK, now you are definitely affected.
littlecranky67
Says the malware is in a post-install script - that will not be called by nx, but i.e after an npm install
echelon
[flagged]
dpoloncsak
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?
wat10000
They’re essentially being used as a programming language interpreter. This attack could easily have been done with Python or Ruby or Perl. There can’t be a realistic expectation that these tools are robust against malicious input. You have to either sandbox them or keep malicious input away from them.
echelon
> 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 and notifying customers, (3) studying the breadth of approaches used (4) for future, more ambitious attacks, monitoring them live as threat actors explore systems.
Google and Anthropic absolutely have responsibility here and must devote resources to this.
I am shocked that this is being met with such hostility. I cannot picture a world where LLM vendors are not responsible for making a best attempt at safeguarding their customers. Especially as they seek to have a greater role in business and financial automation.
I've worked at fintechs and we had to go out of our way to look out for our customers. We purchased compromised password and email lists and scanned for impacted customers. Our business didn't cause the data breaches, but we viewed it as our responsibility to protect customers.
Google and Anthropic have the greatest opportunity to make a difference here.
* THIS IS ABSOLUTELY A SEV0 FOR GOOGLE AND ANTHROPIC *:
While it's not a systems outage, it has incredible potential to shape future business and market sentiment. There are going to be major articles written about this in every publication you can think of. Publications that business decision makers read. Forbes, the New York Times, Business Insider. And Google and Anthropic are going to want to own their blurb and state that they acted fast and responsibly. If they're lucky, they can even spin this as an opportunity.
This is the difference between LLMs being allowed in the business workplace and being met with increasing scrutiny. (Not that they shouldn't be scrutinized, but that this incident will overwhelmingly shape the future of the decision envelope.)
octo888
A single top-level comment would suffice. No need to reply to various comments with the same kind of message
echelon
My first two comments in this thread were my initial reaction to what was happening.
I made the above, longer form post to hopefully grab the attention of Google and Anthropic folks. My top-level posts always fall to the very bottom of the page.
Google and Anthropic need to be tracking this.
null
yuyu789
[dead]
f311a
People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year.
This week, I needed to add a progress bar with 8 stats counters to my Go project. I looked at the libraries, and they all had 3000+ lines of code. I asked LLM to write me a simple progress report tracking UI, and it was less than 150 lines. It works as expected, no dependencies needed. It's extremely simple, and everyone can understand the code. It just clears the terminal output and redraws it every second. It is also thread-safe. Took me 25 minutes to integrate it and review the code.
If you don't need a complex stats counter, a simple progress bar is like 30 lines of code as well.
This is a way to go for me now when considering another dependency. We don't have the resources to audit every package update.
coldpie
> People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year.
I was really nervous when "language package managers" started to catch on. I work in the systems programming world, not the web world, so for the past decade, I looked from a distance at stuff like pip and npm and whatever with kind of a questionable side-eye. But when I did a Rust project and saw how trivially easy it was to pull in dozens of completely un-reviewed dependencies from the Internet with Cargo via a single line in a config file, I knew we were in for a bad time. Sure enough. This is a bad direction, and we need to turn back now. (We won't. There is no such thing as computer security.)
skydhash
The thing is, system based package managers require discipline, especially from library authors. Even in the web world, it’s really distressing when you see a minor library is already on its 15 iteration in less that 5 years.
I was trying to build just (the task runner) on Debian 12 and it was impossible. It kept complaining about rust version, then some libraries shenanigans. It is way easier to build Emacs and ffmpeg.
rootnod3
Fully agree. That is why I vendor all my dependencies. On the common lisp side a new tool emerged a while ago for that[1].
On top of that, I try to keep the dependencies to an absolute minimum. In my current project it's 15 dependencies, including the sub-dependencies.
coldpie
I didn't vendor them, but I did do an eyeball scan of every package in the full tree for my project, primarily to gather their license requirements[1]. (This was surprisingly difficult for something that every project in theory must do to meet licensing requirements!) It amounted to approximately 50 dependencies pulled into the build, to create a single gstreamer plugin. Not a fan.
[1] https://github.com/ValveSoftware/Proton/commit/f21922d970888...
skydhash
Vendoring is nice. Using the system version is nicer. If you can’t run on $current_debian, that’s very much a you problem. If postgres and nginx can do it, you can too.
cedws
Rust makes me especially nervous due to the possibility of compile-time code execution. So a cargo build invocation is all it could take to own you. In Go there is no such possibility by design.
exDM69
The same applies to any Makefile, the Python script invoked by CMake or pretty much any other scriptable build system. They are all untrusted scripts you download from the internet and run on your computer. Rust build.rs is not really special in that regard.
Maybe go build doesn't allow this but most other language ecosystems share the same weakness.
BobbyTables2
Fully agree.
So many people are so drunk on the kool aid, I often wonder if I’m the weirdo for not wanting dozens of third party libraries just to build a simple HTTP client for a simple internal REST api. (No I don’t want tokio, Unicode, multipart forms, SSL, web sockets, …). At least Rust has “features”. With pip and such, avoiding the kitchen sink is not an option.
I also find anything not extensively used has bugs or missing features I need. It’s easier to fork/replace a lot of simple dependencies than hope the maintainer merges my PR on a timeline convenient for my work.
bethekidyouwant
Just use your fork until they merge your MR?
littlecranky67
We are using NX heavily (and are not affected) in my teams in a larger insurance company. We have >10 standalone line of business apps and 25+ individual libraries in the same monorepo, managed by NX. I've toyed with other monorepo tools for these kind of complex setup in my career (lerna, rushjs, yarn workspaces) but not only did none came close, lerna is basically handed over to NX, and rushjs is unmaintained.
If you have any proposal how to properly manage the complexity of a FE monorepo with dozens of daily developers involved and heavy CI/CD/Devops integration, please post alternatives - given that security incident many people are looking.
skydhash
I actually loathe those progress trackers. They break emacs shell (looking at you expo and eas).
Why not print a simple counter like: ..10%..20%..30%
Or just: Uploading…
Terminal codes should be for TUI or interactive-only usage.
christophilus
I’d like a package manager that essentially does a git clone, and a culture that says: “use very few dependencies, commit their source code in your repo, and review any changes when you do an update.” That would be a big improvement to the modern package management fiasco.
hvb2
Is that realistic though? What you're proposing is letting go of abstractions completely.
Say you need compression, you're going to review changes in the compression code? What about encryption, a networking library, what about the language you're using itself?
That means you need to be an expert on everything you run. Which means no one will be building anything non trivial.
chrismustcode
I honestly find in go it’s easier and less code to just write whatever feature you’re trying to implement than use a package a lot of the time.
Compared to typescript where it’s a package + code to use said package which always was more loc than anything comparative I have done in golang.
wat10000
Part of the value proposition for bringing in outside libraries was: when they improve it, you get that automatically.
Now the threat is: when they “improve” it, you get that automatically.
left-pad should have been a major wake up call. Instead, the lesson people took away from it seems to have mostly been, “haha, look at those idiots pulling in an entire dependency for ten lines of code. I, on the other hand, am intelligent and thoughtful because I pull in dependencies for a hundred lines of code.”
fluoridation
The problem is less the size of a single dependency but the transitivity of adding dependencies. It used to be, library developers sought to not depend on other libraries if they could avoid it, because it meant their users had to make their build systems more complicated. It was unusual for a complete project to have a dependency graph more than two levels deep. Package managers let you easily build these gigantic dependency graphs with ease. Great for productivity, not so much for security.
wat10000
The size itself isn’t a problem, it’s just a rough indicator of the benefit you get. If it’s only replacing a hundred lines of code, is it really worth bringing in a dependency, and as you point out potentially many transitive dependencies, instead of writing your own? People understood this with left-pad but largely seemed unwilling to extrapolate it to somewhat larger libraries.
roenxi
Honest to goodness, I do most of my coding in a VM now. I don't see how the security profile of these things are tolerable.
The level of potential hostility from agents as a malware vector is really off the charts. We're entering an era where they can scan for opportunities worth >$1,000 in hostaged data, crypto keys, passwords, blackmail material or financial records without even knowing what they're looking for when they breach a box.
christophilus
Similar, but in a podman container which shares nothing other than the source code directory with my host machine.
fsflover
> I do most of my coding in a VM now
Perhaps you may be interested in Qubes OS, where you do everything in VMs with a nice UX. My daily driver, can't recommend it enough.
mikepurvis
How does it avoid the sharing headaches that make the ergonomics of snaps so bad?
fsflover
I never used snaps, so I don't understand what you mean here. Here's a couple of typical Qubes usage patterns: https://www.qubes-os.org/news/2022/10/28/how-to-organize-you..., https://blog.invisiblethings.org/2011/03/13/partitioning-my-...
0xbadcafebee
Before anyone puts the blame on Nx, or Anthropic, I would like to remind you all what actually caused this exploit. The exploit was caused by an exploit, shipped in a package, that was uploaded using a stolen "token" (a string of characters used as a sort of "usename+password" to access a programming-language package-manager repository).
But that's just the delivery mechanism of the attack. What caused the attack to be successful were:
1. The package manager repository did not require signing of artifacts to verify they were generated by an authorized developer.
2. The package manager repository did not require code signing to verify the code was signed by an authorized developer.
3. (presumably) The package manager repository did not implement any heuristics to detect and prevent unusual activity (such as uploads coming from a new source IP or country).
4. (presumably) The package manager repository did not require MFA for the use of the compromised token.
5. (presumably) The token was not ephemeral.
6. (presumably) The developer whose token was stolen did not store the token in a password manager that requires the developer to manually authorize unsealing of the token by a new requesting application and session.
1. You to keep your GitHub tokens/auth in a password manager that requires you to manually authorize unsealing of the token by a new requesting application and session.
This is why I continue to insist there needs to be building codes for software, with inspections and fines for not following through. This attack could have been used on tens of thousands of institutions to bring down finance, power, telecommunications, hospitals, military, etc. And the scope of the attacks and their impact will only increase with AI. Clearly we are not responsible enough to write software safely and securely. So we must have a building code that forces us to do it safely and securely.
snovymgodym
Claude code is by all accounts a revolutionary tool for getting useful work done on a computer.
It's also:
- a NodeJS app
- installed by curling a shell script and piping it into bash
- an LLM that's given free reign to mess with the filesystem, run commands, etc.
So that's what, like 3 big glaring vectors of attack for your system right there?
I would never feel comfortable running it outside of some kind of sandbox, e.g. VM, container, dedicated dev box, etc.
saberience
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 the most amazing and game changing tool I've used since I first used a computer 30 years ago. I couldn't give two fucks about its "vectors of attack", none of them matter if no one has unauthorized access to my computer, and if they do, Claude Code is the least of my issues.
OJFord
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!
kasey_junk
I definitely think running agents in sandboxes is the way to go.
That said Claude code does not have free reign to run commands out of the gate.
sneak
Yes it does; you are thinking of agent tool calls. The software package itself runs as your uid and can do anything you can do (except on macOS where reading of certain directories is individually gated).
kasey_junk
Ok, but that’s true of _any_ program you install so isn’t interesting.
I don’t think the current agent tool call permission model is _right_ but it exists, so saying by default it will freely run those calls is less true of agents than other programs you might run.
otterley
Claude Code is an agent. It will not call any tools or commands without your prior consent.
sneak
None of this is the concerning part. The bad part is that it auto-updates while running without intervention - i.e. it is RCE on your machine for Anthropic by design.
jpalawaga
So we’re declaring all software with auto-updaters as RCE? That doesn’t seem like a useful distinction.
skydhash
That’s pretty much the definition. Auto updating is trusting the developer (Almost always a bad idea).
null
christophilus
Mine doesn’t auto update. I set it up so it doesn’t have permission to do that.
actualwitch
Not only that, but also connects to raw.githubusercontent.com to get the update. Doubt there are any signature checks happening there either. I know people love hating locked down Apple ecosystem, but this kind of stuff is why it is necessary.
sippeangelo
This Semgrep post describes a very different prompt from what Nx reported themselves, which suggests the attacker was "live-editing" their payload over multiple releases and intended to go further.
Still, why does the payload only upload the paths to files without their actual contents?
Why would they not have the full attack ready before publishing it? Was it really just meant as a data gathering operation, a proof of concept, or are they just a bit stupid?
https://github.com/nrwl/nx/security/advisories/GHSA-cxm3-wv7...
nickstinemates
While the attack vector is completely obvious when you think about it, the gumption to do it is novel. Of course this is the best way to exfiltrate data, it's on a blessed path and no one will really bat an eye. Let's see how corporate-mandated anti virus deal with this!
mdrzn
the truly chilling part is using a local llm to find secrets. it's a new form of living off the land, where the malicious logic is in the prompt, not the code. this sidesteps most static analysis.
the entry point is the same old post-install problem we've never fixed, but the payload is next-gen. how do you even defend against malicious prompts?
christophilus
Run Claude Code in a locked down container or VM that has no access to sensitive data, and review all of the code it commits?
vorgol
OSs need to stop letting applications have a free reign of all the files on the file system by default. Some apps come with apparmor/selinux profiles and firejail is also a solution. But the UX needs to change.
terminalbraid
Which operating system lets an application have "free reign of all the files on the file system by default"? Neither Linux, nor any BSD, nor MacOS, nor Windows does. For any of those I'd have to do something deliberately unsafe such as running it as a privileged account (which is not the "default").
eightys3v3n
I would argue the distinction between my own user and root is not meaningful when they say "all files by default". As my own user, it can still access everything I can on a daily basis which is likely everything of importance. Sure it can't replace the sudo binary or something like that, but it doesn't matter because it's already too late. Why when I download and run Firefox can it access every file my user can access, by default. Why couldn't it work a little closer to Android with an option for the user to open up more access. I think this is what they were getting at.
null
sneak
All except macOS let anything running as your uid read and write all of your user’s files.
This is how ransomware works.
divan
So any process on my computer could just start using Claude Code for their own purposes or what? o_O
algo_lover
Any postinstall script can add anything to your bashrc. I sometimes wonder how the modern world hasn't fallen apart yet.
mathiaspoint
Even before AI the authors could have embeded shells in their software and manually done the same thing. This changes surprisingly little.
42lux
It's an RCE it can do whatever the fuck it wants with your PC.
saberience
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.
divan
Ah, I didn't know that claude code has headless mode...
cluckindan
It’s not an RCE, it is a supply chain attack.
freedomben
It's an RCE delivered via supply chain attack
m-hodges
While this feels obvious once its pointed out, I don't think many people have considered it or its implications.
IshKebab
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.
echelon
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.
antiloper
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.
kawsper
I love the header on that page:
> Secure Vibe Coding Starts Here. Wherever code is built, we keep it secure. Learn more →
mathiaspoint
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.
> Are you using a compromised version of nx?
> Run semgrep --config [...]
> Alternatively, you can run nx –version [...]
Have we not learned, yet? The number of points this submission has already earned says we have not.
People, do not trust security advisors who tell you to do such things, especially ones who also remove the original instructions entirely and replace them with instructions to run their tools instead.
The original security advisory is at https://github.com/nrwl/nx/security/advisories/GHSA-cxm3-wv7... and at no point does it tell you to run the compromised programs in order to determine whether they are compromised versions. Or to run semgrep for that matter.