←back to thread

493 points neuroo | 2 comments | | HN request time: 0s | source
Show context
JdeBP ◴[] 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 #
1. neuroo ◴[] No.45042038[source]
Hi. 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.... 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) if you curl it and run `semgrep --config=rule.yaml`

replies(1): >>45044321 #
2. pharrington ◴[] No.45044321[source]
did you mean to link to https://github.com/semgrep/semgrep instead?