[depfu]

---

Welcome to Depfu 👋

This is one of the first three pull requests with dependency updates we've sent your way. We tried to start with a few easy patch-level updates. Hopefully your tests will pass and you can merge this pull request without too much risk. This should give you an idea how Depfu works in general.

After you merge your first pull request, we'll send you a few more. We'll never open more than seven PRs at the same time so you're not getting overwhelmed with updates.

Let us know if you have any questions. Thanks so much for giving Depfu a try!

---

---

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

---

Here is everything you need to know about this upgrade. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ nx (20.8.4 → 23.2.1) · Repo

Security Advisories 🚨

🚨 Nx daemon and plugin worker sockets are accessible to other local users

Summary

Nx creates the Unix domain sockets for its daemon and its plugin workers in a shared temporary directory with default permissions, so any other user on the same machine can connect to them. The daemon accepts a PROCESS_IN_BACKGROUND request that names a module to load and invokes its default export, which turns socket access into code execution inside the daemon process. On a multi-user machine — a shared build server, a shared developer box, or a container running several accounts — one local user can execute code as another user running Nx.

Severity

Exploitable by any other unprivileged local user on a shared host while a daemon or plugin worker is running, with no user interaction. There is no known evidence of exploitation in the wild.

Affected & Patched Versions

Package	Vulnerable	Patched
nx	>= 14.6.0, < 22.7.9; >= 23.0.0, < 23.1.2	22.7.9, 23.1.2

Every version in the ranges above is affected. The lower bound is 14.6.0, when the daemon request handler that turns socket access into code execution was added.

Important

Single-user machines are not exposed. The vulnerability requires another local account on the same host, so an ordinary laptop with one user account is unaffected — the exposure is shared CI runners, shared build and development servers, and containers or images that run more than one uid.

Disabling the daemon is not sufficient on its own: the plugin worker sockets used by plugin isolation are created in the same directory with the same permissions, and those are used during normal command runs whether or not the daemon is enabled.

Remediation

Upgrade to 22.7.9 (22.x line) or 23.1.2 (23.x line) or later:

nx migrate 23.1.2

On a shared machine, run nx reset after upgrading so that any sockets and directories created by an older version are removed rather than reused.

If you cannot upgrade, point NX_SOCKET_DIR at a directory you own with mode 0700, which is already honoured by the vulnerable versions, and disable the daemon with NX_DAEMON=false to reduce the reachable surface — though, per the callout above, that does not remove the plugin worker sockets.

Details

The daemon and the plugin workers communicate over Unix domain sockets placed in a subdirectory of the shared OS temporary directory. That directory is created with default permissions, which on a typical system leave it readable and traversable by every user on the machine, and nothing narrows the socket files themselves. The directory name is derived from a hash of the workspace path and the process id, so it is unique but not secret — any local user who lists the temporary directory can find it.

The connection carries no authentication: the containment is meant to be the filesystem permissions alone, and those are too broad. Any local process that can reach the socket is treated as a fully trusted client.

The impact of that access is set by what the daemon's request handlers allow. One handler takes a module path from the request and loads and invokes it; because an absolute path resolves regardless of the lookup constraints in place, a caller who can write a file anywhere on the machine — their own home directory suffices — and connect to the socket can have the daemon execute it, as the user running the daemon. Other handlers expose workspace file contents, the project graph, and task hashes to the same unauthenticated caller.

Credits

Reported by researchers at the University of Sydney:

• Liyi
• Ziyue
• Strick
• Maurice
• Chenchen

🚨 Nx: OS command injection via git revisions and remote refs

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

🚨 Nx: OS command injection via git revisions and remote refs

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

🚨 Nx: Path traversal in nx migrate package-migrations extraction

Summary

nx migrate reads each target package's nx-migrations.migrations value from its manifest and extracts the referenced file to a path built by joining that value onto a temporary directory. The value is never validated, so a package whose migrations field contains .. segments (or an absolute path) steers the extraction to write outside the temporary directory. A hostile package — or any package pulled in transitively through a trusted package's packageGroup — can write attacker-controlled content, or truncate an existing file, anywhere the running user can write. This happens during migration planning, before the user reviews the migration list and before --run-migrations, so it does not require the user to approve or execute anything.

Most workspaces need no action. By default nx migrate does not run the nx installed in your workspace — it installs nx@latest into a temporary directory and performs the upgrade planning, including this extraction, with that copy. Now that a patched nx is the latest release, a default nx migrate run is unaffected whatever version the workspace has installed. The installed version only runs, and is only then exposed, when that hand-off is bypassed — see Remediation.

