Docker Security Advisories & CVEs
9 advisories tracked · Docker Security (security@docker.com CNA) + NVD · direct feeds checked every minute; rate-limited backstops use a safe source cadence
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 32 official vendor sources and 160+ reviewed platform categories.
Check if your Docker device is affected
Pick your product and enter the exact software release it runs. We match it against the affected/fixed versions in Docker's recent advisories.
Official 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 advisories
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-15792] malicious BuildKit client or frontend could craft a request that could lead to BuildKit daemon crashing with a panic
A malicious BuildKit client or frontend could craft a request that could lead to BuildKit daemon crashing with a panic.
Medium [CVE-2026-15789] custom client can produce such an upload request to the BuildKit daemon that files can escape from the BuildKit-controlled state directory
A custom client can produce such an upload request to the BuildKit daemon that files can escape from the BuildKit-controlled state directory. The client needs to have valid permissions to access the BuildKit control API to issue builds, e.g., bypass authentication, etc.
Medium [CVE-2026-15788] BuildKit's cache mount source= selector on Windows Container on Windows (WCOW) workers does not detect NTFS directory junctions placed inside the cache root
BuildKit's cache mount source= selector on Windows Container on Windows (WCOW) workers does not detect NTFS directory junctions placed inside the cache root. A build authored by an untrusted user on a WCOW-configured BuildKit daemon can read arbitrary host files reachable to the BuildKit daemon process.
Medium [CVE-2026-47262] Docker Engine: containerd is an open-source container runtime
containerd is an open-source container runtime. Versions prior to 1.7.33, 2.0.10, 2.1.9, 2.2.5 and 2.3.2, contain a vulnerability that allows a maliciously crafted image to cause a Denial of Service (DoS) condition. When creating a container from this image, memory exhaustion occurs, leading to an Out Of Memory (OOM) kill of the containerd process. This renders the container runtime API unavailable and can disrupt clients such as the Docker Engine or Kubernetes control-plane components. This issue has been fixed in versions 1.7.33, 2.0.10, 2.1.9, 2.2.5 and 2.3.2.
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.
Medium [CVE-2026-41568] Docker Engine: Moby is an open source container framework
Moby is an open source container framework. In Docker Engine prior to version 29.5.1, Docker Daemon versions 28.5.2 and prior, and Moby Daemon prior to version 2.0.0-beta.14, a race condition during docker cp mount setup allows a malicious container to create empty files or directories at arbitrary absolute paths on the host filesystem. This issue has been patched in Docker Engine version 29.5.1 and Moby Daemon version 2.0.0-beta.14.
Medium [CVE-2026-33997] Moby is an open source container framework
Moby is an open source container framework. Prior to version 29.3.1, a security vulnerability has been detected that allows plugins privilege validation to be bypassed during docker plugin install. Due to an error in the daemon's privilege comparison logic, the daemon may incorrectly accept a privilege set that differs from the one approved by the user. Plugins that request exactly one privilege are also affected, because no comparison is performed at all. This issue has been patched in version 29.3.1.