chore(security): VEX three new compose CVE findings and correct dependency comment (#1201)

Trivy reported three new advisories against the compose binary today:

- CVE-2026-41568 (docker cp symlink-swap empty-file creation, sibling of
  CVE-2026-42306)
- CVE-2026-33997 (Moby plugin install privilege bypass)
- GHSA-pmwq-pjrm-6p5r (in-toto-golang glob-negation operator mismatch)

All three are daemon-side or supply-chain attestation code paths that
compose only embeds as client-side libraries. Sencho invokes compose
exclusively for up/down/ps against user-authored compose files, never
runs daemon endpoints, never performs plugin installation, and never
verifies in-toto attestations. Each gets a not_affected statement with
a full impact rationale; bump version 7 to 8 and last_updated to today.

Also correct the compose-builder comment in Dockerfile. The previous
text claimed compose v5.1.3 "eliminated CVE-2026-34040 and CVE-2026-33997
at the dependency level" by moving docker/docker to an indirect dep.
That is wrong: the module is still pulled via buildkit and other
transitive paths, the CVEs still appear in scans, and they are tracked
in the VEX file rather than eliminated. The corrected comment points
the reader at the VEX file as the source of truth for these findings.
This commit is contained in:
Anso
2026-05-24 18:30:39 -04:00
committed by GitHub
parent 0951a0e792
commit c67478b50d
2 changed files with 56 additions and 5 deletions
+9 -3
View File
@@ -135,9 +135,15 @@ RUN cp vendor.mod go.mod && cp vendor.sum go.sum && \
# Stage 4b: Build Docker Compose from source against Go 1.26.3
#
# Compose v5.1.3 removed the direct dependency on github.com/docker/docker
# (replaced by moby/moby/api + moby/moby/client), eliminating CVE-2026-34040
# and CVE-2026-33997 at the dependency level. Rebuilding with the patched Go
# Compose v5.1.3 moved github.com/docker/docker from a direct require to an
# indirect dep (the direct surface is now moby/moby/api + moby/moby/client),
# but the docker/docker module is still pulled into the binary via buildkit
# and other transitive paths. Several daemon-side CVEs against docker/docker
# v28.5.2 (CVE-2026-34040, CVE-2026-33997, CVE-2026-41567, CVE-2026-41568,
# CVE-2026-42306) therefore still appear in scans of the compose binary;
# they are tracked as not_affected in security/vex/sencho.openvex.json
# because compose is the client and the vulnerable code paths are reached
# only by Docker Engine the daemon. Rebuilding with the patched Go
# toolchain eliminates Go stdlib CVEs from the binary's SBOM.
#
# Compose v5.1.3 still bundles otel/sdk v1.42.0 transitively via buildkit
+47 -2
View File
@@ -4,8 +4,8 @@
"author": "Studio Saelix",
"role": "Vendor",
"timestamp": "2026-05-18T00:00:00Z",
"last_updated": "2026-05-24T00:00:00Z",
"version": 7,
"last_updated": "2026-05-24T12:00:00Z",
"version": 8,
"statements": [
{
"vulnerability": {
@@ -51,6 +51,51 @@
"status": "not_affected",
"justification": "vulnerable_code_not_in_execute_path",
"impact_statement": "The race condition is in the Docker Engine daemon-side bind-mount resolution path that backs `docker cp`, where a concurrent rename can redirect a copy operation onto a host path. docker-compose v5.1.3 statically bundles docker/docker v28.5.2+incompatible as a client-side library for API types and codecs; it never serves the daemon-side cp endpoint and never resolves bind mounts on the host. Sencho invokes compose only for up/down/ps operations against local user-authored compose files and does not invoke `docker cp` through compose. The vulnerable daemon-side code path is not reachable. The fix lives on the github.com/moby/moby/v2 module path; until upstream compose migrates to the v2 import path, v28.5.2+incompatible is the only Go-module-resolvable version of the affected library that compose can reference."
},
{
"vulnerability": {
"@id": "https://www.cve.org/CVERecord?id=CVE-2026-41568",
"name": "CVE-2026-41568",
"description": "Docker: Race condition in docker cp allows creation of arbitrary empty files on the host via symlink swap"
},
"products": [
{
"@id": "pkg:golang/github.com/docker/docker@v28.5.2+incompatible"
}
],
"status": "not_affected",
"justification": "vulnerable_code_not_in_execute_path",
"impact_statement": "Sibling advisory to CVE-2026-42306. The vulnerable code is the Docker Engine daemon-side `docker cp` path, where a concurrent symlink swap during archive extraction can cause the daemon to create arbitrary empty files on the host filesystem. docker-compose v5.1.3 statically bundles docker/docker v28.5.2+incompatible as a client-side library for API types and codecs; it never serves the daemon-side cp endpoint and never performs archive extraction on the host. Sencho invokes compose only for up/down/ps operations against local user-authored compose files and does not invoke `docker cp` through compose. The vulnerable daemon-side code path is not reachable. The fix lives on the github.com/moby/moby/v2 module path; until upstream compose migrates to the v2 import path, v28.5.2+incompatible is the only Go-module-resolvable version of the affected library that compose can reference."
},
{
"vulnerability": {
"@id": "https://www.cve.org/CVERecord?id=CVE-2026-33997",
"name": "CVE-2026-33997",
"description": "Moby: Privilege validation bypass during plugin installation"
},
"products": [
{
"@id": "pkg:golang/github.com/docker/docker@v28.5.2+incompatible"
}
],
"status": "not_affected",
"justification": "vulnerable_code_not_in_execute_path",
"impact_statement": "The vulnerability is in Docker Engine's daemon-side plugin installation flow, where a crafted plugin manifest can bypass capability validation and grant the plugin elevated privileges at install time. docker-compose v5.1.3 statically bundles docker/docker v28.5.2+incompatible as a client-side library for API types and codecs; it never serves the daemon plugin endpoints and never executes plugin installation logic. Sencho invokes compose only for up/down/ps operations against local user-authored compose files and never installs Docker plugins through compose. The daemon-side plugin installation handler is not reachable. The fix lives on the github.com/moby/moby/v2 module path; until upstream compose migrates to the v2 import path, v28.5.2+incompatible is the only Go-module-resolvable version of the affected library that compose can reference."
},
{
"vulnerability": {
"@id": "https://github.com/advisories/GHSA-pmwq-pjrm-6p5r",
"name": "GHSA-pmwq-pjrm-6p5r",
"description": "in-toto-golang and in-toto-python use inconsistent negation operators in artifact rule glob patterns"
},
"products": [
{
"@id": "pkg:golang/github.com/in-toto/in-toto-golang@v0.10.0"
}
],
"status": "not_affected",
"justification": "vulnerable_code_not_in_execute_path",
"impact_statement": "The vulnerability is a glob-negation operator mismatch (`^` in in-toto-golang versus `!` in in-toto-python) that can cause an in-toto layout authored against one implementation to evaluate differently in the other. It manifests only when a supply-chain attestation layout authored with one in-toto implementation is then verified with another in the same pipeline. in-toto-golang v0.10.0 enters compose's module graph transitively through the SLSA/attestation verification helpers in buildkit and sigstore-go. Compose only invokes those helpers when verifying image attestations during `docker compose build` or pull-with-verification flows. Sencho invokes compose only for `up`, `down`, and `ps` against pre-built images on local user-authored compose files; it does not invoke `compose build`, does not perform image attestation verification, and does not author or evaluate in-toto layouts. The vulnerable glob-evaluation code path is not reached. Fixed in in-toto-golang v0.11.0; pending an upstream compose tag that pulls the bump, the v0.10.0 module remains in compose v5.1.3's graph."
}
]
}