Security1 publisher2 min readPublished
CVE-2026-77179 let sandboxed agent code write anywhere the macOS host account could
Docker shipped the fix in Sandboxes 0.42.0 on September 7 and published the advisory on September 15. Every macOS build from 0.28.0 through 0.41.x is affected, and the default mount is the current directory, read-write.
The Watch · Security desk
What happened
- Docker's September 15 announcement says code running inside a Docker Sandboxes virtual machine on macOS could leave the shared project directory and read or change files anywhere else on the host.
- CVE-2026-77179 is rated Critical, affects 0.28.0 up to but not including 0.42.0 on macOS, and was fixed in 0.42.0, which shipped on September 7, eight days before the advisory.
- The same release fixes CVE-2026-79994, which Docker rates High at CVSS 8.7, in the relay that lets a sandbox connect to Unix domain sockets inside its authorized workspace.
- Docker has not reported exploitation, CISA's assessment on both records lists exploitation as none, and neither CVE is in the KEV catalog as of the version released September 16.
- Docker credits Oren Yomtov of accomplish.ai with finding the file-sharing flaw and Jurre van Bergen of ThreatNotify with finding the socket relay flaw.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure A team that ran an untrusted agent under a pre-0.42.0 build has to scope the question to everything the host account could touch, not to the project directory that was shared in.
- constraint Holding at 0.41.x costs a teardown, because clone mode is fixed at creation time and each existing sandbox has to be destroyed and rebuilt to get it.
- contradiction Anyone who decides upgrades from release notes had nothing to weigh for eight days: the 0.42.0 notes name neither CVE and instead describe a host D-Bus command execution fix Docker has not tied to either one.
- precedent Both bugs are check-then-use on a path the guest controls, so the next places to look are other host-side helpers that reopen or reconnect by stored path name.
Getting root inside the guest is normal operation. Docker's isolation documentation says the hypervisor boundary "is the isolation control, not in-VM privilege separation," and the agent installs packages and runs commands with sudo inside its own virtual machine [6]. Each agent gets that machine with the project directory shared in, and by default sbx run shares the current directory with read and write access [4][17].
The escape sits on the host side of that sharing. The virtio-fs host server followed symlinks when it reopened a removed file from a stored path [7]. A guest 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" [8]. Docker's documentation has said since March that symlinks pointing outside the workspace are not followed [9].
The second flaw is the same trick against a different resource. The relay that lets a sandbox reach Unix domain sockets checked that the socket path was inside the workspace, then reconnected using the path name; a guest that swapped a directory along that path for 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," Docker said [11].
The two version windows overlap. Anything from 0.37.0 through 0.41.9 carries both bugs, and installs from 0.28.0 through 0.36.x carry the file-sharing one only [23]. Updating clears both: 0.42.0 or later, and the newest release as of September 17 was 0.43.0, published September 15 [15].
Clone mode, Docker's fallback for both flaws, works only when the project is a Git repository, and it is set when the sandbox is created [16][18]. It mounts the repository read-only at /run/sandbox/source, and untracked files such as .env stay readable inside the sandbox, Docker's documentation says [19].
Docker lists CVE-2026-77179 as macOS-only and does not state a platform for CVE-2026-79994, and Sandboxes runs on macOS, Windows and Linux hosts [13]. The CVE-2026-79994 record went out on September 15 listing 0.41.0 as the first fixed version, with a link to a 0.41.0 release page that does not exist; Docker corrected both to 0.42.0 about an hour later [21].
What to watch
- A first report of exploitation, or a KEV listing for either CVE, would turn a version bump into an emergency change.
- Whether Docker states a platform for CVE-2026-79994 or extends CVE-2026-77179 beyond macOS to Windows and Linux hosts.
- Whether the host D-Bus command execution fix listed in the 0.42.0 notes gets a CVE record of its own.