CVE-2026-77179: The Docker Sandboxes Escape and the Limits of Sandboxing AI Agents

CVE-2026-77179 is in the virtio-fs server, the host-side component that shares your workspace with the VM. According to Docker's CVE record, on macOS the server follows symlinks when reopening an unlinked file from a stored path. A malicious guest can replace a parent directory with a symlink, escape the shared workspace, and read or modify host files as the VMM user. It affects Docker Sandboxes from 0.28.0 up to, but not including, 0.42.0.

CVE-2026-79994, rated 8.7, is in the guest-to-host Unix socket relay. The relay validates that a socket path is inside an authorized workspace, then reconnects later using the path name. In the gap, a guest can swap an intermediate directory for a symlink so that the host connects to an arbitrary Unix socket. Whether that matters depends on what is listening on your machine, since local sockets often expose capable services. It affects versions from 0.37.0 up to, but not including, 0.42.0. Docker's advisory does not limit this one to a specific platform.

Both share a classic pattern: the code trusted a file path at one moment and acted on it at another, while the guest could change what that path pointed to in between. Hypervisor isolation can be solid and still be undone by a helper service that crosses the boundary.

Oren Yomtov of Accomplish reported the file-sharing flaw to Docker on August 12, 2026, and says Docker acknowledged it the same day. Docker shipped Sandboxes 0.42.0 on September 7, and the CVE records were published on September 15. The current release listed in Docker's Sandboxes release notes was 0.51.0 as of November 3, so most users who update at all should be well past the fix.

The researcher's write-up also says Docker Desktop before 4.88.0 was affected when the optional Docker VMM engine was enabled. Docker's advisory and CVE records name only Docker Sandboxes, and the Desktop 4.88.0 release notes do not mention it, so we cannot confirm that from Docker's side. Keeping Desktop current settles the question either way.

Docker's advisory speaks only of a malicious guest. It says nothing about AI agents being tricked, and we are not aware of a real incident that chained these bugs with prompt injection. The connection is a matter of threat modeling, but a reasonable one. An agent inside a sandbox is exactly the process that reads untrusted content all day: web pages, package READMEs, GitHub issues, and dependency code.

If injected instructions, or a malicious install script, can run commands inside the guest, then a guest-to-host bug is the second step of an attack chain. The sandbox exists because that first step is plausible. As the researcher put it, the sandbox is the only thing between that code and the machine it runs on.

A sandbox remains the right call, and these bugs are no reason to run agents directly on your host. Treat it as one layer and assume that any single layer can fail. The goal is that when one layer fails, the blast radius is an inconvenience and not your business.

The machine running the agent is usually the most sensitive computer in a small company. It often holds cloud credentials, SSH keys, production environment files, and a browser session logged in to your payment provider. Reducing what lives there does more for you than any sandbox setting.

AI agents can do excellent work, and running them responsibly is a learnable skill. The risk these CVEs illustrate is subtler than bad generated code. Agents have quietly become privileged software on the machines that control your product, and many founders adopted them without anyone deciding what they are allowed to reach.

When a product is making money, that decision should be deliberate. Someone should know where the production secrets live and who can deploy, and should be able to say how you would find out if a developer machine were compromised, and how you would rotate everything afterward. If nobody can answer those questions today, that is normal for a young product, and it is a fixable problem. It is also the point where an experienced professional earns their keep.

We help teams keep the speed of AI-assisted development while putting those boundaries in place: separating development from production access, adding review and release controls, and staying available as the tools change. If you are not sure whether your setup is reasonable, an outside review is a cheap way to find out before an incident answers the question for you.