CVE-2026-105445 is a critical vulnerability in Docker Hub's account-to-organization conversion feature that allows an authenticated attacker to reassign a personal access token (PAT) they control to another user without requiring token rotation or revocation. This enables the attacker to use the unchanged PAT to authenticate as the recipient user and perform actions such as pulling, pushing, or deleting images within the token's scope, including organization repositories.
Before 4.92.0, Docker Desktop for Windows did not verify the signature of a package supplied to Docker Desktop Installer.exe install -package. An attacker able to provide a crafted package and convince a user to approve the Docker-signed UAC prompt could execute attacker-controlled installer actions as LocalSystem.
CVE-2026-105452 is a medium severity vulnerability in Docker Sandboxes where client-supplied credentials can be forwarded alongside host proxy credentials due to insufficient filtering of authentication headers. This allows untrusted code running in an authorized sandbox to supply unrecognized credentials, potentially leading to authentication as an attacker-controlled account and exposure of sensitive data in requests.
CVE-2026-101998 is a medium severity vulnerability in Docker Sandboxes where the system may fail open when handling protected proxy responses. This occurs if a response-body read returns data along with an error, potentially causing sensitive bytes to be forwarded unmasked. This flaw could allow code running inside an authorized sandbox to access host-managed OAuth tokens or an Anthropic API key that should remain protected outside the sandbox.
CVE-2026-105570 is a medium severity vulnerability in Docker Sandboxes involving improper handling of case sensitivity. The issue arises because OAuth token-endpoint hostnames were compared case-sensitively, while DNS routing is case-insensitive. This discrepancy allowed untrusted sandbox code to bypass response masking by using case-variant hostnames, potentially exposing unmasked OAuth access and refresh tokens if the OAuth flow completed.
Docker Engine classifies a registry hostname as insecure using an any-match DNS check. loadInsecureRegistries() injects 127.0.0.0/8 and ::1/128 as insecure CIDRs by default. isCIDRMatch resolves all of the hostname's addresses and returns true if a single address is in the insecure CIDR list. Because the transport re-dials the hostname rather than the CIDR-matching address, a DNS answer set of one loopback IP plus a non-loopback attacker IP disables certificate verification and enables HTTP fallback for the registry connection.
CVE-2026-92542 is a medium severity vulnerability in Docker Engine related to firewall rules that indiscriminately mark VXLAN datagrams for encryption. Both authentic VXLAN datagrams from the kernel and forged datagrams from user processes are matched, causing any UDP packet sent from the host network namespace that meets certain criteria to be encrypted with overlay-network IPsec parameters. This affects multiple Docker Engine versions prior to 25.0.19, between 26.0.0 and 29.8.2, and some beta versions. The vulnerability has a CVSS 4.0 score of 6.9 and does not have known exploits in the wild. Patch status is not confirmed from the provided data.
CVE-2026-103433 is a medium severity vulnerability in Docker Buildx Bake where missing authorization checks allow untrusted Bake definitions to expose readable files or consume local OCI image layouts improperly. This occurs because expected filesystem read approvals are not requested for certain inputs, potentially allowing unauthorized file access. The issue affects Docker Buildx versions from 0 up to but not including 0.37.2.
CVE-2026-79994 is a high-severity time-of-check to time-of-use (TOCTOU) race condition vulnerability in Docker Sandboxes. It affects the guest-to-host Unix-domain socket relay mechanism, where socket paths are validated but later reconnected using the pathname. An attacker with guest access can exploit the timing gap by replacing an intermediate directory with a symbolic link after validation, causing the host to connect to an unauthorized socket outside the intended shared workspace. This can lead to exposure of sensitive data or host capabilities accessible via the targeted socket.
On macOS, the virtio-fs host server used by Docker Sandboxes improperly follows symlinks when reopening an unlinked file from a stored path. A malicious guest can replace a parent directory with a symlink, escape the shared workspace, and read or modify arbitrary host files as the VMM user, potentially achieving host code execution.
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.
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.
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.
CVE-2026-8936 is a high-severity vulnerability affecting Docker Desktop version 4.33.0. It involves uncontrolled recursion in the grpcfuse kernel module, which can cause a virtual machine panic when a container creates deeply nested directories on a bind-mounted host folder. This triggers a dentry invalidation event leading to the issue. The vulnerability has been fixed in Docker Desktop version 4.76.0.
The MLX inference backend in Docker Model Runner on macOS uses the MLX-LM library, which unconditionally imports and executes arbitrary Python files from model directories via the model_file configuration field in config.json. When a model's config.json specifies a model_file pointing to a Python file, MLX-LM uses importlib to load and execute it with no trust_remote_code gate or equivalent safety check. The MLX backend runs without sandboxing, resulting in arbitrary code execution on the Docker host as the Docker Desktop user.
Any container on the Docker network can trigger this by calling the model-runner.docker.internal API to pull a malicious model from an attacker-controlled OCI registry and request inference.
The vllm-metal inference backend in Docker Model Runner on macOS unconditionally sets trust_remote_code=True when loading model tokenizers, and runs without sandboxing. This causes transformers.AutoTokenizer.from_pretrained() to import and execute arbitrary Python files included in any model pulled from an OCI registry, resulting in arbitrary code execution on the Docker host as the Docker Desktop user when inference is triggered.
Any container on the Docker network can trigger this by calling the model-runner.docker.internal API to pull a malicious model and request inference.
CVE-2026-6406 is a high-severity vulnerability in Docker Desktop version 4.41.0 where the Docker CLI's --use-api-socket flag bypasses Enhanced Container Isolation (ECI) restrictions. This occurs because the ECI enforcement only inspects certain mount fields, allowing a container to gain unauthorized access to the Docker Engine socket and potentially the host user's container registry credentials. A local attacker with Docker CLI access can exploit this to escape ECI restrictions and escalate privileges.
Docker Model Runner (DMR) is software used to manage, run, and deploy AI models using Docker. Prior to version 1.1.25, Docker Model Runner contains an SSRF vulnerability in its OCI registry token exchange flow. When pulling a model, Model Runner follows the realm URL from the registry's WWW-Authenticate header without validating the scheme, hostname, or IP range. A malicious OCI registry can set the realm to an internal URL (e.g., http://127.0.0.1:3000/), causing Model Runner running on the host to make arbitrary GET requests to internal services and reflect the full response body back to the caller. Additionally, the token exchange mechanism can relay data from internal services back to the attacker-controlled registry via the Authorization: Bearer header. This issue has been patched in version 1.1.25. For Docker Desktop users, enabling Enhanced Container Isolation (ECI) blocks container access to Model Runner, preventing exploitation. However, if the Docker Model Runner is exposed to localhost over TCP in specific configurations, the vulnerability is still exploitable.
Docker CLI for Windows searches for plugin binaries in C:\ProgramData\Docker\cli-plugins, a directory that does not exist by default. A low-privileged attacker can create this directory and place malicious CLI plugin binaries (docker-compose.exe, docker-buildx.exe, etc.) that are executed when a victim user opens Docker Desktop or invokes Docker CLI plugin features, and allow privilege-escalation if the docker CLI is executed as a privileged user.
This issue affects Docker CLI: through 29.1.5 and Windows binaries acting as a CLI-plugin manager using the github.com/docker/cli/cli-plugins/manager https://pkg.go.dev/github.com/docker/cli@v29.1.5+incompatible/cli-plugins/manager package, such as Docker Compose.
This issue does not impact non-Windows binaries, and projects not using the plugin-manager code.
Docker Model Runner versions prior to 1.0.16 expose an unauthenticated POST endpoint that allows attackers with network access to inject arbitrary runtime flags to the underlying inference server. This can be exploited to overwrite arbitrary files accessible to the Model Runner process, including critical Docker Desktop VM disk files, potentially destroying containers, images, volumes, and build history. The vulnerability is fixed in Docker Model Runner 1.0.16 and Docker Desktop 4.61.0. A workaround involves enabling Enhanced Container Isolation to block container access to Model Runner, though certain configurations exposing Model Runner over localhost TCP remain vulnerable.