Nx: OS command injection via git revisions and remote refs — nx
Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')Summary
Nx core builds several git invocations as shell command strings with untrusted values interpolated into them, so a value that should be a git revision or ref is parsed by /bin/sh instead. Two entry points are reachable by an attacker: affected commands, where defaultBase / affected.defaultBase from nx.json (and the NX_BASE / NX_HEAD environment variables) reach git merge-base and git diff; and nx import, where a branch name advertised by a remote repository reaches git fetch, git checkout, and git config. In both cases an attacker who controls a repository — or who opens a pull request against one — gets arbitrary command execution on the machine of anyone who runs an ordinary Nx command against it, including CI runners.
The affected path is the more serious of the two. nx affected and nx show projects --affected run constantly in CI, so a pull request that changes nothing but nx.json is enough to execute code on the runner with whatever credentials that job holds.
Severity
Exploitable by anyone who controls repository content — a fork's pull request, or a repository the victim clones — that the victim then runs an ordinary nx affected or nx import against; no access to the victim's machine is required. We have no evidence of exploitation in the wild.
Affected & Patched Versions
| Package | Vulnerable | Patched |
| --- | --- | --- |
| nx | >= 14.0.0, < 22.7.8; >= 23.0.0, < 23.1.1 | 22.7.8, 23.1.1 |
Treat every version below the patched ones as affected.
Remediation
Upgrade to 22.7.8 (22.x line) or 23.1.1 (23.x line) or later:
nx migrate 23.1.1
The fix is a drop-in — no configuration changes are required. If you cannot upgrade, treat nx.json from untrusted sources as executable content, do not run affected commands against pull requests you have not reviewed, and do not run nx import against repositories you do not trust.
Details
affected commands
Nx computes the merge base and the changed-file set by building git merge-base and git diff command lines as strings and running them through a shell. The base and head revisions in those strings come from nx.json's defaultBase / affected.defaultBase or from the NX_BASE / NX_HEAD environment variables, and a related code path reads file contents with git show <revision>:<path> the same way. Because a shell parses the whole line, a revision value containing shell syntax is executed rather than passed to git.
The revisions are wrapped in double quotes, which looks protective but is not: POSIX shells still perform command substitution inside double quotes, so a value of $(…) runs without needing to break out of the quotes.
nx import
The GitRepository helper runs every git operation — fetch, checkout, reset, config, and others — by interpolating its arguments into a shell command string. The untrusted argument is a branch name: nx import lists the branches a remote advertises, offers them to the user to choose from, and feeds the chosen name back into those commands. A hostile repository controls the names of its own branches, so it controls the command that runs when one is selected.
Credits
- Arkadiusz Marta (RE:SOURCE) — Reporter
- https://github.com/nrwl/nx/commit/11ab38573478172109bb5306cb30ca4af246caf0
- https://github.com/nrwl/nx/commit/4159295a037fdbd8e7f44a33a19d85ab3792415b
- https://github.com/nrwl/nx/commit/9ce184a04d2098a4797c8b0d6877ee079b751abf
- https://github.com/nrwl/nx/commit/c12850ce7b364db08e325c13541641d754db7123
- https://github.com/nrwl/nx/commit/cd9b3c068e17adc9c1722b35b9ca962b98542c20
- https://github.com/nrwl/nx/commit/cf996496bbad727362d48292b50fafc8c3665847
- https://github.com/nrwl/nx/pull/36348
- https://github.com/nrwl/nx/pull/36379
- https://github.com/nrwl/nx/releases/tag/22.7.8
- https://github.com/nrwl/nx/releases/tag/23.1.1
- https://github.com/nrwl/nx/security/advisories/GHSA-w2vw-w76x-qr89
Is nx exposed on your perimeter?
A vulnerability database tells you what is broken. Attack surface management tells you where it is running: it discovers your internet-facing assets and flags the ones affected by issues like this one.
What is attack surface management? →
Deep Security Visibility Without the Complexity
SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.
- No setup fees
- 5-min deployment
- Cancel anytime
Frequently Asked Questions
A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.
CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.
A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.
Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.
Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.
SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.