## Summary The local HTTP server started by `nx graph` sent `Access-Control-Allow-Origin: *` on every response, letting any website a developer visited read the server's responses cross-origin — including the full project graph and the output of the `/help` endpoint, which runs a target's configured help command. The practical impact is typically **cross-origin information disclosure**, but can be arbitrary command injection in rare cases. ## Severity Exploitation requires the developer to be running `nx graph` and to visit an attacker page. Any execution beyond benign help commands also requires a malicious target to already be present in the workspace (see Details). ## Affected & Patched Versions Package: `nx` (npm). - **Affected:** `>= 17.0.4, < 22.7.2` and `>= 23.0.0-beta.0, < 23.0.0-beta.2` - **Patched:** `22.7.2`+ (backport) and `23.0.0` (first in `23.0.0-beta.2`) The wildcard CORS header was introduced in `17.0.4`; the `/help` execution endpoint in `19.4.0`. **The `21.x` line is not patched** — `21.x` users should upgrade to `22.7.2` or later. ## Details `nx graph` starts a local server (default `http://127.0.0.1:4211`). Before the fix, its request handler set a wildcard CORS header on every response: ```ts res.setHeader('Access-Control-Allow-Origin', '*'); ``` The `/help` endpoint runs a target's configured command: ```ts const command = target.metadata?.help?.command; return execSync(command, { cwd: target.options?.cwd ?? workspaceRoot }).toString(); ``` A `GET /help` is a CORS "simple request", so a malicious page could `fetch()` it with no preflight, and the wildcard header let the page read the result. This exposes the project graph (project names, file paths, dependencies, build configuration) and the output of any configured help command. The command is not attacker-controlled through the request — it comes from the workspace's project configuration, and first-party plugins (jest, vite, cypress) populate it with benign, read-only help commands. For `/help` to run anything malicious, a target carrying a malicious `help.command` must already exist in the project graph, which can only be introduced by **installing a malicious package** or by **altering the workspace's own code/configuration** — both of which already grant code execution independent of this flaw. The fix ([#35494](https://github.com/nrwl/nx/pull/35494)) removes the header; the browser's same-origin policy then blocks cross-origin reads. ## References - Fix: [nrwl/nx#35494](https://github.com/nrwl/nx/pull/35494) - Introduced: [nrwl/nx#20744](https://github.com/nrwl/nx/pull/20744) (CORS), [nrwl/nx#26629](https://github.com/nrwl/nx/pull/26629) (`/help`) ## Credits Thanks to Nozomu Sasaki (Paul) ([@morimori-dev](https://github.com/morimori-dev)) for finding and responsibly reporting this issue.

## Summary The local HTTP server started by `nx graph` sent `Access-Control-Allow-Origin: *` on every response, letting any website a developer visited read the server's responses cross-origin — including the full project graph and the output of the `/help` endpoint, which runs a target's configured help command. The practical impact is typically **cross-origin information disclosure**, but can be arbitrary command injection in rare cases. ## Severity Exploitation requires the developer to be running `nx graph` and to visit an attacker page. Any execution beyond benign help commands also requires a malicious target to already be present in the workspace (see Details). ## Affected & Patched Versions Package: `nx` (npm). - **Affected:** `>= 17.0.4, < 22.7.2` and `>= 23.0.0-beta.0, < 23.0.0-beta.2` - **Patched:** `22.7.2`+ (backport) and `23.0.0` (first in `23.0.0-beta.2`) The wildcard CORS header was introduced in `17.0.4`; the `/help` execution endpoint in `19.4.0`. **The `21.x` line is not patched** — `21.x` users should upgrade to `22.7.2` or later. ## Details `nx graph` starts a local server (default `http://127.0.0.1:4211`). Before the fix, its request handler set a wildcard CORS header on every response: ```ts res.setHeader('Access-Control-Allow-Origin', '*'); ``` The `/help` endpoint runs a target's configured command: ```ts const command = target.metadata?.help?.command; return execSync(command, { cwd: target.options?.cwd ?? workspaceRoot }).toString(); ``` A `GET /help` is a CORS "simple request", so a malicious page could `fetch()` it with no preflight, and the wildcard header let the page read the result. This exposes the project graph (project names, file paths, dependencies, build configuration) and the output of any configured help command. The command is not attacker-controlled through the request — it comes from the workspace's project configuration, and first-party plugins (jest, vite, cypress) populate it with benign, read-only help commands. For `/help` to run anything malicious, a target carrying a malicious `help.command` must already exist in the project graph, which can only be introduced by **installing a malicious package** or by **altering the workspace's own code/configuration** — both of which already grant code execution independent of this flaw. The fix ([#35494](https://github.com/nrwl/nx/pull/35494)) removes the header; the browser's same-origin policy then blocks cross-origin reads. ## References - Fix: [nrwl/nx#35494](https://github.com/nrwl/nx/pull/35494) - Introduced: [nrwl/nx#20744](https://github.com/nrwl/nx/pull/20744) (CORS), [nrwl/nx#26629](https://github.com/nrwl/nx/pull/26629) (`/help`) ## Credits Thanks to Nozomu Sasaki (Paul) ([@morimori-dev](https://github.com/morimori-dev)) for finding and responsibly reporting this issue.