4 ms·
> Are you using a compromised version of nx? > Run semgrep --config [...] > Alternatively, you can run nx –version [...] Have we not learned, yet? The numbe
by JdeBP 1y ago
> 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-wv7p-598c 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.
- dudeinjapan 1y agoAre you affected? Run the affected program. OK, now you are definitely affected.
- littlecranky67 1y agoSays the malware is in a post-install script - that will not be called by nx, but i.e after an npm install
- reactordev 1y agoConsider anything pre or post attached to the package as tainting the package.
- SoftTalker 1y agoConsider your entire system tainted, nothing is trustworthy at this point. Wipe and rebuild from known good media.
- littlecranky67 1y agoThe malware is "luckily" written in javascript and such quite easy to analyse. No manipulation outside of .zshrc or .bashrc and a temp txt file.
- tsukikage 1y agoThat's what the code you can see now does. It may or may not be the same as what ran.
- littlecranky67 1y agoNope, 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.
- reactordev 1y agoCorrect, 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.
- tempaccount420 1y agoWASM should be easier to analyze since you can't look at what functions the WASM imports to do side-effects.
- dudeinjapan 1y agoOh good. I guess running the actual program was too many steps.
- baxtr 1y agoIt might be even better than that: Create a blog post about a security issue. Post it on HN and get upvotes. Find people who believe they might be affected. Let them run the affected program. Boom.
- ghurtado 1y agoEither I've grown old and bitter enough that I think this is likely the case, or this is just a rational take and most likely what happened. I'm not sure which is worse.
- pharrington 1y agoYeah. The blogpost reads like a confession. It's very strange.
- pastel8739 1y agoWhat exactly are “such things” that should cause us not to trust? Executing programs?
- threadsgiggle 1y ago[dead]
- ezfe 1y agoDon't use the hacked program to check if it's hacked! For starters, it can lie.
- deleted 1y ago[deleted]
- neuroo 1y agoHi. Co-author of the post here. Good callout. Evidence so far points to `nx --version` itself being safe because this was in a post-install script but we changed the rec in our post. We took the versions in the Github security advisory and compiled it into a Semgrep rule which is MIT-licensed: https://semgrep.dev/c/r/oqUk5lJ/semgrep.ssc-mal-resp-2025-08-nx-build-compromised https://semgrep.dev/c/r/oqUk5lJ/semgrep.ssc-mal-resp-2025-08.... Semgrep rules can be overkill for these use cases but it can be convenient to have a single command to check for all affected versions across multiple packages, especially for our users who already have Semgrep installed. That's basically what I did on all our internal repos. We updated the blog post to note the Semgrep rule is MIT licensed. And you can run locally with Semgrep (which is LGPL: https://github.com/returntocorp/semgrep https://github.com/returntocorp/semgrep) if you curl it and run `semgrep --config=rule.yaml`
- pharrington 1y agodid you mean to link to https://github.com/semgrep/semgrep https://github.com/semgrep/semgrep instead?