CVE-2025-9164

In Docker Desktop for Windows with the WSL2 backend, an unprivileged Linux container can use 32-bit socketcall to bypass the default seccomp restriction on AF_VSOCK. This can expose host-facing services and Windows files accessible to the logged-in user. The issue affects x86-64 WSL2; LinuxKit-based backends are unaffected.

Docker Desktop before version 4.97.0 could write third-party API keys and OAuth access tokens in cleartext to local application logs and diagnostics bundles due to insufficient IPC payload redaction. An attacker with read access to these files could obtain the credentials; these OAuth tokens are not Docker account tokens. Versions 4.94.0 and 4.95.0 addressed known logging paths, but logs containing credentials can remain after upgrading, and version 4.97.0 fixes the issue and includes cleanup of existing host logs and crash dumps.

Docker Desktop 4.76.0 fixes a VM panic caused by unbounded recursion in the grpcfuse kernel module when deeply nested directories are created on a bind-mounted host folder and a dentry invalidation event is triggered.

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. The --use-api-socket flag adds the mount via HostConfig.Mounts instead of HostConfig.Binds, and ECI enforcement only inspects Binds, allowing the mount to pass unchecked. This grants a container full access to the Docker Engine socket and, if the host user is logged into container registries, their authentication credentials.

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.

In Docker Desktop 4.46.0 with Enhanced Container Isolation (ECI) enabled and the command restrictions feature in use, the restriction configuration was ignored, allowing any command to be executed on the Docker socket. This affects only containers explicitly allowed by the administrator to mount the Docker socket.