Docker has patched two serious vulnerabilities in its Docker Sandboxes feature for macOS that allowed code running inside a sandbox VM to bypass directory restrictions and gain broad access to the host machine. The flaws were fixed in version 0.42.0 and earlier versions—back to 0.28.0—are affected. Docker rated one issue as Critical and another as High.
What’s the risk and how it happened
The most severe issue, tracked as CVE-2026-77179, involves the virtio-fs component (used for host-to-VM file sharing). On macOS systems running Docker Sandboxes versions 0.28.0 through 0.41.9, malicious or compromised code inside the sandbox can exploit a symlink attack. The guest can replace a parent directory with a symlink and then use the host’s virtio-fs service to reopen a removed file via its saved path—thus escaping the shared “project directory” boundary and reading or modifying any file the host account has access to.
The second flaw, CVE-2026-79994, is ranked High (CVSS 8.7) and concerns the relay service that lets sandbox guests connect to Unix domain sockets inside their workspace. The flaw arises when a socket path is validated against the workspace, but a directory in the path is swapped out with a symlink after the check. The host will then connect to an arbitrary socket outside the workspace, granting potential access to data or other host-side privileges. Versions from 0.37.0 through 0.41.9 are affected; the flaw is not macOS-exclusive.
Who’s at target, what you can do
The Critical danger only applies to macOS hosts, while the High severity Unix-socket issue could potentially affect all platforms. Docker Sandboxes is the environment used to isolate AI coding agents—each agent runs inside its own VM with a shared project directory. If the container or agent is compromised, these issues can allow it to break out of its sandbox entirely.
The vulnerabilities have been fixed in Docker Sandboxes version 0.42.0 (released September 7, 2026), with 0.43.0 being the newest stable release as of September 15.
Until users can upgrade, Docker recommends using “clone mode” when possible and avoiding read-write mounts from host to sandbox. Clone mode mounts the workspace in read-only fashion (excluding untracked files), limiting what the sandboxed VM can modify. Existing sandboxes must be deleted and recreated with the –clone flag.
Disclosure, detection, and mitigation
Docker made its advisory public on September 15, along with the CVE entries. No known exploitation of these flaws has been observed in the wild to date. The U.S. Cybersecurity & Infrastructure Security Agency (CISA) reports no active exploitation and has not listed either vulnerability in its Known Exploited Vulnerabilities catalog.
Security researchers who discovered the issues include Oren Yomtov and Jurre van Bergen. The more serious CVE-2026-77179 was credited to Yomtov, and the second issue, CVE-2026-79994, to van Bergen.
The affected versions and ratings at a glance:
• CVE-2026-77179 (virtio-fs host server): versions 0.28.0 up to 0.42.0 on macOS; rated Critical (CVSS 9.4).
• CVE-2026-79994 (guest-to-host Unix socket relay): versions 0.37.0 up to 0.42.0; rated High.
Analytical angle:These flaws underscore how even with traditional sandboxing and lightweight VMs, shared filesystem mechanisms like virtio-fs and socket relays pose meaningful risk when symlinks or race conditions are involved. As containers and AI agents become more embedded in developer workflows, such misconfigurations offer novel attack vectors. Going forward, teams relying on embedded sandbox environments must verify not just that they run agents in isolation, but that file-sharing and socket connection layers are secure by default. Docker’s move to clone-mode and strict versioning is essential—users should treat upgrades as mandatory, not optional.
