Docker Desktop EUVD-2026-116144

Requires Docker Desktop for Windows running the WSL2 backend on x86-64, and the ability to execute code inside an unprivileged Linux container on that host (PR:L - not remote-unauthenticated). The concrete trigger named in the source is the use of the 32-bit socketcall multiplexer syscall to evade the default seccomp profile's restriction on AF_VSOCK, after which host-facing services and Windows files accessible to the logged-in user are reachable. LIMITING FACTORS: LinuxKit-based Docker Desktop backends are explicitly unaffected; the issue is specific to x86-64 WSL2. Remediation is only complete when BOTH Docker Desktop 4.98.0+ and WSL 3.0.3+ are present - Docker Desktop 4.98.0+ on an older WSL remains affected per the vendor description.

This is a genuine high-priority issue rather than a CVSS-inflated one, but the severity is driven by impact (container-to-host sandbox escape) and not by ease of remote reach. The vendor CVSS 4.0 score of 9.2 is built on AV:L/AC:L/AT:N/PR:L/UI:N with high vulnerable- and subsequent-system confidentiality/integrity impact (VC:H/VI:H/SC:H/SI:H, VA:N/SA:N), which is internally consistent with the description: a local, low-privileged actor already running a container breaks out of the seccomp sandbox to reach the host and the logged-in Windows user's files. The vuln.today decision label is act_now, which should drive remediation urgency. However, the signals are not uniformly alarming: there is no EPSS probability provided, the CVE is not listed in CISA KEV, and no PoC or exploit reference appears in the input, so there is no public exploit identified at time of analysis. The practical gating factor is that the attacker must first be able to execute code inside a container on an affected Windows WSL2 host, so this is primarily a privilege-boundary/defense-in-depth failure (malicious or compromised container image, multi-tenant build environment) rather than an internet-facing remote threat. One nuance security teams must weigh: Docker Desktop 4.98.0 alone does NOT fully fix this - the host also needs WSL 3.0.3 or later; a patched Docker Desktop on an older WSL remains vulnerable, which is a common misremediation trap.

A developer or CI runner pulls and runs a malicious or compromised image as an ordinary (unprivileged) container on Docker Desktop for Windows with the WSL2 backend. Code inside that container issues 32-bit socketcall calls to evade the default seccomp block on AF_VSOCK, opening vsock channels to host-facing services and reading Windows files accessible to the logged-in user. Exploitation is local and low-complexity (AV:L/AC:L) but requires the attacker to already run container code; no public exploit was identified at time of analysis.