Unbounded recursion in grpcfuse kernel module allows container to crash Docker Desktop VM

Fixed a VM panic caused by unbounded recursion in the grpcfuse kernel module when a container created deeply nested directories on a bind-mounted host folder and triggered a dentry invalidation event. This issue has been fixed in Docker Desktop 4.76.0.

Docker Model Runner container-to-host code execution via unsandboxed trust_remote_code in Python inference backends

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.

Docker Model Runner container-to-host code execution via MLX-LM model_file importlib loading

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.

Docker Desktop Enhanced Container Isolation bypass via --use-api-socket CLI flag

The Docker CLI --use-api-socket flag bypasses Enhanced Container Isolation (ECI) restrictions in Docker Desktop. When ECI is enabled, Docker socket mounts from containers are denied unless explicitly allowed via the admin-settings configuration. However, the --use-api-socket flag adds the Docker socket mount via the HostConfig.Mounts field rather than the HostConfig.Binds field. The ECI enforcement in the Docker Desktop API proxy only inspected Binds, allowing the mount to pass unchecked. This grants a container full access to the Docker Engine socket and, if the host user has logged in to container registries, their authentication credentials. A local attacker with the ability to run Docker CLI commands can exploit this to escape ECI restrictions, access the Docker Engine, and potentially escalate privileges.

Out of bounds read vulnerability in grpcfuse kernel module

An out of bounds read vulnerability in the grpcfuse kernel module present in the Linux VM in Docker Desktop for Windows, Linux and macOS up to version 4.61.0 could allow a local attacker to cause an unspecified impact by writing to /proc/docker entries. The issue has been fixed in Docker Desktop 4.62.0 .

Docker Desktop for Windows Incorrect Permission Assignment Privilege Escalation Vulnerabilities

Docker Desktop for Windows contains multiple incorrect permission assignment vulnerabilities in the installer's handling of the C:\ProgramData\DockerDesktop directory. The installer creates this directory without proper ownership verification, creating two exploitation scenarios: Scenario 1 (Persistent Attack): If a low-privileged attacker pre-creates C:\ProgramData\DockerDesktop before Docker Desktop installation, the attacker retains ownership of the directory even after the installer applies restrictive ACLs. At any time after installation completes, the attacker can modify the directory ACL (as the owner) and tamper with critical configuration files such as install-settings.json to specify a malicious credentialHelper, causing arbitrary code execution when any user runs Docker Desktop. Scenario 2 (TOCTOU Attack): During installation, there is a time-of-check-time-of-use (TOCTOU) race condition between when the installer creates C:\ProgramData\DockerDesktop and when it sets secure ACLs. A low-privileged attacker actively monitoring for the installation can inject malicious files (such as install-settings.json) with attacker-controlled ACLs during this window, achieving the same code execution outcome.

Exposure in Docker Desktop logs of environment variables configured for running containers

Recording of environment variables, configured for running containers, in Docker Desktop application logs could lead to unintentional disclosure of sensitive information such as api keys, passwords, etc. A malicious actor with read access to these logs could obtain sensitive credentials information and further use it to gain unauthorized access to other systems. Starting with version 4.41.0, Docker Desktop no longer logs environment variables set by the user.

Registry Access Management (RAM) policies not applied when sign-in enforcement is configured via a configuration profile

Registry Access Management (RAM) is a security feature allowing administrators to restrict access for their developers to only allowed registries. When a MacOS configuration profile is used to enforce organization sign-in, the RAM policies are not being applied, which would allow Docker Desktop users to pull down unapproved, and potentially malicious images from any registry.

Exposure of system environment variables in Docker Desktop diagnostic logs

System environment variables are recorded in Docker Desktop diagnostic logs, when using shell auto-completion. This leads to unintentional disclosure of sensitive information such as api keys, passwords, etc.  A malicious actor with read access to these logs could obtain secrets and further use them to gain unauthorized access to other systems. Starting with version 4.43.0 Docker Desktop no longer logs system environment variables as part of diagnostics log collection.

Multiple DLL Search Order Hijacking Vulnerabilities in Docker Desktop Installer for Windows

Docker Desktop Installer.exe is vulnerable to DLL hijacking due to insecure DLL search order. The installer searches for required DLLs in the user's Downloads folder before checking system directories, allowing local privilege escalation through malicious DLL placement.This issue affects Docker Desktop: through 4.48.0.

