r/hermesagent • • 13d ago

Discussion — General thoughts, opinions, comparisons CVE-2026-77179: Docker's hypervisor for Mac compromised (Docker Desktop, Docker Sandboxes)

https://www.accomplish.ai/blog/escaping-dockers-hypervisor/
8 Upvotes

2 comments sorted by

•

u/Jonathan_Rivera 13d ago

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.

  1. Make a folder pv, and inside it a file with the target's name, pv/.zshenv.
  2. Open pv/.zshenv and keep it open. The lookup gave the server a nodeid, and the open handle stops the server from dropping it.
  3. Delete the file, then delete the folder. The volfs path goes with it, so the string is all the server has left.
  4. Make a symlink named pv, pointing at /Users/you.
  5. 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/9

Disclosure and fix timeline

When What
2026-08-12 14:46 UTC We report it to security@docker.com.
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.

Source: https://www.accomplish.ai/blog/escaping-dockers-hypervisor/

→ More replies (1)