Docker Sandboxes is supposed to keep AI coding agents contained. Each agent runs in its own little virtual machine. The project folder is shared in. Everything else stays out.

But a bug let malicious code inside that VM break out. It could read or change files anywhere on the host. Docker disclosed the flaw on September 15.

The vulnerability is CVE-2026-77179. Docker rates it Critical. CVSS score: 9.4. It affects macOS only. Versions 0.28.0 up to, but not including, 0.42.0. The fix landed in 0.42.0 on September 7.

No exploitation has been reported. CISA's assessment on the CVE record lists exploitation as none. It's not in the Known Exploited Vulnerabilities catalog as of September 16.

Here's what happened and what you should do.

Quick Summary

Docker Sandboxes and the Promise of Isolation

Docker Sandboxes runs each AI coding agent in its own small VM. The project directory is shared into that VM. The agent can install packages and run commands with sudo inside the VM.

That's the point. The sandbox is supposed to protect the host from whatever the agent does. Docker's own isolation docs say the hypervisor boundary "is the isolation control, not in-VM privilege separation."

So when the sandbox breaks, the whole model breaks.

How the Escape Worked

The escape ran through the virtio-fs host server. That's the host side of the file sharing between the Mac and the virtual machine.

Docker says the host server followed symlinks when it reopened a removed file from a stored path. A guest whatever runs inside the VM could replace a parent directory with a symlink. Then it could read or change files as the VMM user.

The VMM user is the host account that runs the virtual machine monitor. So the escape runs with that account's rights. Docker says this could lead to code execution on the host.

There's a wrinkle. Docker's documentation has said since March that symlinks pointing outside the workspace are not followed. The workspace is Docker's term for the shared project directory. But the virtio-fs host server did follow them in this case.

The Second Flaw: Unix Socket Relay

The same release fixes a second bug. It's CVE-2026-79994. Docker rates it High. CVSS score: 8.7.

This one is in the relay that lets a sandbox connect to Unix domain sockets inside its authorized workspace. The relay checked that a socket path was inside the workspace. Then it reconnected using the path name.

A guest could replace a directory along that path with a symlink between the check and the connection. That would make the host connect to any AF_UNIX socket outside the workspace. Docker says that could expose data or host-side capabilities provided by that socket.

This flaw affects versions 0.37.0 through 0.41.9. It does not affect 0.42.0.

Affected Versions and Fix

Update to 0.42.0 or later. As of September 17, the latest release is 0.43.0, published September 15.

What to Do If You Can't Update

Docker has advice for both flaws. Use clone mode. Avoid adding read-write host mounts.

By default, sbx run shares the current directory into the sandbox with read and write access. Clone mode works only when the project is a Git repository. It's set when the sandbox is created. So an existing sandbox has to be removed and created again with --clone.

Clone mode protects the repository from changes. It does not protect it from reading. The repository is mounted read-only at /run/sandbox/source. Untracked files like .env stay readable inside the sandbox.

So clone mode reduces the risk. It doesn't eliminate it.

Disclosure Timeline and Oddities

Docker published the CVE records and the advisory on September 15. That was eight days after 0.42.0 shipped.

The 0.42.0 release notes on GitHub and Docker's documentation site don't name either CVE as of September 17. Among routine fixes, they list one for "a sandboxed process could get the daemon to open a host D-Bus transport and execute an arbitrary command on the host." Docker has not connected that fix to either CVE.

The record for CVE-2026-79994 initially listed 0.41.0 as the first fixed version. It linked to a 0.41.0 release page that does not exist. Docker corrected both to 0.42.0 about an hour after publishing the record on September 15.

Docker credits Oren Yomtov of accomplish.ai with finding CVE-2026-77179. Jurre van Bergen of ThreatNotify found CVE-2026-79994.

In April, Cyera Research Labs described how a prompt-injected coding agent inside a Docker-based sandbox could be tricked into exploiting a separate Docker Engine flaw against its host.

What This Means for Defenders

Sandbox escapes matter because coding agents run untrusted code. The agent installs packages. It runs commands with sudo inside the VM. If the hypervisor boundary fails, the host account is exposed.

No exploitation has been reported. That's good. But the flaw is serious. And the fix is available.

If you run Docker Sandboxes on macOS, update to 0.42.0 or later. If you can't, use clone mode and avoid read-write host mounts. Treat the agent's output and the code it runs as untrusted. That's true even inside a sandbox.

The Bottom Line

Docker Sandboxes had a critical escape flaw on macOS. CVE-2026-77179 let malicious code inside the VM read or change files anywhere on the host. A second flaw, CVE-2026-79994, affected Unix socket relay. Both are fixed in 0.42.0. Update now. If you can't, use clone mode and avoid read-write mounts.

Quick Reference:

What to Do:

• Update to 0.42.0 or later
• Use clone mode if you can't update
• Avoid read-write host mounts
• Treat agent code as untrusted

FAQ Section

What is CVE-2026-77179?

A critical escape flaw in Docker Sandboxes on macOS. It let malicious code inside the sandbox VM read or change files anywhere on the host.

How did the escape work?

The virtio-fs host server followed symlinks when reopening a removed file. A guest could replace a parent directory with a symlink and access host files as the VMM user.

What is CVE-2026-79994?

A high-severity flaw in the Unix socket relay. A guest could replace a directory with a symlink between the check and connection, making the host connect to sockets outside the workspace.

Which versions are affected?

CVE-2026-77179 affects 0.28.0 to before 0.42.0 on macOS. CVE-2026-79994 affects 0.37.0 to before 0.42.0.

Has it been exploited?

No exploitation has been reported. CISA lists exploitation as none, and it's not in the KEV catalog as of September 16.

What should I do?

Update to 0.42.0 or later. If you can't, use clone mode and avoid read-write host mounts.

Source: The Hacker News