On this page
Docker shipped Docker Desktop 4.98.0 on Tuesday, Nov 3, and one line in the security notes matters to anyone running Linux containers on a Windows laptop: CVE-2026-112917, where "a container on the WSL 2 backend could bypass the AF_VSOCK restriction." Docker's CVE record says an unprivileged Linux container can do this with the 32-bit socketcall system call, and that it "can expose host-facing services and Windows files accessible to the logged-in user." Docker rates it CVSS 4.0 9.2.
The catch is in the last line of the record. The bug is fully fixed only when you run Docker Desktop 4.98.0 or later and WSL 3.0.3 or later. Docker Desktop 4.98.0 on an older WSL is still affected. Plenty of people will click "Update" in Docker Desktop and stop there.
How to fix
- Update Docker Desktop to 4.98.0 or later (Settings, Software updates, or the installer from the 4.98.0 release notes). Docker rolls releases out gradually and says updates usually reach everyone within a week, so if the in-app updater does not offer 4.98.0 yet, download the installer directly.
- Update WSL to 3.0.3 or later from an admin or normal PowerShell prompt:
The shutdown matters. The WSL 2 VM and its kernel keep running until you stop them, so a new WSL package does nothing for containers that are already up.wsl --update wsl --shutdown - Start Docker Desktop again and confirm both versions (next section).
WSL 3.0.3 is not new. Microsoft released it on Oct 9, 2026, so machines that take WSL updates automatically may already have it. Machines where IT pins WSL, or blocks the Microsoft Store, are the ones that will sit on the old version while showing a patched Docker Desktop.
Check both versions
wsl --version
docker version --format "{{.Server.Platform.Name}}"
docker info --format "{{.KernelVersion}}"You want WSL version: 3.0.3.0 or higher from the first command and Docker Desktop 4.98.0 or higher from the second. WSL 3.0.3 moved its bundled kernel to linux-msft-wsl 6.18.54.1, which is the third reference on the CVE record, so the third command should report 6.18.54.1 or newer. If it reports something older after a wsl --shutdown, look in %UserProfile%\.wslconfig for a kernel= line. A custom kernel set there stays in use no matter which WSL package you install.
Why the default seccomp profile missed it
Docker's default seccomp profile does not ban the socket() call outright. It allows it only for an explicit list of address families, and in the upstream moby default profile family 40, AF_VSOCK, is not on that list. On WSL 2, AF_VSOCK is the socket type for talking between the Linux VM and the Windows host, so keeping containers away from it is part of what keeps a container inside the VM.
The same profile allows socketcall with no argument checks, and on x86-64 it also covers 32-bit x86 programs. socketcall is the old 32-bit entry point that multiplexes every socket operation through one call, with the real arguments passed in a block of memory. Seccomp filters only see the raw register values, not memory behind a pointer, so the filter has no way to read the address family. A 32-bit program inside the container can ask for an AF_VSOCK socket through socketcall and the family allowlist never gets a say.
Docker's notes do not say how 4.98.0 closes the gap or exactly why it depends on WSL 3.0.3. The 6.18.54.1 kernel notes list "Bpf LSM is enabled by default," which would let a fix filter at the socket layer instead of at syscall entry. That is our reading of the release notes, not something Docker has stated.
Who should care most: agents and dev containers on Windows
The CVSS vector needs low privileges and local access, which in practice means someone already running code inside one of your containers. On a developer laptop that is a normal Tuesday. Dev containers run npm install and pip install from whatever a lockfile points at. AI coding agents are often told "go wild, you are in a container" and then run commands from a README, an issue, or a web page they just read. Sandbox tools for agents frequently boil down to "start a Docker container on the developer's machine."
All of those setups assume the container is the wall. On Windows with the WSL 2 backend and an old WSL, the record says that wall had a hole aimed at the Windows side: host-facing services and the Windows files the logged-in user can read. For a developer, those files tend to include source checkouts, cloud CLI config and SSH keys. If you let an agent or an untrusted install script run in Docker Desktop on Windows, this is the machine to update first.
Who is not in scope
- Docker Desktop on Mac and on Linux. The record names Docker Desktop for Windows with the WSL 2 backend only.
- Docker Desktop on Windows with a LinuxKit-based backend, such as the Hyper-V backend. Docker says LinuxKit-based backends are unaffected.
- Windows on ARM. The record says the issue affects x86-64 WSL 2.
- Docker Engine on Linux servers and CI runners. Nothing in the record or the release notes points at plain Docker Engine.
What this is not
This is not a remote bug. A website or a network scan cannot trigger it. An attacker needs code running inside a Linux container on your Windows machine first. As of publication it is not in the CISA Known Exploited Vulnerabilities catalog, the NVD record is still in "Received" status with no NVD analysis, and we have seen no public exploit or report of exploitation.
If you cannot update today
Keep untrusted code out of Docker Desktop on that machine until both updates land: no agent sandboxes, no dev containers for repos you have not read, no images you would not run directly on Windows. Docker says LinuxKit-based backends are not affected, so if your Docker Desktop version and Windows edition still offer the Hyper-V backend, switching to it is another way out, at the cost of a separate VM and re-pulling your images. Updating WSL is the faster fix for most people.
Docker Desktop 4.98.0 also fixes CVE-2026-98432, a use-after-free in the Linux kernel's IPv4 TCP handling, so the update is worth taking on every platform.
Evidence and sources
The HOL Guard CVE-2026-112917 evidence pack is the source record for this CVE. This post is the operator write-up.
- Docker Desktop 4.98.0 release notes (Nov 3, 2026)
- NVD record for CVE-2026-112917 (CNA: Docker, CVSS 4.0 9.2, CWE-424)
- WSL 3.0.3 release (Oct 9, 2026)
- WSL2 Linux kernel 6.18.54.1 release
- moby default seccomp profile
What do people ask about CVE-2026-112917?
Is updating Docker Desktop to 4.98.0 enough to fix CVE-2026-112917?
No. Docker says 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 running on an older WSL is still affected. Run wsl --update, then wsl --shutdown, then check wsl --version.
Does CVE-2026-112917 affect Docker Desktop on Mac or Linux?
No. The CVE record covers Docker Desktop for Windows with the WSL 2 backend on x86-64. Docker says LinuxKit-based backends are unaffected.
Can CVE-2026-112917 be exploited remotely?
Not directly. The attacker needs code running inside a Linux container on the Windows machine, for example a malicious image, an install script in a dev container, or commands an AI agent runs in a container. It is not in the CISA KEV catalog and there is no known exploitation as of Nov 3, 2026.
What can an attacker reach with CVE-2026-112917?
Docker's CVE record says a container can bypass the default seccomp block on AF_VSOCK, which can expose host-facing services and Windows files accessible to the logged-in user.
How do I check if my machine is still vulnerable?
Run wsl --version and expect 3.0.3.0 or higher, then run docker version and expect Docker Desktop 4.98.0 or higher on the server line. If either is older, you are still affected.