Severity

Exploitable when the victim runs nx migrate against a package the attacker controls, directly or through a trusted package's packageGroup. The primary impact is a file write with attacker-controlled content and no path confinement; overwriting an auto-loaded file (a shell rc, a git hook, a CI script) escalates that write to code execution. There is no known evidence of exploitation in the wild.

Affected & Patched Versions

Package	Vulnerable	Patched
nx	>= 13.10.0, < 22.7.10; >= 23.0.0, < 23.2.1	22.7.10, 23.2.1

Every version in the ranges above is affected. The lower bound is 13.10.0, the first release where nx migrate extracted a package's migrations file from its tarball; earlier versions resolved migrations without that extraction.

Important

nx migrate normally fetches and runs nx@latest rather than the nx installed in your workspace. The ranges above therefore say where the vulnerable code ships, not who is exposed — it only runs when that hand-off is bypassed.

Remediation

If you run nx migrate normally, there is nothing to do. It resolves and runs the latest nx, which is patched, so your workspace's own nx version does not matter for this flaw.

Upgrade only if you bypass that hand-off and run the workspace's nx instead — that is, if you set NX_USE_LOCAL or NX_MIGRATE_USE_LOCAL, pin NX_MIGRATE_CLI_VERSION to an affected version, resume an existing run with --run-id, or run where the temporary install fails and nx migrate falls back to the local nx. In those cases upgrade to 22.7.10 (22.x line) or 23.2.1 (23.x line) or later:

nx migrate 23.2.1

The fix is a drop-in — no configuration changes are required, and no legitimate migrations value is affected (real packages reference ./migrations.json or another path within their own directory, all of which remain valid). Either way, do not run nx migrate against packages, or packageGroup members, that you do not trust.

Details

While planning an upgrade, nx migrate extracts each target package's migrations file to a destination built by joining the package's own nx-migrations.migrations value onto a temporary directory. That value is read from the manifest without validation, and it is handled asymmetrically: the name Nx matches against the archive entries is normalized (so its .. segments collapse), while the destination path it writes to is a raw join that keeps the .. segments and resolves outside the temporary directory. Because the attacker controls the tarball, they name their entry to equal the normalized form; the match then succeeds and the bytes are written to the un-normalized, escaping destination. The normalization is not a defence — it only dictates what the attacker must name their entry.

The same value also seeds the directory used for prompt-file extraction, which has the same shape, so both writes are steerable from the one field.

Two distinct primitives fall out of this:

• Truncation — the destination write stream is opened, and truncates, before any tar entry is inspected. So a package that points migrations at an existing file empties that file even when no tar entry matches — no crafted archive required.
• Controlled write — when a tar entry's name matches, its bytes are written to the escaping destination. The extractor performs no path containment of its own.

Credits

• Arkadiusz Marta (RE:SOURCE) — Reporter

🚨 Nx daemon and plugin worker sockets are accessible to other local users

Summary

Nx creates the Unix domain sockets for its daemon and its plugin workers in a shared temporary directory with default permissions, so any other user on the same machine can connect to them. The daemon accepts a PROCESS_IN_BACKGROUND request that names a module to load and invokes its default export, which turns socket access into code execution inside the daemon process. On a multi-user machine — a shared build server, a shared developer box, or a container running several accounts — one local user can execute code as another user running Nx.

Severity

Exploitable by any other unprivileged local user on a shared host while a daemon or plugin worker is running, with no user interaction. There is no known evidence of exploitation in the wild.

Affected & Patched Versions

Package	Vulnerable	Patched
nx	>= 14.6.0, < 22.7.9; >= 23.0.0, < 23.1.2	22.7.9, 23.1.2

Every version in the ranges above is affected. The lower bound is 14.6.0, when the daemon request handler that turns socket access into code execution was added.

Important

Single-user machines are not exposed. The vulnerability requires another local account on the same host, so an ordinary laptop with one user account is unaffected — the exposure is shared CI runners, shared build and development servers, and containers or images that run more than one uid.

Disabling the daemon is not sufficient on its own: the plugin worker sockets used by plugin isolation are created in the same directory with the same permissions, and those are used during normal command runs whether or not the daemon is enabled.

Remediation

Upgrade to 22.7.9 (22.x line) or 23.1.2 (23.x line) or later:

