CVE-2026-54753: Nx Graph Server CORS Misconfiguration Enables Cross-Origin Information Disclosure

Technical summary

The Nx graph server fails to properly restrict Cross-Origin Resource Sharing (CORS), responding with `Access-Control-Allow-Origin: *` to all requests. This violates the same-origin policy and allows cross-origin JavaScript code to fetch responses that would normally be blocked by the browser. The `/help` endpoint is particularly risky—it executes a target's configured help command and returns the output, creating a command injection vector if an attacker can influence the project configuration or intercept the developer's build system. The vulnerability stems from CWE-749 (Exposed Dangerous Method or Function) and CWE-942 (Permissive Cross-Domain Policy), arising because the development server prioritizes convenience over security boundaries.

Business impact

Development teams using Nx face exposure of proprietary project architecture, dependency graphs, and internal tooling commands during local development. If a developer visits a malicious or compromised website while running `nx graph`, that site can exfiltrate the project graph—revealing code structure, build targets, and organizational dependencies. In environments where help commands include sensitive operations (database migrations, credential generation, or deployment scripts), attackers may trigger unintended execution. The real-world impact depends on what developers have configured in their Nx targets and what sites they visit during development, but the risk is elevated in organizations with strict IP or architecture confidentiality requirements.

Affected systems

Nx versions 17.0.4 through 22.7.1, and 23.0.0-beta.1 are vulnerable. The affected versions span roughly two years of releases. Organizations should audit their nx package.json dependencies and lock files. The vulnerability only manifests when developers actively use the `nx graph` command; teams using Nx solely for CLI task execution without the graph visualization feature have reduced immediate exposure, though the underlying CORS misconfiguration persists.

Exploitability

Exploitation requires user interaction—a developer must be running `nx graph` (which starts a local server, typically on http://localhost:8888 or similar) and then visit a website controlled or compromised by the attacker. The attacker's site uses JavaScript to make cross-origin requests to the Nx server and read the responses. No special privileges are required; the barrier is primarily social and environmental. The CVSS score of 5.9 (MEDIUM) reflects this: network-accessible but requiring user action and a specific local precondition. Command injection via the `/help` endpoint is possible but requires the project to configure help commands with dangerous operations, making it a secondary concern for most teams.

Remediation

Upgrade Nx to version 22.7.2 or 23.0.0-beta.2 or later. These versions fix the CORS misconfiguration by restricting the `Access-Control-Allow-Origin` header to localhost or removing it entirely for the development server. After patching, the graph server will no longer respond to cross-origin requests from arbitrary websites. Verify the fix in your environment by confirming that the server no longer sends permissive CORS headers when inspected via browser developer tools.

Patch guidance

Update your Nx installation by running `npm install -g nx@latest` or updating the Nx dependency in your project's package.json to version 22.7.2 or later (or 23.0.0-beta.2 for early adopters). If you use Nx as a project dependency (the recommended approach), update your lock file and reinstall: `npm install` or `yarn install`. Verify the patched version with `nx --version`. No configuration changes are required post-patch; the CORS behavior is corrected by default. Test that `nx graph` continues to function normally after the upgrade.

Detection guidance

Monitor for the presence of Nx versions 17.0.4–22.7.1 in your codebase and CI/CD manifests. Use software composition analysis (SCA) tools to flag vulnerable Nx package versions. In production environments, there is no direct exposure because the graph server is a local development tool. During incident response or forensics, inspect browser history and network logs from developer machines to determine if anyone visited potentially malicious sites while running `nx graph`. Check project configuration (nx.json and project.json) for unusual or overly permissive help commands that could be abused.

Why prioritize this

Although categorized as MEDIUM severity, prioritize this based on team size and development practices. Teams with many developers, high code confidentiality requirements, or developers who frequently visit external websites should treat this as HIGH priority for immediate patching. The primary risk is information disclosure of your project graph, which competitors or malicious actors could use to understand your architecture. Command injection scenarios are lower-probability but high-impact. Given that patching requires only a simple dependency update with no breaking changes, remediation effort is minimal, favoring rapid deployment.

Risk score, explained

CVSS 5.9 balances the ease of data exfiltration (network-accessible, no authentication) against the requirement for user interaction (developer must run `nx graph` and visit an attacker-controlled or compromised site) and the limited scope of the impact (information disclosure without system changes). The score does not fully capture the business risk of architecture disclosure or the conditional command injection risk, both of which warrant organizational context in prioritization decisions.

Frequently asked questions