We reported a sandbox escape in Docker's hypervisor for Mac: a container gets complete read and write access to the host filesystem with three lines of bash. Assigned CVE-2026-77179 and fixed in Docker Desktop 4.88.0 and Docker Sandboxes 0.42.0.
Docker has patched a sandbox escape we reported in its hypervisor for Mac: a container can get complete read and write access to the host filesystem by running three lines of bash.
Docker Desktop and Docker Sandboxes are both affected. Docker Desktop is only affected if Docker VMM is turned on in Settings. It’s a good thing we found it now, because Docker VMM is scheduled to become the default for Docker Desktop at the end of October 2026.
The vulnerability has been assigned CVE-2026-77179, and has been fixed in Docker Sandboxes 0.42.0 and Docker Desktop 4.88.0.
The bug
When you mount a folder into a container, Docker’s VMM uses virtio-fs, and the file server that serves it runs on the host. The first time the guest touches a path it sends a lookup, and the server answers with a nodeid: a number the server picked, for its own bookkeeping. From then on the guest asks by nodeid and never sends the path again, so the server has to find that file again on every request.
It has two ways to find it. First by inode, through macOS volfs. If that fails, it falls back to the path string it saved when the file was first looked up.
Deleting the file removes the volfs path. Holding it open keeps the nodeid. Together they leave the server with nothing but the string. Then the guest replaces the parent folder with a symlink. The server reads that string and sees a path that’s inside the mounted folder and allows it, but then the kernel reads the same string, follows the symlink, and opens a file on the host outside of the mounted folder.
The exploit
The guest picks a file on the host that it wants to read or overwrite. Say /Users/you/.zshenv.
- Make a folder
pv, and inside it a file with the target’s name,pv/.zshenv. - Open
pv/.zshenvand keep it open. The lookup gave the server a nodeid, and the open handle stops the server from dropping it. - Delete the file, then delete the folder. The volfs path goes with it, so the string is all the server has left.
- Make a symlink named
pv, pointing at/Users/you. - Read or write through the handle from step 2.
The server resolves that string one more time. pv is a symlink now, and it is not the last name in the path, so the kernel follows it. The request lands on /Users/you/.zshenv.
The same thing in bash:
mkdir pv && : > pv/.canary && exec 9< pv/.canary
rm pv/.canary; rmdir pv; ln -s /Users/Shared pv
echo CONFIRMED > /proc/self/fd/9Disclosure and fix timeline
| When | What |
|---|---|
| 2026-08-12 14:46 UTC | We report it to [email protected]. |
| 2026-08-12 21:54 UTC | They reply, acknowledging receipt, about seven hours after the report. |
| 2026-08-13 22:16 UTC | Sailor commit 9f348c0. This is the fix. About 31 hours after the report. |
| 2026-08-14 14:36 UTC | Docker confirms the bug, says a fix is in progress, and says they plan to issue a CVE. |
| 2026-08-24 | Docker Desktop 4.88.0 ships sailor 0.118.0. |
| 2026-09-07 | Docker Sandboxes 0.42.0 ships the fix for CVE-2026-77179. |
Sailor is the internal name of Docker’s hypervisor.
Docker’s security team was quick and professional. They replied in about seven hours and confirmed the bug in two days. The Docker Desktop fix shipped on August 24, and the Docker Sandboxes fix shipped in 0.42.0 on September 7.
Checking if you’re affected
If you use Docker Sandboxes, run sbx --version. Make sure you’re running 0.42.0 or later.
If you use Docker Desktop, you want 4.88.0 or later. Open Settings, General, Virtual Machine Manager. Any earlier version with Docker VMM selected is affected.
Sandboxing agents
Agents run untrusted code all day, and the sandbox around them is the only thing between that code and the machine it runs on.
That sandbox is what we build at Accomplish: one environment for any agent, any model, any cloud.
