CVE-2026-112917 in Dockerinfo

Summary

by MITRE • 11/03/2026

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. The issue is fully fixed only with Docker Desktop 4.98.0 or later and WSL 3.0.3 or later. Docker Desktop 4.98.0 or later running on an older WSL remains affected.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 11/03/2026

The vulnerability in question represents a significant security flaw within the architecture of Docker Desktop for Windows when operating with the Windows Subsystem for Linux version two backend, specifically targeting x86-64 systems. This issue stems from how the container runtime interacts with the underlying hypervisor and network stack to facilitate communication between guest containers and the host environment. The core technical flaw involves an improper restriction enforcement mechanism regarding address family types, particularly AF_VSOCK which is designed for virtual socket communications typically used in VM environments. By leveraging a specific system call behavior inherent to 32-bit architectures on x86-64 processors, unprivileged Linux containers are able to execute the socketcall syscall with arguments that effectively bypass the default seccomp filters applied by Docker. Seccomp is a critical security feature designed to restrict the set of system calls available to processes within a container, thereby limiting the potential attack surface and preventing privilege escalation or unauthorized access to host resources.

The exploitation mechanism relies on the fact that 32-bit applications running on a 64-bit kernel often use the socketcall syscall as an entry point for various network-related operations, including those associated with AF_VSOCK. While Docker Desktop attempts to block direct usage of AF_VSOCK through its default seccomp profile to prevent containers from directly accessing host-facing services and Windows file systems via virtual sockets, this specific bypass technique allows the container runtime to circumvent these restrictions. This occurs because the filtering logic did not adequately account for the translation layer required when 32-bit syscalls are invoked on a 64-bit kernel environment within WSL2. Consequently, an attacker who has gained access to an unprivileged Linux container can establish virtual socket connections that bridge the isolation boundary between the guest OS and the host Windows operating system.

The operational impact of this vulnerability is severe due to the broad scope of resources exposed through AF_VSOCK. Once the seccomp restriction is bypassed, the compromised container gains the ability to interact with services running on the host machine as well as access files within the user profile directory accessible to the logged-in Windows user. This effectively breaks the fundamental security model of containerization which relies on strong isolation between guest and host environments. An adversary could potentially exfiltrate sensitive data from the host file system, intercept network traffic intended for local services, or use the compromised container as a pivot point for further attacks against other systems within the same network segment if those services are exposed via virtual sockets. This level of access undermines trust in isolated development and deployment environments where containers are expected to remain strictly confined unless explicitly granted additional privileges through secure mechanisms like Docker volumes with specific mount options rather than raw socket access.

This vulnerability is classified under CWE-250 which refers to execution with unnecessary privileges, as the container process achieves a level of access beyond what its assigned permissions should allow due to an implementation error in the security controls. Furthermore it aligns with MITRE ATT&CK techniques related to lateral movement and defense evasion such as T1610 Drop or Implant Objects on File System if used for persistence or T1572 Protocol Tunneling if leveraged to exfiltrate data through disguised network channels. It is important to note that this issue specifically affects the x86-64 WSL2 backend implementation and does not impact LinuxKit-based backends which utilize different architectural approaches to container isolation and networking. The vulnerability remains present in Docker Desktop versions prior to 4.98.0 regardless of whether they are paired with older or newer versions of WSL, indicating that the fix requires coordinated updates across both components.

To mitigate this risk organizations must ensure that all endpoints running Docker Desktop for Windows are updated to version 4.98.0 or later and simultaneously upgraded to WSL version 3.0.3 or later. Running a patched version of Docker Desktop on an older, unpatched instance of WSL will leave the system vulnerable as both components must enforce the corrected security policies in tandem. Administrators should verify their current versions through standard diagnostic commands within the container runtime and operating system shell respectively before deploying any new workloads that require network isolation guarantees. Additionally until all systems are fully patched it is advisable to restrict untrusted or third-party containers from running with elevated networking capabilities and to monitor for unusual outbound connections originating from Linux containers using host monitoring tools capable of detecting virtual socket activity patterns indicative of this specific bypass technique.

Responsible

Docker

Reservation

10/19/2026

Disclosure

11/03/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you know our Splunk app?

Download it now for free!