Docker Sandboxes Flaw Lets Guest Code Reach macOS Host Files
Docker has disclosed two vulnerabilities in Docker Sandboxes, the tool that runs each AI coding agent inside its own lightweight virtual machine with a project directory shared in. The more serious of the two, CVE-2026-77179, is rated Critical with a CVSS score of 9.4 and allows malicious code running inside the sandbox to escape the shared project directory and read or modify files anywhere else on the macOS host. The escape executes with the privileges of the host account running the virtual machine monitor, and the vendor notes it could potentially lead to code execution on the host. Affected versions run from 0.28.0 up to but not including 0.42.0 on macOS, with the fix shipping in 0.42.0 on September 7 and the advisory and CVE records published on September 15. A second issue, CVE-2026-79994, is rated High with a CVSS score of 8.7 and affects versions 0.37.0 through 0.41.9.
The Critical flaw sits in the virtio-fs host server, the host side of the file sharing bridge between the Mac and the guest virtual machine. According to the vendor, that component followed symbolic links when it reopened a removed file from a previously stored path. Code inside the guest could replace a parent directory with a symlink and then have the host component resolve that link, giving it read and write access to files outside the workspace as the VMM user. The second flaw follows a similar pattern in the relay that lets a sandbox connect to Unix domain sockets inside its authorised workspace. The relay validated that a socket path was inside the workspace and then reconnected using the path name, so a guest that swapped a directory along that path for a symlink between the check and the connection could force the host to connect to any AF_UNIX socket outside the workspace, exposing data or host side capabilities behind it. Both issues are classic time of check to time of use weaknesses, and both require that something malicious is already executing inside the sandbox, which is precisely the scenario the product exists to contain.
The strategic significance here is about trust boundaries in agentic AI workflows rather than mass exploitation. Docker Sandboxes gives a coding agent broad freedom inside the virtual machine, including installing packages and running commands with sudo, on the stated assumption that the hypervisor boundary is the isolation control rather than in VM privilege separation. When that boundary leaks, a prompt injected or otherwise subverted agent, or any malicious dependency it pulls in, moves from a disposable sandbox to a developer workstation holding source code, credentials and SSH keys. Prior research has already demonstrated a prompt injected agent inside a Docker based sandbox being steered into attacking its own host through a separate engine flaw, so the abuse path is not theoretical. On current exploitation status, Docker has reported no exploitation, CISA's assessment on both CVE records lists exploitation as none, and neither CVE appears in the Known Exploited Vulnerabilities catalog as of the September 16 catalog version. FIRST EPSS puts the probability of exploitation in the next 30 days at 0.2 percent for CVE-2026-77179 and 0.1 percent for CVE-2026-79994. Disclosure hygiene is worth noting for tracking purposes. The advisory arrived eight days after the fixed build shipped, the 0.42.0 release notes do not name either CVE, and the record for CVE-2026-79994 initially listed a non existent 0.41.0 fix before being corrected. Separately, those release notes mention a fix for a sandboxed process getting the daemon to open a host D-Bus transport and execute an arbitrary command on the host, which Docker has not linked to either CVE, leaving defenders with limited mapping between build numbers and specific security fixes.
Attack Surface
Endpoint, Endpoint OS, Infrastructure
Tactics
Privilege Escalation, Defense Evasion, Execution, Collection, Impact
Techniques
- T1611 – Escape to Host
- T1068 – Exploitation for Privilege Escalation
- T1005 – Data from Local System
- T1565 – Data Manipulation
- T1083 – File and Directory Discovery
SuperPRO's Threat Countermeasures Procedures
- Upgrade Docker Sandboxes to 0.42.0 or later on all macOS developer machines; 0.42.0 shipped September 7 and fixes both CVE-2026-77179 in the virtio-fs host server and CVE-2026-79994 in the guest to host Unix socket relay. Version 0.43.0, published September 15, is the most recent release.
- Treat any host running Docker Sandboxes 0.28.0 through 0.41.9 as affected and inventory installs by version, since the 0.42.0 release notes do not name either CVE and cannot be used to confirm the fix is present.
- Where upgrading is not yet possible, follow Docker's workaround for both flaws by recreating sandboxes in clone mode with sbx run –clone. Clone mode only works on Git repositories and is fixed at creation time, so existing sandboxes must be removed and recreated.
- Stop adding read write host mounts to sandboxes; by default sbx run shares the current directory into the sandbox with read and write access, which is the pivot point the virtio-fs symlink escape abuses.
- Remember clone mode protects the repository from modification but not from reading, as it mounts the repo read only at /run/sandbox/source while untracked files such as .env remain readable inside the sandbox. Move API keys and .env secrets out of any directory shared with a sandbox and into an external secret store.
- Run the sbx or VMM host process under a dedicated low privilege macOS account rather than a developer's primary or admin account, because the escape executes with the rights of the host account running the virtual machine.
- Add endpoint monitoring for the behaviours behind these bugs: symlinks replacing parent directories inside a shared workspace, file writes by the VMM user outside the shared project path, and host side AF_UNIX socket connections initiated by the sandbox relay to socket paths outside the authorised workspace. Also alert on the 0.42.0 fixed behaviour of a sandboxed process driving the daemon to open a host D-Bus transport.