nx migrate 23.1.2

On a shared machine, run nx reset after upgrading so that any sockets and directories created by an older version are removed rather than reused.

If you cannot upgrade, point NX_SOCKET_DIR at a directory you own with mode 0700, which is already honoured by the vulnerable versions, and disable the daemon with NX_DAEMON=false to reduce the reachable surface — though, per the callout above, that does not remove the plugin worker sockets.

Details

The daemon and the plugin workers communicate over Unix domain sockets placed in a subdirectory of the shared OS temporary directory. That directory is created with default permissions, which on a typical system leave it readable and traversable by every user on the machine, and nothing narrows the socket files themselves. The directory name is derived from a hash of the workspace path and the process id, so it is unique but not secret — any local user who lists the temporary directory can find it.

The connection carries no authentication: the containment is meant to be the filesystem permissions alone, and those are too broad. Any local process that can reach the socket is treated as a fully trusted client.

The impact of that access is set by what the daemon's request handlers allow. One handler takes a module path from the request and loads and invokes it; because an absolute path resolves regardless of the lookup constraints in place, a caller who can write a file anywhere on the machine — their own home directory suffices — and connect to the socket can have the daemon execute it, as the user running the daemon. Other handlers expose workspace file contents, the project graph, and task hashes to the same unauthenticated caller.

Credits

Reported by researchers at the University of Sydney:

• Liyi
• Ziyue
• Strick
• Maurice
• Chenchen

🚨 Nx: Path traversal in nx migrate package-migrations extraction

Summary

nx migrate reads each target package's nx-migrations.migrations value from its manifest and extracts the referenced file to a path built by joining that value onto a temporary directory. The value is never validated, so a package whose migrations field contains .. segments (or an absolute path) steers the extraction to write outside the temporary directory. A hostile package — or any package pulled in transitively through a trusted package's packageGroup — can write attacker-controlled content, or truncate an existing file, anywhere the running user can write. This happens during migration planning, before the user reviews the migration list and before --run-migrations, so it does not require the user to approve or execute anything.

Most workspaces need no action. By default nx migrate does not run the nx installed in your workspace — it installs nx@latest into a temporary directory and performs the upgrade planning, including this extraction, with that copy. Now that a patched nx is the latest release, a default nx migrate run is unaffected whatever version the workspace has installed. The installed version only runs, and is only then exposed, when that hand-off is bypassed — see Remediation.

Severity

Exploitable when the victim runs nx migrate against a package the attacker controls, directly or through a trusted package's packageGroup. The primary impact is a file write with attacker-controlled content and no path confinement; overwriting an auto-loaded file (a shell rc, a git hook, a CI script) escalates that write to code execution. There is no known evidence of exploitation in the wild.

Affected & Patched Versions

Package	Vulnerable	Patched
nx	>= 13.10.0, < 22.7.10; >= 23.0.0, < 23.2.1	22.7.10, 23.2.1

Every version in the ranges above is affected. The lower bound is 13.10.0, the first release where nx migrate extracted a package's migrations file from its tarball; earlier versions resolved migrations without that extraction.

Important

nx migrate normally fetches and runs nx@latest rather than the nx installed in your workspace. The ranges above therefore say where the vulnerable code ships, not who is exposed — it only runs when that hand-off is bypassed.

Remediation

If you run nx migrate normally, there is nothing to do. It resolves and runs the latest nx, which is patched, so your workspace's own nx version does not matter for this flaw.

Upgrade only if you bypass that hand-off and run the workspace's nx instead — that is, if you set NX_USE_LOCAL or NX_MIGRATE_USE_LOCAL, pin NX_MIGRATE_CLI_VERSION to an affected version, resume an existing run with --run-id, or run where the temporary install fails and nx migrate falls back to the local nx. In those cases upgrade to 22.7.10 (22.x line) or 23.2.1 (23.x line) or later:

nx migrate 23.2.1

The fix is a drop-in — no configuration changes are required, and no legitimate migrations value is affected (real packages reference ./migrations.json or another path within their own directory, all of which remain valid). Either way, do not run nx migrate against packages, or packageGroup members, that you do not trust.

Details

