CVE-2025-13743

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 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.

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.