Malicious code running inside a Docker Sandboxes virtual machine on macOS can break out of the single project folder shared into it and reach files anywhere else on the host, Docker said in a security announcement on 15 September. The docker sandboxes vulnerability, tracked as CVE-2026-77179 and rated Critical, lets a guest process read or overwrite host files with the same rights as whichever account launched the virtual machine.
Docker Sandboxes is built to run project code inside a VM rather than directly on the Mac, with only one folder, the project directory a developer explicitly shares in, visible to that VM. Everything else on the host is meant to stay off-limits. CVE-2026-77179 removes that limit: guest code can step outside the shared folder and reach the rest of the filesystem, which is precisely the access the sandbox exists to deny.
The value of that model is that a developer can point Sandboxes at a folder containing code from a source they only partly trust, a dependency, a pull request, a generated script, without granting it any reach into the rest of the machine. That promise is what CVE-2026-77179 undermines: the one thing a developer explicitly did not share becomes reachable anyway.
Why the Docker Sandboxes vulnerability breaks host isolation
Most container escapes involve breaking out of namespace or cgroup restrictions on a shared kernel, a narrower barrier than a full virtual machine. Docker Sandboxes uses an actual VM boundary, which is normally the stronger of the two: a process inside the VM is supposed to have no direct path to the host’s files at all, let alone the host user’s own files. A flaw that crosses a VM boundary rather than a container boundary is why Docker rated this Critical instead of treating it as a narrower information leak.
The escape does not require root or any stolen credential. It runs with the rights of whichever account started the virtual machine, and on a typical single-user Mac that is the same account that owns the home directory. Guest code that finds the way out of the shared folder is not landing in some restricted corner of the disk: it inherits the same read and write access the developer already has, covering documents, browser profiles, SSH keys and anything else that account can touch.
What it means for Docker Sandboxes users on macOS
Anyone using Docker Sandboxes to run code they do not fully trust should treat that isolation as broken until Docker names a fixed build. Docker’s announcement on 15 September does not state which version resolves CVE-2026-77179, so the safest position for now is to assume the current release is still exposed and avoid pointing Sandboxes at anything untrusted in the meantime.
The flaw also has a public record at CVE-2026-77179 on the National Vulnerability Database, separate from Docker’s own write-up. It is worth checking directly: NVD entries get updated as vendors narrow affected version ranges or publish fixes, and that update will show up there before it necessarily reaches a summary of the original advisory.
Watch that record, and Docker’s own advisory, for the specific version that closes CVE-2026-77179. Until one is named, the practical fix is to keep untrusted code out of Docker Sandboxes on macOS entirely.