While planning an upgrade, nx migrate extracts each target package's migrations file to a destination built by joining the package's own nx-migrations.migrations value onto a temporary directory. That value is read from the manifest without validation, and it is handled asymmetrically: the name Nx matches against the archive entries is normalized (so its .. segments collapse), while the destination path it writes to is a raw join that keeps the .. segments and resolves outside the temporary directory. Because the attacker controls the tarball, they name their entry to equal the normalized form; the match then succeeds and the bytes are written to the un-normalized, escaping destination. The normalization is not a defence — it only dictates what the attacker must name their entry.

The same value also seeds the directory used for prompt-file extraction, which has the same shape, so both writes are steerable from the one field.

Two distinct primitives fall out of this:

• Truncation — the destination write stream is opened, and truncates, before any tar entry is inspected. So a package that points migrations at an existing file empties that file even when no tar entry matches — no crafted archive required.
• Controlled write — when a tar entry's name matches, its bytes are written to the escaping destination. The extractor performs no path containment of its own.

Credits

• Arkadiusz Marta (RE:SOURCE) — Reporter

🚨 Nx: Zip-Slip in the self-hosted remote cache

Summary

The Nx self-hosted HTTP remote cache extracts downloaded cache artifacts without constraining where files are written. A malicious — or on-path (MITM) — remote cache server can return a crafted tar archive whose entries escape the cache directory and write to arbitrary locations on the machine running Nx. This arbitrary file write can be escalated to remote code execution. The directly exploitable issue is the self-hosted HTTP remote cache.

Affected Packages

Important

Nx's default local cache and Nx Cloud are NOT affected. The default local cache and Nx Cloud use separate cache retrieval and extraction mechanisms that does not have this vulnerability. Only workspaces that use a self-hosted remote cache (NX_SELF_HOSTED_REMOTE_CACHE_SERVER, @nx/s3-cache, etc.) are affected.

Two self-hosted cache surfaces are affected:

1. The built-in HTTP remote cache (NX_SELF_HOSTED_REMOTE_CACHE_SERVER, in nx) — fixed in the patched release.
2. The self-hosted cache packages — @nx/s3-cache, @nx/gcs-cache, @nx/azure-cache, @nx/shared-fs-cache (and their @nx/powerpack-* predecessors) — the same flaw in their own extractor. Deprecated (CVE-2025-36852) and not patched; migrate off (see Remediation).

The shared step that copies cached outputs into the workspace was also part of the exposure and is hardened in the patched nx release.

Remediation

Upgrade to Nx 22.7.7 or 23.0.2 (or later). The patched extractor is a drop-in — no configuration change is required.

If you use the S3, GCS, Azure, or shared-filesystem cache packages

@nx/s3-cache, @nx/gcs-cache, @nx/azure-cache, and @nx/shared-fs-cache (and their @nx/powerpack-* predecessors) are separately versioned packages and are already deprecated (see CVE-2025-36852). Upgrading nx hardens the shared restore step, but it does not fully secure these packages. The remediation for them is to migrate off — to Nx Cloud or the self-hosted OpenAPI/HTTP remote cache — per the deprecation guidance: https://nx.dev/docs/reference/deprecated/self-hosted-cache-packages

Details

When Nx retrieves an artifact from the self-hosted HTTP remote cache, it downloads a gzipped tar archive and extracts it. The extractor joined each untrusted tar entry name directly onto the output directory and unpacked it with tar's unguarded Entry::unpack(), which performs no containment check:

// vulnerable
let path_on_disk = output_dir.join(entry_path); // entry_path is attacker-controlled
fs::create_dir_all(path_on_disk.parent()…)?;
entry.unpack(&path_on_disk)?;

In addition, restore now copies only the declared task outputs (never the whole cache directory), confined to the workspace root; parent directories are realized as real directories so a write can never traverse a symlink; declared outputs that resolve outside the workspace are rejected; and the malformed-input cases return errors instead of panicking.

References

• Fix: #36116 (merged)
• TLS-verification warning follow-up: #36132 (merged)
• Vulnerable extractor introduced in Nx 20.8.0: #30593

Credits

• Lidor B., Novee Security — Reporter
• Assaf Levkovich, Novee Security — Reporter

🚨 Nx: Zip-Slip in the self-hosted remote cache

Summary

The Nx self-hosted HTTP remote cache extracts downloaded cache artifacts without constraining where files are written. A malicious — or on-path (MITM) — remote cache server can return a crafted tar archive whose entries escape the cache directory and write to arbitrary locations on the machine running Nx. This arbitrary file write can be escalated to remote code execution. The directly exploitable issue is the self-hosted HTTP remote cache.

Affected Packages

Important

