On September 15, 2026, Docker published a security announcement that got a fraction of the attention it deserved. Two flaws in Docker Sandboxes, the product that runs each AI coding agent inside its own lightweight virtual machine, let code inside that machine step outside it and touch the host. One flaw is rated Critical at CVSS 9.4. The other is High at 8.7. Both are fixed in 0.42.0.
Sit with one sentence from Docker's own documentation for a moment. The hypervisor boundary "is the isolation control, not in-VM privilege separation." Translation: everything inside the VM is assumed hostile. The agent, the packages it installs, the commands it runs with sudo. That is the entire design. The sandbox is not a convenience wrapper around a risky tool. It is the control.
So when the file-sharing layer that makes a sandbox useful also makes it escapable, the trust model falls apart.
What Docker Disclosed
Docker's advisory covers two vulnerabilities in Docker Sandboxes, the tooling that gives each AI coding agent its own micro-VM with the project directory shared in.
- CVE-2026-77179 is Critical, CVSS 9.4. It lives in the virtio-fs host server, the host side of the file sharing between the Mac and the VM. The server followed symlinks when reopening a removed file from a stored path. A guest could replace a parent directory with a symlink, break out of the shared workspace, and read or modify arbitrary files as the VMM user, the host account running the virtual machine monitor, "potentially leading to code execution on the host," Docker wrote. Affected: 0.28.0 up to but not including 0.42.0, macOS only.
- CVE-2026-79994 is High, CVSS 8.7. It lives in the relay that lets a sandbox connect to Unix domain sockets inside its authorized workspace. The relay validated that a socket path was inside the workspace, then reconnected by name. A guest that swapped a directory along that path for a symlink between the check and the connect could make the host reach any AF_UNIX socket outside the workspace, "exposing data or host-side capabilities provided by that socket." Affected: 0.37.0 up to but not including 0.42.0.
Both were fixed in 0.42.0 on September 7, 2026. The most recent release is 0.43.0, published September 15. Docker has not reported exploitation, CISA's assessment on the records lists exploitation as none, and neither flaw is in the Known Exploited Vulnerabilities catalog as of its September 16 version.
The Uncomfortable Detail
Docker's documentation has stated since March that symlinks pointing outside the workspace are not followed. That was the promise. CVE-2026-77179 is the stored-path fallback quietly not keeping it.
This is the pattern security teams keep meeting in agentic tooling. The controls are real, the design intent is sound, and then one fallback branch in one code path does the naive thing. The escape runs with the privileges of the host account that launched the VM. If that account is the developer's everyday login, then so is everything reachable from it: SSH keys, cloud CLI credentials, browser sessions, source checkouts, password manager vaults.
Why the CVSS Score Is Not the Level of Risk
Neither flaw is remotely exploitable. Both need malicious code inside the sandbox first. That sounds reassuring until you remember what a coding agent is. It is a process that reads untrusted input, follows instructions embedded in that input, installs packages from public registries, and executes generated code with elevated privileges inside its VM. Prompt injection is a live, unsolved class of attack. A poisoned dependency is routine. The guest is not a trusted zone, and the whole architecture says so.
So the honest question is not whether someone can exploit this. It is what your blast radius looks like the day someone does. If your agents run under an account that also holds production credentials, the answer is: everything.
What To Do This Week
- Patch to 0.42.0 or later. 0.43.0 is out. If you cannot update immediately, Docker's guidance is to use clone mode, which removes the shared-workspace exposure.
- Inventory who runs sandboxed agents. Version, platform, and which host account launches the VM. A patch you cannot prove is installed is not a patch.
- Give the VMM its own least-privilege account. No cloud credentials, no SSH keys, no deploy tokens, no access to your password vault. The escape inherits exactly the rights you handed the VM.
- Keep secrets out of the shared project directory. The workspace is the thing the sandbox is designed to hand to untrusted code.
- Treat the isolation boundary as one bug away from failing, because it is. Layer it: no long-lived credentials in the agent environment, egress monitoring on agent hosts, and a separate machine for anything that touches production.
- Make dev-tool patch cadence a security process, not a habit. Agent sandboxes ship weekly. Your review cycle should be shorter than the interval between their CVEs.
The Bigger Lesson
We spent the last two years telling teams to sandbox their AI agents. Give them a VM, cap their network, keep them away from production. That guidance is still right, and it is still the best available control.
But a sandbox is a boundary between two trust zones, and boundaries need the same discipline we apply everywhere else: least privilege on both sides, no ambient credentials, monitoring, and a patch process that actually runs. Docker fixed these flaws in eight days and disclosed responsibly. The engineering was good. The uncomfortable lesson is subtler. In agentic systems, every component in the chain decides how much the boundary is worth, and the weakest fallback branch sets the price.
If your team is running AI coding agents and you are not sure what they can reach from inside their sandbox, that is a conversation worth having this week.
Sources
- Docker security announcements: Docker Sandboxes 0.42.0 security update (CVE-2026-77179 and CVE-2026-79994), September 15, 2026
- The Hacker News: Critical Docker Sandboxes Flaw Lets Malicious Guest Code Read and Modify macOS Host Files, September 17, 2026
- Docker Sandboxes isolation documentation
- Docker sbx-releases v0.42.0 and v0.43.0