Nothing broke the hardware boundary. Docker's 15 September advisory describes two ways out of a Docker Sandboxes microVM, and both of them went through a channel the sandbox opens on purpose — the workspace file share and the guest-to-host socket relay. That is the durable lesson for anyone buying isolation for a coding agent: your blast radius is not set by the isolation technology, it is set by the host-side code servicing the holes you deliberately punched through it.
At a glance
Two advisories, one product, one root-cause pattern.
| Identifier | Severity | Affected | Where it lives |
|---|---|---|---|
| CVE-2026-77179 | Critical — CVSS v4.0 9.4 | 0.28.0 ≤ v < 0.42.0, macOS | virtio-fs host server (the workspace share) |
| CVE-2026-79994 | High | 0.37.0 ≤ v < 0.42.0 | guest-to-host Unix domain socket relay |
Both are symlink-substitution races; the critical one is classed CWE-59, improper link resolution before file access. Both were fixed in Docker Sandboxes 0.42.0, released on 7 September; the advisory followed on 15 September. Docker has reported no known exploitation.
What actually broke
Docker Sandboxes, generally available since 30 January 2026, gives each coding agent a disposable microVM: its own kernel, its own filesystem, its own Docker daemon, its own network stack, driven by an sbx CLI. Your project directory is shared in read-write, because an agent that cannot edit your repository is not a coding agent. The pitch is that you can run Claude Code or Codex unattended — permission prompts off — and a compromised or runaway agent still cannot reach the host.
The first bug is in the virtio-fs host server, the component that serves that shared workspace. When it reopened an unlinked file from a path it had stored earlier, it followed symbolic links. A guest that controls the workspace can replace a parent directory with a symlink after the path was recorded, so the later operation resolves somewhere else entirely. The result is arbitrary read and write of host files reachable by the virtual machine monitor process — which, on a developer laptop, runs as the developer.
The second bug is the same shape in a different channel. The socket relay checked that a requested socket path sat inside the approved workspace, and then connected using the original path string rather than the validated handle. Swap an intermediate directory for a symlink between the check and the use, and the host connects to an AF_UNIX socket of the guest's choosing, outside the workspace.
Both are time-of-check-to-time-of-use races against symlinks: the oldest bug class in Unix, arriving in an AI product because that product's entire job is mediating a filesystem between an untrusted party and you. Note what is not here. This is not an authorization bug — nobody exceeded a permission they had been granted. The permission model was fine; the code implementing it resolved a path twice and got two different answers.
The untrusted party is your own agent
"An attacker controlling the guest" reads, in a normal container advisory, as someone who already got in. In an agent sandbox it reads differently, because the guest is software you launched yourself and then pointed at the internet.
A coding agent reads issue text, dependency READMEs, CI logs, web pages, and the output of every command it runs. Any of those can carry instructions, and the agent has a shell. The product's own value proposition — unattended execution with permission prompts disabled — is precisely the configuration in which nobody is watching the moment a prompt injection turns "the guest" into "the attacker controlling the guest". You do not need a compromised laptop or a malicious insider for these CVEs to matter. You need one poisoned README in a transitive dependency and an agent doing what it was bought to do.
That is why the severity assessment for an agent sandbox should not start from "how likely is a hostile guest". Assume the guest is hostile on some percentage of runs, because that is the threat model the sandbox was purchased to handle. The question that remains is what a hostile guest reaches when the channel it must be given fails.
Why both bugs are in the same place
Isolation technology has a strong record. A microVM gives you a separate kernel and a hardware-enforced boundary, and neither CVE dented it — the same conclusion the wiki's comparison of gVisor, Firecracker, Kata and Wasm reaches from the opposite direction. What has a much weaker record is the paravirtualised plumbing bolted across that boundary so the thing inside can be useful: shared filesystems, socket forwarding, clipboard bridges, port proxies, credential helpers. That code is host-side, it parses guest-controlled input, and it is where sandbox escapes have lived for a decade.
For an agent sandbox this is structural rather than accidental. The share is the product. Nobody buys a microVM that cannot see the repository, so the one channel with the worst properties — guest-controlled paths, host-side parsing, host filesystem on the other side — is also the one channel you can never configure away. The correct reading of an escape through it is not that the vendor was careless. It is that this surface will produce a bug of this class again, and your design should already assume the next one.
Which reframes the shopping question. "Is it a real VM or just a container?" is the question everyone asks, and it decides only the wall. The questions that decide your loss are: what is mounted, as whom does the monitor process run, and how fast do you patch.
What to change on Monday
| Boundary | What it promises | What a failure gets the guest | What you control |
|---|---|---|---|
| MicroVM / kernel | No host code execution from guest code | Everything, but it did not fail here | Vendor choice, patch level |
| Workspace share | Guest sees only the project directory | Every file the monitor process can read or write | What you mount, and as whom you run |
| Socket relay | Guest reaches only approved sockets | Any local service that trusts its socket peers | Whether you enable it at all |
| Network egress | Guest reaches only allowed hosts | Exfiltration of whatever it already read | Allowlist, and whether one exists |
Four concrete moves follow from that table, in descending order of return:
- Upgrade to 0.42.0 or later. Both fixes shipped on 7 September, eight days before the advisory. If you install through a package manager rather than the desktop updater, check the installed version rather than assuming.
- Shrink what is behind the door. The workspace share does not have to be a directory inside your real home. Give the agent a dedicated checkout under a path that holds nothing else — not your SSH keys, not your cloud credentials, not your other clients' repositories. The first CVE's reach was "host files accessible to the VMM user", and you get to decide how much that is.
- Do not run the sandbox as your daily user if you can avoid it. On a shared build host this is straightforward and rarely done; on a laptop it is friction, and the honest trade is to accept the risk deliberately rather than by default. Sandbox and isolation patterns covers the layering.
- Patch these on the appliance clock, not the tooling clock. A developer-tool CVE feels like low priority until you notice it is a pre-authentication path from internet-derived content to your home directory. Treat agent sandboxes as internet-facing software, because functionally they are.
If you do one thing today, make it the mount. Upgrading fixes these two bugs; changing what the share points at fixes the class. An agent working in a throwaway clone with no credentials beside it turns the next escape of this kind from an incident into a bad afternoon — and unlike patch velocity, it costs you nothing to keep.
FAQ
Was the microVM isolation itself broken?
No. Neither CVE involves escaping the virtual machine's hardware boundary or the guest kernel. Both abuse host-side services that deliberately cross that boundary — the virtio-fs file share and the socket relay — by winning a race against a symlink.
Am I affected if I do not use macOS?
CVE-2026-77179 is scoped to macOS. The socket-relay bug, CVE-2026-79994, is listed for 0.37.0 up to 0.42.0 without that platform qualifier. Upgrade regardless of platform, and read the advisory for the scoping that applies to your install.
Does this mean containers would have been just as good?
No, and the inference runs the wrong way. The microVM boundary held; a container's shared-kernel boundary is weaker and would still have been sitting behind the same shared workspace. What the advisory shows is that the channels through the boundary deserve the same scrutiny as the boundary, not that the boundary is pointless.
How would I know if this had been exploited against me?
Realistically, you would not, from the sandbox's own logs. The escape looks like ordinary file operations from the monitor process — the same process legitimately writes your repository. Detection lives at the host level: file integrity monitoring on credential paths, and egress logging. This is the argument detecting agent compromise makes at length.
What is the general rule to take away?
Count the channels you have opened through your isolation boundary, and assume each one will eventually fail. Then size what sits behind each channel so that the failure is survivable. Isolation strength is a property of the whole perimeter, not of its strongest wall.
Further reading
On this wiki:
- Sandbox and isolation patterns — what each isolation layer actually promises.
- Sandboxing and execution for coding agents — building the enclosure an agent works inside.
- Detecting agent compromise — the signals that survive when the agent's own logs cannot be trusted.
- Blast radius — sizing the loss before it happens.
- gVisor vs Firecracker vs Kata vs Wasm — the isolation technologies themselves, compared.