DNS Rebinding vulnerability present when running MCP Gateway in sse or streaming mode

MCP Gateway allows easy and secure running and deployment of MCP servers. In versions 0.27.0 and earlier, when MCP Gateway runs in sse or streaming transport mode, it is vulnerable to DNS rebinding. An attacker who can get a victim to visit a malicious website or be served a malicious advertisement can perform browser-based exploitation of MCP servers executing behind the gateway, including manipulating tools or other features exposed by those MCP servers. MCP Gateway is not affected when running in the default stdio mode, which does not listen on network ports. Version 0.28.0 fixes this issue.

Docker Desktop Docker Plugins Uncontrolled Search Path Element Local Privilege Escalation Vulnerability

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.

OS Command Injection Vulnerability in RAID Manager Storage Replication Adapter

OS Command Injection vulnerability in Hitachi RAID Manager Storage Replication Adapter allows remote authenticated users to execute arbitrary OS commands. This issue affects: Hitachi RAID Manager Storage Replication Adapter 02.01.04 versions prior to 02.03.02 on Windows; 02.05.00 versions prior to 02.05.01 on Windows and Docker.

Information Exposure Vulnerability in RAID Manager Storage Replication Adapter

Information Exposure Through an Error Message vulnerability in Hitachi RAID Manager Storage Replication Adapter allows remote authenticated users to gain sensitive information. This issue affects: Hitachi RAID Manager Storage Replication Adapter 02.01.04 versions prior to 02.03.02 on Windows; 02.05.00 versions prior to 02.05.01 on Windows and Docker.

Expired Personal Access Tokens (PATs) are recorded in Docker Desktop diagnostic logs

Docker Desktop diagnostics bundles were found to include expired Hub PATs in log output due to error object serialization. This poses a risk of leaking sensitive information in exported diagnostics, especially when access denied errors occurred.

runc can be confused to create empty files/directories on the host

runc is a CLI tool for spawning and running containers according to the OCI specification. runc 1.1.13 and earlier, as well as 1.2.0-rc2 and earlier, can be tricked into creating empty files or directories in arbitrary locations in the host filesystem by sharing a volume between two containers and exploiting a race with `os.MkdirAll`. While this could be used to create empty files, existing files would not be truncated. An attacker must have the ability to start containers using some kind of custom volume configuration. Containers using user namespaces are still affected, but the scope of places an attacker can create inodes can be significantly reduced. Sufficiently strict LSM policies (SELinux/Apparmor) can also in principle block this attack -- we suspect the industry standard SELinux policy may restrict this attack's scope but the exact scope of protection hasn't been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The issue is fixed in runc v1.1.14 and v1.2.0-rc3. Some workarounds are available. Using user namespaces restricts this attack fairly significantly such that the attacker can only create inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actual user on the host (such as with rootless containers that don't use `/etc/sub[ug]id`), this in practice means that an attacker would only be able to create inodes in world-writable directories. A strict enough SELinux or AppArmor policy could in principle also restrict the scope if a specific label is applied to the runc runtime, though neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.

Docker Desktop Community Edition before 2.1.0.1 allows local users to gain privileges by placing a Trojan horse docker-credential-wincred.exe file in %PROGRAMDATA%\DockerDesktop\version-bin\ as a low-privilege user, and then waiting for an admin or service user to authenticate with Docker, restart Docker, or run 'docker login' to force the command.

docker: Lack of content verification

Lack of content verification in Docker-CE (Also known as Moby) versions 1.12.6-0, 1.10.3, 17.03.0, 17.03.1, 17.03.2, 17.06.0, 17.06.1, 17.06.2, 17.09.0, and earlier allows a remote attacker to cause a Denial of Service via a crafted image layer payload, aka gzip bombing.

docker-distribution: Does not properly restrict the amount of content accepted from a user

Docker Registry before 2.6.2 in Docker Distribution does not properly restrict the amount of content accepted from a user, which allows remote attackers to cause a denial of service (memory consumption) via the manifest endpoint.

docker: insecure opening of file-descriptor allows privilege escalation

RunC allowed additional container processes via 'runc exec' to be ptraced by the pid 1 of the container. This allows the main processes of the container, if running as root, to gain access to file-descriptors of these new processes during the initialization and can lead to container escapes or modification of runC state before the process is fully placed inside the container.