Malicious code running inside a Docker Sandboxes virtual machine on macOS could escape the project directory shared into it and read or change files anywhere else on the host, Docker warns in a security announcement on September 15.
The escape runs with the rights of the host account that runs the virtual machine. The flaw, CVE-2026-77179, is rated Critical, affects 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 Sandboxes runs each AI coding agent in its own small virtual machine with the project directory shared in. The code that could escape is whatever runs inside that machine, such as a coding agent that has been turned against its user, or anything malicious the agent installs and runs.
Docker has not reported any exploitation. CISA’s added assessment on the CVE record lists exploitation as none, and the flaw is not in CISA’s Known Exploited Vulnerabilities catalog as of the catalog version released on September 16.
The flaw needs malicious code inside the sandbox, and protecting the host from what an agent runs is what the sandbox is for. The agent installs packages and runs commands with sudo inside the virtual machine, and Docker’s isolation documentation says the hypervisor boundary “is the isolation control, not in-VM privilege separation.”
The escape goes through the virtio-fs host server, the host side of the file sharing between the Mac and the virtual machine, which followed symlinks when it reopened a removed file from a stored path, Docker said.
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 runs, Docker said, “potentially leading to code execution on the host.”
Docker’s documentation has said since March that symlinks pointing outside the workspace, Docker’s term for the shared project directory, are not followed.
The same release fixes a second flaw, CVE-2026-79994, rated High by Docker with a CVSS score of 8.7, in the relay that allows a sandbox to connect to Unix domain sockets within its authorized workspace.
The relay checked that a socket path was inside the workspace, then reconnected using the path name. 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.”
That flaw affects versions 0.37.0 through 0.41.9, but not 0.42.0. Docker lists the first flaw as macOS-only but states no platform for it, whereas Docker Sandboxes runs on macOS, Windows, and Linux hosts. CISA’s assessment on its record also lists exploitation as none, and it is not in the KEV catalog either.
Affected Versions and What to Install
| CVE | Component | Affected versions | Platform | Docker rating |
|---|---|---|---|---|
| CVE-2026-77179 | virtio-fs host server | 0.28.0 up to but not including 0.42.0 | macOS | Critical, CVSS 9.4 |
| CVE-2026-79994 | Guest-to-host Unix socket relay | 0.37.0 up to but not including 0.42.0 | None stated | High, CVSS 8.7 |
- Update to 0.42.0 or later. As of September 17, the most recent release is 0.43.0, published on September 15.
- If you cannot update yet, use clone mode and avoid adding read-write host mounts. That is Docker’s advice for both flaws.
By default, sbx run shares the current directory into the sandbox with read and write access. Clone mode works only when the project is a Git repository, and it is set when the sandbox is created, so an existing sandbox has to be removed and created again with –clone.
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 stay readable inside the sandbox, Docker’s documentation says.
Docker published the CVE records and the advisory on September 15, eight days after 0.42.0 shipped.
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 sandboxed process could get the daemon to open a host D-Bus transport and execute an arbitrary command on the host.” 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.
Docker credits Oren Yomtov of accomplish.ai with finding CVE-2026-77179 and Jurre van Bergen of ThreatNotify with finding CVE-2026-79994.
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 Engine flaw against its host.
