Docker Sandboxes CVE-2026-77179 and CVE-2026-79994: when the agent VM can still reach the host

Docker Sandboxes is the feature that runs an AI coding agent inside a purpose-built virtual machine, so that whatever the agent does stays out of the developer's environment. In September 2026 Docker published two advisories showing that a process inside that virtual machine could reach the host anyway.

The virtio-fs path

The first issue is CVE-2026-77179. It affects the virtio-fs host server used to share files with the sandbox, in versions from 0.28.0 up to but not including 0.42.0. Docker rated it critical and the CVSS score is 9.4. The scope is macOS, where the shared file system is implemented in this way.

The consequence is direct. Code running inside the per-agent virtual machine can read and modify arbitrary files on the host, outside the shared project directory, with the privileges of the host account. The shared directory is the boundary the feature advertises, and this defect steps outside it.

The find is credited to Oren Yomtov of accomplish.ai.

The guest-to-host socket relay

The second issue is CVE-2026-79994, rated 8.7, affecting versions from 0.37.0 up to but not including 0.42.0. It involves a Unix socket relay between the guest and the host. The Docker advisory does not name the platform for this one, and the text describes the mechanism rather than a full reproduction.

Two defects in the same component within the same window is worth noting on its own. The shared-filesystem path and the socket relay are the two channels through which a sandbox is supposed to communicate with its host, and both had a defect in the same version range.

One detail from the CVE records is worth recording for anyone who tracks their own inventory. The record for CVE-2026-79994 initially listed 0.41.0 as the fixed version and corrected it to 0.42.0 about an hour later. If a tool cached that entry early, it may still show the wrong fix version.

Fixed versions and the interim option

Both issues are fixed in 0.42.0, released 7 September 2026. The advisories and the CVE records were published on 15 September, and version 0.43.0 followed on the same day as the advisories.

Until a host can be updated, Docker's documented interim measure is to run sandboxes in --clone mode. That mode works only with Git repositories and mounts the source read-only at /run/sandbox/source. It reduces what the agent can reach, with a caveat worth stating plainly: .env files and untracked files inside the repository remain readable, because they are part of the checked-out tree.

Why the boundary is the hypervisor

Docker's own documentation frames the sandbox as a hypervisor barrier rather than a privilege boundary inside the virtual machine. That framing explains the shape of these two bugs. Processes running in the guest are not separated from each other, and the isolation that matters is the one the hypervisor enforces. A defect in the host-side component that implements sharing weakens exactly that layer.

For a security program, the useful question is not whether the agent is trusted. It is what the host-side service is allowed to touch on behalf of the guest, and how that is verified.

Exploitation status

Docker did not report in-the-wild exploitation, and neither issue appeared in CISA's Known Exploited Vulnerabilities catalogue as of 16 September 2026. The second defect is credited to Jurre van Bergen of ThreatNotify.

What to do

Update to 0.42.0 or later, which covers both CVEs, and treat 0.43.0 as the current build. After updating, check anything the sandbox had access to during the exposure window, particularly files outside the project directory and any credentials stored in the developer's home directory. Because the first flaw grants modification as well as read access, an integrity check on shell startup files and Git configuration is a reasonable follow-up.

References