←back to thread

Nx compromised: malware uses Claude code CLI to explore the filesystem

(semgrep.dev)
493 points neuroo | 2 comments | 27 Aug 25 12:18 UTC | HN request time: 0.001s | source
Show context
JdeBP ◴[27 Aug 25 12:55 UTC] No.45038993[source]▶
> 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.

replies(5): >>45039083 #>>45040461 #>>45041384 #>>45041551 #>>45042038 #
dudeinjapan ◴[27 Aug 25 13:02 UTC] No.45039083[source]▶
Are you affected? Run the affected program. OK, now you are definitely affected.
replies(2): >>45039230 #>>45041280 #
littlecranky67 ◴[27 Aug 25 13:13 UTC] No.45039230[source]▶
Says the malware is in a post-install script - that will not be called by nx, but i.e after an npm install
replies(2): >>45040135 #>>45041022 #
reactordev ◴[27 Aug 25 14:22 UTC] No.45040135[source]▶
Consider anything pre or post attached to the package as tainting the package.
replies(1): >>45040219 #
SoftTalker ◴[27 Aug 25 14:28 UTC] No.45040219[source]▶
Consider your entire system tainted, nothing is trustworthy at this point. Wipe and rebuild from known good media.
replies(1): >>45040954 #
littlecranky67 ◴[27 Aug 25 15:22 UTC] No.45040954[source]▶
The malware is "luckily" written in javascript and such quite easy to analyse. No manipulation outside of .zshrc or .bashrc and a temp txt file.
replies(1): >>45041971 #
tsukikage ◴[27 Aug 25 16:42 UTC] No.45041971[source]▶
That's what the code you can see now does. It may or may not be the same as what ran.
replies(1): >>45043530 #
littlecranky67 ◴[27 Aug 25 18:54 UTC] No.45043530[source]▶
Nope, because the script was commited to upstream and you can review what ended in the package.

It seems a lot of general "wisdom" here is thrown by people who have not looked into this particular incident or are unfamiliar with js node dev in general.

replies(1): >>45044858 #
1. reactordev ◴[27 Aug 25 20:35 UTC] No.45044858[source]▶
Correct, luckily, but all it takes is one eval. So be diligent about checking. However, like you said, luckily it’s JavaScript and there’s a history online that you can see.

Be weary of binary wasms though, harder to analyze. In the end, because it was published and npm allows you to see the history, we can all see.

Still, from a security standpoint, anything within a “package” that is compromised, compromises the package. Don’t install it. Wait for the fix.

replies(1): >>45048628 #
2. tempaccount420 ◴[28 Aug 25 05:13 UTC] No.45048628[source]▶
WASM should be easier to analyze since you can't look at what functions the WASM imports to do side-effects.