Docker Sandboxes flaw on macOS patched in version 0.42.0

Docker has disclosed a critical vulnerability in Docker Sandboxes on macOS that allowed malicious code running inside a sandbox to reach files anywhere else on the Mac, and the company has already shipped a fix.

The flaw is tracked as CVE-2026-77179, where CVE stands for Common Vulnerabilities and Exposures, a public identifier given to a security bug so that everyone describes the same problem with the same name. Docker rates it Critical with a CVSS score of 9.4. CVSS is the Common Vulnerability Scoring System, a 0 to 10 scale the industry uses to say how serious a flaw is, so 9.4 sits near the top. It affects Docker Sandboxes versions 0.28.0 up to but not including 0.42.0 on macOS and was fixed in 0.42.0 on September 7. Docker published the CVE records and its security announcement on September 15, eight days after the fixed version appeared, so anyone who installed the update as soon as it was available was protected before the details became public. The escape runs with the rights of the host account that runs the virtual machine, meaning it needs no extra privileges of its own.

Docker Sandboxes is built to run each AI coding agent inside its own small virtual machine, which is a computer simulated in software and kept separate from the real machine, with the project directory shared into it. The code that could break out is whatever runs inside that machine: a coding agent that has been turned against its own user, or anything malicious the agent installs and runs. That is the point that matters, because protecting the host from what an agent does is exactly what the sandbox exists to do, and this flaw was the gap in that protection. Agents install packages and run commands with sudo, which means with administrator rights, inside the virtual machine, and Docker's isolation documentation states that the hypervisor boundary, the layer separating the virtual machine from the machine underneath it, "is the isolation control, not in-VM privilege separation." Docker is saying that it relies on the wall around the virtual machine rather than on permissions inside it.

According to Docker, the escape went through the virtio-fs host server, the host side of the file sharing mechanism between the Mac and the virtual machine, which followed symlinks when it reopened a file that had been removed, using a stored path. A symlink is a small file that acts as a shortcut pointing at another file or folder, and following one is how a program is sent to look somewhere other than where it intended. A guest, meaning whatever runs inside the virtual machine, could replace a parent directory with a symlink and then read or change files as the VMM user, the host account under which the virtual machine monitor, the program that runs the virtual machine, operates, Docker said, "potentially leading to code execution on the host." Code execution on the host means an attacker's program runs on the Mac itself rather than inside the sealed-off machine. Docker's documentation has said since March that symlinks pointing outside the workspace, its name for the shared project directory, are not followed.

The same 0.42.0 release also fixes a second vulnerability, CVE-2026-79994, which Docker rates High with a CVSS score of 8.7. It sits in the relay that allows a sandbox to connect to Unix domain sockets within its authorized workspace. A Unix domain socket is a channel that programs on the same computer use to talk to one another. The relay checked that a socket path was inside the workspace and then reconnected using the path name, and a guest that replaced a directory along that path with a symlink between the check and the connection could make the host connect to any AF_UNIX socket outside the workspace, Docker said, "exposing data or host-side capabilities provided by that socket." In other words, the safety check and the action happened at different moments, and the answer changed in between. That flaw affects versions 0.37.0 through 0.41.9, but not 0.42.0. Docker lists the first flaw as macOS-only yet states no platform for the second, even though Docker Sandboxes runs on macOS, Windows and Linux hosts, so the second may reach further than the first.

Docker has not reported any exploitation of either flaw. CISA's added assessment on the CVE-2026-77179 record lists exploitation as none, and the flaw is not in CISA's Known Exploited Vulnerabilities catalog, a list the agency maintains of flaws attackers are known to have used in real attacks, as of the catalog version released on September 16. The same is true of CVE-2026-79994, whose record also lists exploitation as none and which is likewise absent from that catalog. Exploiting the first flaw requires malicious code to already be running inside the sandbox, which is precisely what a sandbox is designed to contain. Docker credits Oren Yomtov of accomplish.ai with finding CVE-2026-77179 and Jurre van Bergen of ThreatNotify with finding CVE-2026-79994.

The remedy is straightforward. First, update to 0.42.0 or later; as of September 17 the most recent release is 0.43.0, published on September 15. Second, if you cannot update yet, Docker advises using clone mode and avoiding read-write host mounts, which is its recommendation for both flaws.

By default, the sbx run command shares the current directory into the sandbox with read and write access. Clone mode works only when the project is a Git repository, Git being the version control system many developers use to track changes to code, and it is chosen when the sandbox is created, so an existing sandbox has to be removed and created again with the --clone option. Clone mode protects the repository from changes, not from reading. The repository is mounted read-only at /run/sandbox/source, and untracked files such as .env, a common place to keep passwords and API keys, stay readable inside the sandbox, according to Docker's documentation. Anyone treating clone mode as complete protection should know about that limit.

Some details remain undocumented. The 0.42.0 release notes on GitHub and on Docker's documentation site do not name either CVE as of September 17. Among routine fixes they list one for a case where "a sandboxed process could get the daemon to open a host D-Bus transport and execute an arbitrary command on the host," the daemon being the background service that carries out tasks on the host machine and D-Bus a message system that programs on the same computer use to talk to each other, and Docker has not connected that fix to either CVE. The record for CVE-2026-79994 initially listed 0.41.0 as the first fixed version and linked to a 0.41.0 release page that does not exist; Docker corrected both to 0.42.0 about an hour after publishing the record on September 15.

Sandboxed AI agents have been examined for ways out before. In April, Cyera Research Labs described how a prompt-injected coding agent inside a Docker-based sandbox could be tricked into exploiting a separate Docker Eng