"potentially leading to code execution on the host." — Docker
The virtio-fs escape on macOS (CVE-2026-77179)
Docker warned on September 15 that 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. The escape leverages the virtio-fs host server — the host side of file sharing between the Mac and the virtual machine — which followed symlinks when it reopened a removed file from a stored path, Docker said.
Docker described the practical effect plainly: a guest (anything running inside the VM, including an AI coding agent or packages it installs) 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. The escape therefore runs with the rights of the host account that runs the virtual machine. Docker assigned this flaw CVE-2026-77179, rated Critical.
AF_UNIX relay redirection (CVE-2026-79994)
The September 15 advisory also fixed a second vulnerability in the relay that permits a sandbox to connect to Unix domain sockets within its authorized workspace. Docker said the relay first checked that a socket path was inside the workspace, then reconnected using the path name — a classic time-of-check/time-of-use window.
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 warned, "exposing data or host-side capabilities provided by that socket." Docker rated this second issue High (CVE-2026-79994, CVSS 8.7).
Your scanner finds 4,000 vulns. Which 12 matter?
Nubivance is a Rapid7 Registered Partner delivering vulnerability management as a service - scanning, risk-based prioritization, and remediation follow-through across IT and OT.
Fix the backlogAffected versions, updates, and mitigation advice
CVE-2026-77179 affects Docker Sandboxes versions 0.28.0 up to but not including 0.42.0 on macOS and was fixed in 0.42.0, which Docker shipped on September 7. Docker lists the second flaw, CVE-2026-79994, as affecting 0.37.0 through 0.41.9 and also fixed in 0.42.0. As of September 17, the most recent release was 0.43.0, published on September 15.
Docker's explicit guidance: update to 0.42.0 or later. For users who cannot update immediately, Docker advised using clone mode and avoiding adding read–write host mounts. 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 and must be set at sandbox creation; an existing sandbox must be removed and created again with --clone. Clone mode mounts the repository read-only at /run/sandbox/source, but Docker's documentation notes that untracked files such as .env remain readable inside the sandbox.
CISA assessment and Docker's disclosure timeline
Docker published CVE records and its advisory on September 15, eight days after 0.42.0 first shipped. CISA added an assessment to the CVE records indicating exploitation as none, and neither of the flaws was listed in CISA's Known Exploited Vulnerabilities (KEV) catalog as of the catalog version released on September 16. Docker's advisory likewise reported no exploitation.
Docker's public artifact trail shows a brief inconsistency: 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 entries to 0.42.0 about an hour after publishing the record on September 15. The 0.42.0 release notes on GitHub and Docker's documentation site did not name either CVE as of September 17, although they did list other sandbox-related fixes.
Who found the flaws, related research, and where responsibility sits
Docker credited Oren Yomtov of accomplish.ai with finding CVE-2026-77179 and Jurre van Bergen of ThreatNotify with finding CVE-2026-79994. The advisory underscores a core design point in Docker's own documentation: the hypervisor boundary is the isolation control, not in-VM privilege separation. In other words, protecting the host from what an agent runs is the sandbox's responsibility — but the vulnerabilities described here permitted a guest to influence the host-side file server and relay.
Separately, Docker's advisory and the record note prior research in the area: 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. Together these items track a string of concerns about how code running in sandboxed agents can interact with host services when file shares and sockets are exposed.
What this means for technologists, procurement teams, and end users
- Technologists and security teams: prioritize updating Docker Sandboxes to 0.42.0 or later, audit any sandboxes that use read–write host mounts, and consider recreating sandboxes with --clone where possible. Review mounts and socket exposures to reduce the potential for symlink-based redirection.
- Procurement and platform owners: require patched versions in vendor contracts and validate that CI/CD or developer environments using Docker Sandboxes are not exposing host mounts or sockets unnecessarily, since the escape runs with the host account that runs the virtual machine.
- End users and developers running agents: understand that agents and packages they install inside Sandboxes can perform actions with VM privileges; untrusted or prompt-injected code inside the sandbox can therefore be a vector for host-impacting activity if the environment permits mounts or sockets that the sandbox can influence.
Docker's fixes close two distinct avenues that allowed a guest to influence host-side services: virtio-fs following of recreated paths and a relay reconnect that could be tricked into using symlinked paths. The immediate practical step is simple and explicit in Docker's advisory: update to 0.42.0 or later, or fall back to clone mode and remove read–write host mounts until you can.
