diff --git a/Dockerfile b/Dockerfile
index aa889283..87a483f0 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -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
diff --git a/security/vex/sencho.openvex.json b/security/vex/sencho.openvex.json
index 4d598586..444276db 100644
--- a/security/vex/sencho.openvex.json
+++ b/security/vex/sencho.openvex.json
@@ -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."
     }
   ]
 }