Docker Desktop CVE-2026-6406

Local attacker must already have permission to invoke the Docker CLI against Docker Desktop (typically membership in the docker group or interactive desktop session) on a host where Enhanced Container Isolation is enabled and is the control the attacker seeks to bypass - without ECI deployed, no enforcement exists to bypass and the issue is moot. Exploitation specifically requires use of the --use-api-socket flag (or equivalent direct Engine API call populating HostConfig.Mounts rather than HostConfig.Binds), targets Docker Desktop versions prior to 4.59.0, and requires no user interaction or network access. Credential theft as a secondary impact is conditional on the host user having previously authenticated to container registries (docker login).

The CVSS 3.1 base score of 8.8 reflects local attack vector (AV:L), low complexity (AC:L), low privileges (PR:L), no user interaction (UI:N), and a scope change (S:C) with full CIA impact - appropriate given that container escape via Docker socket access yields control over the host Engine. Real-world risk is moderated by the local-access prerequisite: an attacker must already be able to invoke the Docker CLI on the host, so this is primarily a privilege-escalation and ECI-bypass concern for multi-user workstations, shared developer hosts, and environments where ECI is the security boundary between developers and admin-controlled policy. No EPSS score, KEV listing, or POC was provided in the intelligence package, and no public exploit identified at time of analysis; however, vendor self-reporting plus ZDI coordinated disclosure suggests the issue is well-understood internally. The most relevant defenders are enterprises that deployed ECI specifically to constrain Docker socket exposure - for them this is a meaningful policy-bypass that defeats the control they purchased.

A developer on a shared workstation where the admin has enabled Docker Desktop ECI and explicitly disallowed Docker socket mounts runs docker run --use-api-socket ... against a container image of their choice; the API proxy passes the request through because it only inspects Binds, and the container starts with /var/run/docker.sock attached. From inside the container the user issues Engine API calls to launch a privileged container that mounts the host filesystem, and harvests ~/.docker/config.json registry tokens from the host user's login session.