The sandbox was the whole control

Docker Sandboxes exists to run AI coding agents somewhere they cannot damage the machine. Each agent gets its own micro virtual machine with the project directory shared in, and inside that machine the agent installs packages and runs commands with sudo, because that is the point.

Docker's isolation documentation is explicit about what that means: the hypervisor boundary "is the isolation control, not in-VM privilege separation."

There is no second layer. Two flaws disclosed on 15 September crossed the only one there is.

The two flaws

CVE-2026-77179 — CVSS 9.4, Critical, macOS. The virtio-fs host server, which handles file sharing between the Mac and the virtual machine, followed symbolic links when reopening an unlinked file from a stored path.

A malicious guest could replace a parent directory with a symlink after the path was recorded, escape the shared workspace, and read or modify arbitrary files on the host as the VMM user — the host account the virtual machine monitor runs under. Docker's own wording is that this potentially leads to code execution on the host.

CVE-2026-79994 — CVSS 8.7, High. A time-of-check to time-of-use problem in the relay that lets a sandbox reach Unix domain sockets inside its authorised workspace.

The relay verified that a socket path was inside the workspace, then reconnected using the path name rather than a retained file reference. A guest that swapped an intermediate directory for a symlink between the check and the connection could make the host connect to any AF_UNIX socket outside the workspace — exposing whatever data or host-side capability that socket provides.

CVE-2026-77179 virtio-fs host server 0.28.0 → before 0.42.0 macOS CVE-2026-79994 guest-to-host socket 0.37.0 → before 0.42.0 platform not stated Fixed in 0.42.0, released 7 September Current release 0.43.0

There is no known exploitation. Neither flaw is in CISA's catalogue of actively exploited vulnerabilities, and EPSS puts the 30-day exploitation probability at well under one percent.

Who the attacker is meant to be

This is what makes the story worth more than a version bump.

The threat model here is not an intruder on your network. It is the code running inside the sandbox — which is to say, the coding agent you deliberately started, or anything it installs and runs.

An agent can be turned against its user through prompt injection in a repository file, an issue comment, a web page it fetches, or a compromised MCP server. It can also simply install a malicious dependency while doing what you asked. In April, Cyera Research Labs demonstrated a prompt-injected coding agent inside a Docker-based sandbox being tricked into exploiting a separate Docker Engine flaw against its host.

The sandbox is the control that makes running agents acceptable. Removing it does not degrade the security posture — it removes it.

The mitigation has a caveat worth reading twice

If you cannot update, Docker's advice for both flaws is to use clone mode and avoid read-write host mounts. By default, sbx run shares the current directory with read and write access.

Clone mode only works when the project is a Git repository, and it is set when the sandbox is created — an existing sandbox has to be removed and recreated with --clone.

More importantly:

Clone mode protects the repository from changes, not from reading. The repository is mounted read-only, and untracked files such as .env stay readable inside the sandbox.

We wrote last week about a campaign specifically harvesting .env files, AWS credential files and Terraform state from exposed development servers. If an agent inside a clone-mode sandbox is compromised, those files are still available to it. Clone mode reduces the blast radius of a write. It does nothing for a secret.

Update. The mitigation is a stopgap for a few hours, not a position.

The gap, for the seventh time

Docker fixed both flaws in 0.42.0 on 7 September. It published the advisory and the CVE records on 15 September.

The 0.42.0 release notes do not name either CVE. Among routine entries they list a fix for a sandboxed process getting the daemon to open a host D-Bus transport and execute an arbitrary command on the host — which Docker has not connected to either record.

So anyone reading the changelog on 7 September had no way to know this was an urgent security update. Anyone who read it on the 15th had eight days of retrospective exposure to consider.

This is now the seventh incident in a month where the fix and the disclosure were separated by a meaningful interval — after MikroTik, Plex, Chromium, PaperCut, StyleSmuggler and GitLab. The version number is the first disclosure; the advisory is the second.

Two smaller notes in the same direction. Docker's documentation had stated since March that symlinks pointing outside the workspace are not followed, which was the security property that turned out not to hold. And the CVE record for the second flaw initially listed a first-fixed version that did not exist, corrected about an hour later.

None of that is unusual. All of it is the reason a version number in a changelog is not a security signal.

What to do

1. Update Docker Sandboxes to 0.42.0 or later. The current release is 0.43.0.
2. Check every machine that runs coding agents, not just servers. This is developer laptop software. It will not appear in a server patch report, and on macOS it is the personal machine that holds the SSH keys, the cloud credentials and the signing material.
3. If you cannot update today, use clone mode and drop read-write host mounts — while understanding that secrets in the working tree remain readable.
4. Decide what a compromised agent can reach. The sandbox limits what it can touch on the host. It does not limit what it can do with credentials that are inside the sandbox with it, or with network access it has been given.
5. Treat agent sandboxes as a patched product class. Anything that runs untrusted code by design needs the same update discipline as a browser, and it currently gets the discipline of a developer utility.

4Tify reviews developer workstation exposure, including the tooling that runs untrusted code by design and the credentials sitting next to it. If you want that assessed, get in touch.