The container that was supposed to hold an AI coding agent could be climbed out of. Docker has disclosed that code running inside a Docker Sandboxes virtual machine on macOS was able to leave the shared project directory and touch files anywhere else on the host.
Container specialists rate the escape Critical. It is tracked as CVE-2026-77179 and reaches versions 0.28.0 through 0.42.0 on macOS. A corrected build, 0.42.0, shipped on September 7; the advisory followed on September 15.
The whole point of Docker Sandboxes is that a turned agent, or a malicious package it installs, stays boxed in its own small virtual machine. The shared project directory is the only intended bridge. This bug crosses it through the virtio-fs host server, the host side of that file-sharing channel, and whatever gets through runs with the rights of the macOS account that started the machine.
A second flaw, CVE-2026-79994, went in the same release. It let a sandboxed process talk the daemon into opening a host D-Bus transport and running an arbitrary command. Docker’s 0.42.0 release notes list that fix without linking it to either CVE, and one CVE record briefly cited a nonexistent 0.41.0 page before being corrected.
No exploitation has been reported. Docker has not flagged any, and CISA’s assessment attached to the record lists exploitation as none. The flaw is absent from the Known Exploited Vulnerabilities catalog.
Upgrading to 0.42.0 closes it, but not automatically for machines already running: a live sandbox has to be removed and recreated. Clone mode also rewards a second look, since it shields a repository from changes but not from reads, leaving untracked files like .env visible inside the sandbox.
