Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦 npm
Not in CISA KEV

@nx/maven and @nx/gradle have OS command injection via nx.json plugin optionsGHSA-qm8w-vx34-5j9j

Fix: nrwl/nx#36626

GHSA-qm8w-vx34-5j9j is a OS Command Injection vulnerability in @nx/maven. A fix is available for @nx/maven — see the affected versions and patch details below.

Also known asCVE-2026-119282
Published
Updated
Affected
4 pkgs
Patched
4 / 4
Exploits
None indexed
Exploitation data as of Oct 30, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Real-World Exposure

4 pkgs affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

0other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
@nx/mavennpm
9Kdownloads / week
@nx/gradlenpm
87Kdownloads / week

Description

Summary

@nx/maven and @nx/gradle spawn their project-graph analyzers through a shell and interpolate plugin options read from nx.json straight into the command line. Because a shell parses the whole line, an option value containing shell syntax is executed as a command by any nx command that constructs the project graph. Anyone who clones a hostile repository, or who checks out a pull request that edits nx.json, runs the injected command with their own privileges.

Severity

A victim who runs an ordinary nx command in an attacker-supplied Maven or Gradle workspace gets code execution as themselves. In most such workspaces an attacker who can write nx.json can already run code through the repository's build files (./mvnw, pom.xml, and the Gradle equivalents), so the genuinely new exposure is narrow — for example CI building a fork's pull request where nx.json is writable but the build files are not. We have no evidence of exploitation in the wild.

Affected & Patched Versions

PackageVulnerablePatched
@nx/maven>= 22.0.2, < 22.7.9; >= 23.0.0, < 23.1.222.7.9, 23.1.2
@nx/gradle>= 21.0.0, < 22.7.9; >= 23.0.0, < 23.1.222.7.9, 23.1.2

[!IMPORTANT] Workspaces that register neither @nx/maven nor @nx/gradle in nx.json are unaffected — the vulnerable code only runs from those plugins' graph-construction paths, and no other Nx plugin shares this pattern.

Remediation

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

nx migrate 23.1.2

Upgrade both nx and the affected plugin (@nx/maven and/or @nx/gradle). The plugin's fix depends on code that ships in the nx package, so bumping the plugin without a matching nx upgrade will not resolve it.

There is no configuration to change — upgrading is the whole fix. If you cannot upgrade yet, only run nx commands in repositories you trust, since a malicious nx.json can execute code on a vulnerable version.

Details

Both plugins spawn their analyzer through a shell and interpolate nx.json plugin options into the command, so those option values are shell source. For Maven the injectable value is the targetNamePrefix option; for Gradle it is broader, since every plugin option is mapped into a -P argument and arbitrary option names are accepted, making both the name and value of any option injectable.

Credits

  • Arkadiusz Marta (RE:SOURCE) — Reporter

Affected Packages

4 total 4 fixed
EcosystemPackageVulnerable rangeFix
📦npm@nx/maven≥ 22.0.2&&< 22.7.922.7.9npm install @nx/maven@22.7.9
📦npm@nx/maven≥ 23.0.0&&< 23.1.223.1.2npm install @nx/maven@23.1.2
📦npm@nx/gradle≥ 21.0.0&&< 22.7.922.7.9npm install @nx/gradle@22.7.9
📦npm@nx/gradle≥ 23.0.0&&< 23.1.223.1.2npm install @nx/gradle@23.1.2

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @nx/maven, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update @nx/maven to 22.7.9 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-qm8w-vx34-5j9j is resolved across your whole dependency graph.

  3. Workarounds

    Stop passing untrusted input into the interpreter or shell: call the affected binary with an argument array rather than a composed command string, reject anything outside a strict allowlist of expected values, and run the component under an account that cannot reach beyond the work it legitimately does.

Frequently Asked Questions

## Summary `@nx/maven` and `@nx/gradle` spawn their project-graph analyzers through a shell and interpolate plugin options read from `nx.json` straight into the command line. Because a shell parses the whole line, an option value containing shell syntax is executed as a command by any `nx` command that constructs the project graph. Anyone who clones a hostile repository, or who checks out a pull request that edits `nx.json`, runs the injected command with their own privileges. ## Severity A victim who runs an ordinary `nx` command in an attacker-supplied Maven or Gradle workspace gets code
O3 Security · Impact-Aware SCA

Is GHSA-qm8w-vx34-5j9j in your dependencies?

Find it across npm, including transitive dependencies.

Scan my dependencies How O3 SCA works
@nx/maven and @nx/gradle have OS command injection…