Nx's default local cache and Nx Cloud are NOT affected. The default local cache and Nx Cloud use separate cache retrieval and extraction mechanisms that does not have this vulnerability. Only workspaces that use a self-hosted remote cache (NX_SELF_HOSTED_REMOTE_CACHE_SERVER, @nx/s3-cache, etc.) are affected.

Two self-hosted cache surfaces are affected:

1. The built-in HTTP remote cache (NX_SELF_HOSTED_REMOTE_CACHE_SERVER, in nx) — fixed in the patched release.
2. The self-hosted cache packages — @nx/s3-cache, @nx/gcs-cache, @nx/azure-cache, @nx/shared-fs-cache (and their @nx/powerpack-* predecessors) — the same flaw in their own extractor. Deprecated (CVE-2025-36852) and not patched; migrate off (see Remediation).

The shared step that copies cached outputs into the workspace was also part of the exposure and is hardened in the patched nx release.

Remediation

Upgrade to Nx 22.7.7 or 23.0.2 (or later). The patched extractor is a drop-in — no configuration change is required.

If you use the S3, GCS, Azure, or shared-filesystem cache packages

@nx/s3-cache, @nx/gcs-cache, @nx/azure-cache, and @nx/shared-fs-cache (and their @nx/powerpack-* predecessors) are separately versioned packages and are already deprecated (see CVE-2025-36852). Upgrading nx hardens the shared restore step, but it does not fully secure these packages. The remediation for them is to migrate off — to Nx Cloud or the self-hosted OpenAPI/HTTP remote cache — per the deprecation guidance: https://nx.dev/docs/reference/deprecated/self-hosted-cache-packages

Details

When Nx retrieves an artifact from the self-hosted HTTP remote cache, it downloads a gzipped tar archive and extracts it. The extractor joined each untrusted tar entry name directly onto the output directory and unpacked it with tar's unguarded Entry::unpack(), which performs no containment check:

// vulnerable
let path_on_disk = output_dir.join(entry_path); // entry_path is attacker-controlled
fs::create_dir_all(path_on_disk.parent()…)?;
entry.unpack(&path_on_disk)?;

In addition, restore now copies only the declared task outputs (never the whole cache directory), confined to the workspace root; parent directories are realized as real directories so a write can never traverse a symlink; declared outputs that resolve outside the workspace are rejected; and the malformed-input cases return errors instead of panicking.

References

• Fix: #36116 (merged)
• TLS-verification warning follow-up: #36132 (merged)
• Vulnerable extractor introduced in Nx 20.8.0: #30593

Credits

• Lidor B., Novee Security — Reporter
• Assaf Levkovich, Novee Security — Reporter

🚨 `nx graph` dev server permissive CORS policy

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:

res.setHeader('Access-Control-Allow-Origin', '*');

The /help endpoint runs a target's configured command:

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) removes the header; the browser's same-origin policy then blocks cross-origin reads.

References

• Fix: nrwl/nx#35494
• Introduced: nrwl/nx#20744 (CORS), nrwl/nx#26629 (/help)

Credits

Thanks to Nozomu Sasaki (Paul) (@morimori-dev) for finding and responsibly reporting this issue.

🚨 `nx graph` dev server permissive CORS policy

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:

res.setHeader('Access-Control-Allow-Origin', '*');

The /help endpoint runs a target's configured command:

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) removes the header; the browser's same-origin policy then blocks cross-origin reads.

References

• Fix: nrwl/nx#35494
• Introduced: nrwl/nx#20744 (CORS), nrwl/nx#26629 (/help)

Credits

Thanks to Nozomu Sasaki (Paul) (@morimori-dev) for finding and responsibly reporting this issue.

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

---

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands

@​depfu rebase

Rebases against your default branch and redoes this update

@​depfu recreate

Recreates this PR, overwriting any edits that you've made to it

@​depfu merge

Merges this PR once your tests are passing and conflicts are resolved

@​depfu cancel merge

Cancels automatic merging of this PR

@​depfu close

Closes this PR and deletes the branch

@​depfu reopen

Restores the branch and reopens this PR (if it's closed)

@​depfu pause

Ignores all future updates for this dependency and closes this PR

@​depfu pause [minor|major]

Ignores all future minor/major updates for this dependency and closes this PR

@​depfu resume

Future versions of this dependency will create PRs again (leaves this PR as is)

[changeset-bot]

⚠️ No Changeset found

Latest commit: 863e591

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR