Docker Docker Desktop Vulnerabilities & Security Advisories
14 advisories tracked · Docker Security (security@docker.com CNA) + NVD · 0 listed in the CISA Known Exploited Vulnerabilities catalog
Every row below is a published Docker advisory that VulniPulse classified as Docker Desktop, with the CVEs, affected and fixed releases and exploitation status the vendor stated. Severity mix: 1 critical, 7 high, 6 medium.
Android app · Google Play
Monitor Docker CVEs from your phone.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 34 official vendor sources and 160+ reviewed platform categories.
Source
Docker Security (security@docker.com CNA) + NVD
Docker Inc. is its own CVE Numbering Authority. VulniPulse ingests Docker's CVEs from the NVD CNA feed (security@docker.com) — Docker Desktop, Docker CLI, Docker Model Runner and Docker Sandboxes — and merges in the open-source engine components that publish under their own project CNAs (Moby, the Docker Engine upstream; BuildKit; containerd) via a subject-anchored NVD keyword feed that drops the heavy 'third-party app runs in a Docker Compose stack' noise. Docker Desktop / Engine is a near-universal part of every developer and homelab stack.
Latest Docker Docker Desktop advisories
Medium [CVE-2026-105452] Docker Sandboxes could forward a client-supplied credential alongside a credential injected by the host egress proxy
Docker Sandboxes could forward a client-supplied credential alongside a credential injected by the host egress proxy. The proxy removed alternate credentials only when their values matched known sentinel values, so untrusted code in an authorized sandbox could supply an unrecognized credential in another supported authentication header. For affected upstream services, this could authenticate the request to an attacker-controlled account and expose data included in the request.
Medium [CVE-2026-101998] Docker Sandboxes could fail open while masking credentials in protected proxy responses
Docker Sandboxes could fail open while masking credentials in protected proxy responses. When a response-body read returned data together with an error, affected handlers could forward unmasked bytes. Code inside an authorized sandbox could use this to recover host-managed OAuth access and refresh tokens or a derived Anthropic API key intended to remain outside the sandbox.
Medium [CVE-2026-105570] Docker Sandboxes compared OAuth token-endpoint hostnames case-sensitively when deciding whether to mask managed credential responses, while request routing treated DNS hostnames case-insensitively
Docker Sandboxes compared OAuth token-endpoint hostnames case-sensitively when deciding whether to mask managed credential responses, while request routing treated DNS hostnames case-insensitively. Untrusted code inside a sandbox could use a case-variant hostname to reach the genuine provider endpoint while bypassing response masking. If a user completed the OAuth flow, the provider's access and refresh tokens could be returned unmasked to the sandbox, exposing host-managed credentials.
Medium [CVE-2026-18171] Docker Sandboxes (sbx) applies the read-only intent of a runtime host mount to the in-guest container bind only: the underlying virtio-fs host-edge grant is added to the sandbox's policy-share allowlist with no access mode
Docker Sandboxes (sbx) applies the read-only intent of a runtime host mount to the in-guest container bind only: the underlying virtio-fs host-edge grant is added to the sandbox's policy-share allowlist with no access mode. The directory stays writable at its shared-export path, so unprivileged code inside the sandbox can derive that path and write to a host directory the operator attached read-only.
Medium [CVE-2026-12539] Docker Sandboxes (sbx) blocks ICMP egress with an authorizer applied only at network-creation time, and does not re-apply it to networks rebuilt from disk when the Docker daemon restarts, so a restart-surviving sandbox forwards ICMP to arbitrary hosts
Docker Sandboxes (sbx) blocks ICMP egress with an authorizer applied only at network-creation time, and does not re-apply it to networks rebuilt from disk when the Docker daemon restarts, so a restart-surviving sandbox forwards ICMP to arbitrary hosts. A workload inside a sandbox, which the threat model treats as untrusted, can therefore defeat the documented ICMP egress block to perform network reconnaissance and exfiltrate data over an ICMP covert channel, regardless of the configured allowlist.
Medium [CVE-2026-12039] Docker Sandboxes (sbx) enforces an HTTP/S-only egress allowlist but does not apply it to DNS resolution: the per-network embedded DNS server forwards any queried name to the host resolver whenever the network is internet-connected, without consulting the policy
Docker Sandboxes (sbx) enforces an HTTP/S-only egress allowlist but does not apply it to DNS resolution: the per-network embedded DNS server forwards any queried name to the host resolver whenever the network is internet-connected, without consulting the policy. A workload inside a sandbox, which the threat model treats as untrusted, can therefore encode data into DNS labels for an attacker-controlled domain and exfiltrate it through a DNS covert channel, bypassing the configured allowlist.