Docker Desktop 4.13 shipped on October 13, 2022, and the release quietly reset the Windows container security posture by hardening the WSL2 backend against two classes of attack — container escape via the docker.sock proxy and privilege escalation from the WSL2 distribution into the host. The hardening followed a year of CVE disclosures: CVE-2022-26659 (privilege escalation via dockerDesktopLinuxEngine), CVE-2022-25365 (arbitrary file write on install), CVE-2022-31647 (Windows service local privilege escalation), and CVE-2022-34292 (same class, different path). Docker also introduced Enhanced Container Isolation (ECI) in Docker Desktop 4.13 as a preview feature, which ran user containers inside a rootless, user-namespaced sub-engine that prevented most container-break-out primitives from reaching the host. For developer shops on Windows — now the majority of enterprise developer environments — these changes were the difference between treating the dev laptop as a high-trust endpoint and treating it as a build sandbox. This post walks through the defects, the fixes, and what enterprise teams should change in 2022 configurations.
Why did Docker Desktop need so many CVEs fixed in 2022?
Docker Desktop needed multiple CVEs fixed because its Windows service model — a privileged Docker Desktop Service running as SYSTEM, brokering IPC between the WSL2 distribution and the Windows host — offered several sensitive attack surfaces that had accumulated over the product's rapid growth. The pattern across CVE-2022-26659, -25365, -31647, and -34292 was consistent: a named-pipe or IPC endpoint reachable from a local user context processed requests that effectively executed code as SYSTEM or wrote files to privileged locations. Each CVE was individually straightforward — one was a TOCTOU in file-path handling during install, another was insufficient validation on the Docker Desktop Linux Engine IPC — but collectively they reflected that the broker layer had been added iteratively without a unified threat model. 2022 is when Docker engineering rewrote portions of the broker with explicit validation and moved elevation-prone paths behind a Windows-authenticated gate.
What exactly is Enhanced Container Isolation?
Enhanced Container Isolation is a Docker Desktop feature that runs user containers inside a user-namespaced, rootless sub-engine (sysbox under the hood) rather than as the equivalent of root on the underlying Docker daemon. The effect is that a container process that would otherwise be UID 0 inside the container and UID 0 inside the daemon's mount namespace is now mapped to an unprivileged UID on the host-side WSL2 distro. A docker run --privileged still confers capabilities inside the container, but escape primitives (CAP_SYS_ADMIN abuse, /proc traversals, device mounts) no longer reach the host because the daemon itself does not have those capabilities. ECI also bind-mounts /var/run/docker.sock read-only, disables several unsafe default mounts, and restricts kernel-keyring access. In 4.13 it was a preview; by 4.21 (June 2023) it was production and recommended for any laptop that runs untrusted images.
How did the old WSL2 model allow lateral movement?
The old WSL2 model allowed lateral movement because the docker-desktop WSL2 distribution shared a file system space with the Windows host, and several Docker Desktop features (volumes, credential helpers, the settings broker) accessed Windows paths via /mnt/c/Users/<user>/.... A container running as root inside the daemon's namespace could, in certain configurations, write to mounted Windows paths owned by the user. Combined with a CVE in the Windows broker — for example CVE-2022-31647 — that gave an attacker in a container a path to SYSTEM: drop a malicious DLL in a location the broker reloaded, wait for the broker to reload. The 2022 fixes closed these paths by hardening broker validation, denying writes from the WSL2 sandbox into most Windows host locations, and — with ECI — preventing the container from being root in the daemon namespace in the first place.
What must enterprise admins configure for Docker Desktop in 2022?
Enterprise admins must configure Docker Desktop through the admin-settings.json file — introduced in Docker Desktop 4.13 for Business subscribers — to enforce: ECI enabled, extensionsEnabled: false unless explicitly needed, image access management restricted to approved registries, and mandatory signed image enforcement. An example:
{
"configurationFileVersion": 2,
"enhancedContainerIsolation": { "value": true, "locked": true },
"extensionsEnabled": { "value": false, "locked": true },
"allowedOrgs": { "value": ["your-corp"], "locked": true },
"containersProxy": {
"override": { "mode": "manual", "http": "", "https": "" },
"locked": true
}
}
Deploy admin-settings.json to %ProgramData%\DockerDesktop\admin-settings.json via MDM or Group Policy. The locked: true flag prevents users from overriding the setting locally. This is the first version of Docker Desktop where enterprise configuration is meaningfully enforceable; prior to 4.13 most settings were per-user and adjustable.
What about the Docker daemon socket attack surface?
The Docker daemon socket is still the highest-value target on any developer laptop that runs untrusted code, and the 2022 changes mitigated rather than eliminated the risk. The canonical attack — a container that mounts /var/run/docker.sock and launches a privileged sibling container — remains possible whenever a developer runs docker run -v /var/run/docker.sock:/var/run/docker.sock .... ECI narrows the impact (the resulting privileged container is still rootless relative to the host), but a malicious image that encrypts the developer's ~/src and drops a ransom note does not need to escape to the Windows host to cause pain. Enterprise policy should block socket-mounting containers by default, and developer workflows that require Docker-in-Docker (Testcontainers, kind, etc.) should move to rootless modes. Testcontainers 1.18 added ECI compatibility in late 2022 for exactly this reason.
What is the durable security model for Docker Desktop now?
The durable security model treats the WSL2 distribution as the trust boundary and Docker Desktop's broker as the narrow-waist IPC that must be validated like any other cross-trust-domain call. The model assumes the developer will run untrusted images. The WSL2 distro and the daemon inside it are sandboxes, not trusted execution contexts. Production credentials must not sit in the WSL2 home directory without at least ~/.docker/config.json credential-helper integration that keeps secrets in Windows Credential Manager. Registry pulls should be routed through a signed-image verification step (Notary v2 / Notation, now that ACR and ECR support it). Egress from the WSL2 distro should be monitored, especially during build steps, because a compromised base image running as part of docker build has the same blast radius as any other build-time compromise.
How Safeguard Helps
Safeguard scans your container base images and developer laptop registries continuously, correlating CVE exposure to the Docker Desktop version in use and flagging configurations where ECI is disabled or admin-settings.json is unset. Reachability analysis highlights which containers in your ecosystem mount docker.sock, run privileged, or depend on base images with known broker-abuse primitives. Griffin AI answers ad-hoc questions like "which of my images would benefit from ECI" and generates rollout plans for admin-settings.json across device fleets. SBOM comparisons between base image versions surface undocumented toolchain changes in updates. Policy gates block CI builds that ship images requiring privileged flags without documented justification, closing the attack surface at the source rather than on the laptop.