Docker Fixes macOS Sandbox Escape Flaws

A coding agent running inside a Docker Sandboxes virtual machine on macOS is supposed to be walled off from everything beyond its shared project directory. According to Docker's September 15 security announcement, that wall could be crossed: malicious code in the guest could read or modify files anywhere else on the host, operating with the rights of the account running the virtual machine.

The escape undermines the core promise of a sandbox built specifically to contain AI coding agents — the code you don't trust is meant to stay in its own virtual machine. The issue is tracked as CVE-2026-77179 and rated Critical, affecting macOS versions 0.28.0 up to but not including 0.42.0. A fix landed in 0.42.0 on September 7.

What Docker Sandboxes Actually Is

Docker Sandboxes places each AI coding agent in its own small virtual machine, with the project directory shared into that machine. The isolation model assumes that whatever runs inside the VM is untrusted — a coding agent that has been turned against its user, or any malicious package the agent installs and executes.

That design choice is deliberate: the agent installs packages and runs commands with sudo inside the virtual machine, and Docker's isolation documentation states that the hypervisor boundary "is the isolation control, not in-VM privilege separation." In other words, the entire security story rests on the guest not being able to reach the host through the sharing layer.

So far, Docker has not reported any exploitation of the flaw. CISA's assessment on the CVE record lists exploitation as none, and the vulnerability is not in CISA's Known Exploited Vulnerabilities catalog as of the catalog version released on September 16. That absence of exploitation activity does not change the severity of the flaw, but it does mean the flaw was reported and fixed ahead of any known campaign.

The Symlink Path Out of the Sandbox

Docker traced the escape to the virtio-fs host server — the host side of the file sharing between the Mac and the virtual machine. According to Docker, that component followed symlinks when it reopened a removed file from a stored path.

The sequence Docker describes is a classic time-of-check/time-of-use gap. 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 warned this could prove "potentially leading to code execution on the host."

That combination matters because it means the escape was not merely a confidentiality problem. A malicious coding agent that managed to reach the host through this path could, in principle, do more than read files — it could run code under the host account's privileges.

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 advisory effectively states that the implementation of that rule had a gap in the virtio-fs host server, which is what CVE-2026-77179 addresses. The gap does not require the guest to exploit a memory-safety bug or corrupt the hypervisor; it is achieved by manipulating directory entries on the shared filesystem and letting the host-side server follow the resulting symlink.

The constraint is that the flaw needs malicious code inside the sandbox. Protecting the host from what an agent runs is precisely what the sandbox is for, which is why a flaw that lets the guest break that boundary is rated Critical. The attack surface here is not a remote service listening on the network — it is the trust boundary between the agent's VM and the Mac it runs on, exercised through the shared file path.

A Second Flaw in the Socket Relay

The same release fixes a second vulnerability, CVE-2026-79994, rated High by Docker with a CVSS score of 8.7. It lives 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. Docker said 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, "exposing data or host-side capabilities provided by that socket."

This is the same class of race condition as the first bug, applied to a different host-side mechanism. Instead of a file being reopened after removal, the target is a socket connection whose path is validated and then used again. The consequence is that a guest could pivot from an intended in-workspace socket to any Unix domain socket available to the host process.

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 this one, even though 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.

What to Install, and What to Do in the Meantime

Docker's guidance is to update to 0.42.0 or later. As of September 17, the most recent release was 0.43.0, published on September 15. For teams that cannot update immediately, Docker advises using clone mode and avoiding adding read-write host mounts. That advice applies to both flaws.

Clone mode comes with its own constraints. 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. It also 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, according to Docker's documentation.

The practical takeaway for anyone running a sandboxed agent on a Mac is that the shared directory should not be treated as a wall between the agent and the rest of the filesystem. Avoiding read-write host mounts reduces the surface, but clone mode still leaves untracked files readable.

The Record and the Release Notes

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, those notes 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, so it remains an open question whether the release notes describe the same underlying problem in different terms.

There was also a documentation correction: 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. The disclosure timeline — fixes shipped September 7, advisories published September 15 — left a window in which users running affected versions had no public notice of the flaws.

The Broader History of Agent Escape

This is not the first time a Docker-based sandbox has been examined for a path out. 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.

That earlier research and the new CVEs share a theme: the agent inside the sandbox is assumed to be potentially hostile, and the mechanisms meant to keep it contained — file sharing, socket relays, daemon interactions — are where the boundary can fail. Docker's isolation documentation is explicit that in-VM privilege separation is not the control; the hypervisor boundary is. These two CVEs show how much depends on the host-side components that boundary relies on.

For defenders, the relevant question is not whether a coding agent can be prompt-injected, but what it can reach if it is. The September 15 advisory provides a concrete answer for macOS users: without the fix, files outside the shared directory were in scope, along with whatever capabilities the host account held.

Why It Matters for Teams Running Agents

Sandboxes have become the default answer to the risk of autonomous coding agents, and that answer is only as strong as its host-side implementation. A Critical escape in Docker Sandboxes on macOS suggests that teams should track the patch level of the sandboxing layer itself, not just the agent framework or model they run inside it.

The fix is available in 0.42.0 and later, with 0.43.0 already published. Anyone running versions prior to that on a Mac should treat the update as the primary mitigation, and use clone mode with no read-write host mounts only as a stopgap. Because clone mode leaves untracked files like .env readable, teams that keep secrets in the working tree should also consider what those secrets would be worth to code running inside the VM.

The larger implication is structural: as more organizations run AI agents against real repositories, the sandbox boundary becomes production security infrastructure. A flaw that grants host code execution from inside the sandbox is not a minor bug in a developer convenience — it is the failure of the control that makes running untrusted agent code tolerable in the first place.