GHSA-6VC5-VF29-FFR2
Vulnerability from github – Published: 2026-10-05 23:29 – Updated: 2026-10-05 23:29Summary
The @nx/docker release pipeline builds its docker invocations as shell command strings, interpolating release.docker.repositoryName and registryUrl from Nx configuration into them. Because those strings are handed to /bin/sh -c, a crafted repository or registry name executes as a command during nx release version and nx release publish. Anyone running a Docker release against a repository whose Nx configuration they do not control — or whose configuration a pull request has changed — executes the injected command with the privileges of the release job, which in CI typically holds registry credentials and cloud tokens.
Severity
Exploitable when someone runs a Docker release against attacker-supplied configuration, with high impact because release jobs hold publishing credentials. There is no known evidence of exploitation in the wild.
Affected & Patched Versions
| Package | Vulnerable | Patched |
|---|---|---|
@nx/docker |
>= 21.4.0, < 22.7.8; >= 23.0.0, < 23.1.1 |
22.7.8, 23.1.1 |
Every published @nx/docker release before the patched versions is affected.
[!IMPORTANT]
--dry-rundoes not protect you: one of the injected commands runs before the dry-run check, so even a dry-run publish reaches a shell.
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 and requires no configuration change. If you have run nx release version with a configuration you do not trust, delete the generated Docker version file before your next publish, since the composed reference is read back from disk.
Details
Several docker commands in the release pipeline (docker tag during nx release version; the image existence check and docker push during nx release publish) are built as shell command strings with the image reference interpolated in. The reference is composed from the project's release.docker repositoryName and registryUrl, so a value containing shell syntax is executed rather than passed to docker.
Credits
- Arkadiusz Marta (RE:SOURCE) — Reporter
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@nx/docker"
},
"ranges": [
{
"events": [
{
"introduced": "21.4.0"
},
{
"fixed": "22.7.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@nx/docker"
},
"ranges": [
{
"events": [
{
"introduced": "23.0.0"
},
{
"fixed": "23.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-104859"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-05T23:29:13Z",
"nvd_published_at": "2026-10-02T18:17:02Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe `@nx/docker` release pipeline builds its `docker` invocations as shell command strings, interpolating `release.docker.repositoryName` and `registryUrl` from Nx configuration into them. Because those strings are handed to `/bin/sh -c`, a crafted repository or registry name executes as a command during `nx release version` and `nx release publish`. Anyone running a Docker release against a repository whose Nx configuration they do not control \u2014 or whose configuration a pull request has changed \u2014 executes the injected command with the privileges of the release job, which in CI typically holds registry credentials and cloud tokens.\n\n## Severity\n\nExploitable when someone runs a Docker release against attacker-supplied configuration, with high impact because release jobs hold publishing credentials. There is no known evidence of exploitation in the wild.\n\n## Affected \u0026 Patched Versions\n\n| Package | Vulnerable | Patched |\n| --- | --- | --- |\n| `@nx/docker` | `\u003e= 21.4.0, \u003c 22.7.8`; `\u003e= 23.0.0, \u003c 23.1.1` | `22.7.8`, `23.1.1` |\n\nEvery published `@nx/docker` release before the patched versions is affected.\n\n\u003e [!IMPORTANT]\n\u003e `--dry-run` does not protect you: one of the injected commands runs before the dry-run check, so even a dry-run publish reaches a shell.\n\n## Remediation\n\nUpgrade to **22.7.8** (22.x line) or **23.1.1** (23.x line) or later:\n\n```\nnx migrate 23.1.1\n```\n\nThe fix is a drop-in and requires no configuration change. If you have run `nx release version` with a configuration you do not trust, delete the generated Docker version file before your next publish, since the composed reference is read back from disk.\n\n## Details\n\nSeveral `docker` commands in the release pipeline (`docker tag` during `nx release version`; the image existence check and `docker push` during `nx release publish`) are built as shell command strings with the image reference interpolated in. The reference is composed from the project\u0027s `release.docker` `repositoryName` and `registryUrl`, so a value containing shell syntax is executed rather than passed to `docker`.\n \n\n## Credits\n\n- **Arkadiusz Marta** (RE:SOURCE) \u2014 Reporter",
"id": "GHSA-6vc5-vf29-ffr2",
"modified": "2026-10-05T23:29:13Z",
"published": "2026-10-05T23:29:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nrwl/nx/security/advisories/GHSA-6vc5-vf29-ffr2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-104859"
},
{
"type": "WEB",
"url": "https://github.com/nrwl/nx/pull/36505"
},
{
"type": "WEB",
"url": "https://github.com/nrwl/nx/commit/6d60eed061f050e0d5af509a1f5a07c707f09865"
},
{
"type": "WEB",
"url": "https://github.com/nrwl/nx/commit/b587441fd8da28c5db37edb0826554e0060dc81b"
},
{
"type": "PACKAGE",
"url": "https://github.com/nrwl/nx"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "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",
"type": "CVSS_V4"
}
],
"summary": "@nx/docker: OS command injection in the @nx/docker release pipeline"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.