Critical Docker Sandboxes Flaw Lets Malicious Guest Code Read and Modify macOS Host Files
Docker fixed CVE-2026-77179 (CVSS 9.4), a virtio-fs symlink flaw letting code inside macOS Sandboxes VMs read and modify host files; update to 0.42.0.
CVE-2026-77179 (CVSS 9.4, macOS-only) is a symlink-following flaw in the virtio-fs host server of Docker Sandboxes versions 0.28.0 to 0.41.x that lets guest code escape the shared project directory and read or modify host files as the VMM user, potentially leading to host code execution. A second flaw, CVE-2026-79994 (CVSS 8.7), is a check-to-use race in the Unix socket relay that lets a sandbox connect to AF_UNIX sockets outside its workspace. Both were fixed in version 0.42.0 on September 7 and disclosed September 15; no exploitation has been reported and neither flaw is in CISA's KEV catalog.
- Guest replaces a directory with a symlink; virtio-fs follows it, enabling host file access as VMM user
- Second flaw CVE-2026-79994 (CVSS 8.7) exposes AF_UNIX sockets outside the sandbox workspace
- Fixed in Docker Sandboxes 0.42.0 (September 7); 0.43.0 is the current release; no exploitation seen
- Sandboxes isolate AI coding agents, and the escape runs with the host account's rights
- Mitigation: use clone mode and avoid read-write host mounts until updating
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2026-77179 | Symlink Escape in Docker Sandboxes virtio-fs Exposes macOS Host Files A symlink-resolution flaw (CWE-59) in the virtio-fs host server used by Docker Sandboxes on macOS allows a malicious guest VM to break out of its shared workspace. The bug occurs when the host server reopens an unlinked file from a stored path: the guest can replace a parent directory with a symlink so the reopen resolves outside the intended share. A successful exploit lets the guest read or modify arbitrary files on the macOS host as the VMM user, with potential host code execution, reflected in a CVSS 4.0 score of 9.4 (critical). This affects users running Docker's Sandboxes feature on macOS hosts, particularly where the sandbox is used to execute untrusted or AI-generated code. No public proof of concept is known and the flaw is not listed in CISA's KEV, so exploitation status is none known. Do: Update Docker Desktop on macOS to the latest release, which contains Docker's fix for the virtio-fs symlink handling, as soon as it is available to you. Until patched, disable the Sandboxes feature on macOS hosts and avoid executing untrusted or AI-generated code inside it. If the feature has been used with untrusted code, review the host for unexpected file modifications or processes running as the VMM user. | 9.4 | — |
| moderate≈tens of thousands of macOS Docker Desktop users (opt-in Sandboxes feature) | ||
| CVE-2026-79994 | TOCTOU Symlink Race in Docker Sandboxes Socket Relay Exposes Host Sockets Docker Sandboxes contains a time-of-check/time-of-use race condition (CWE-367) in the guest-to-host Unix-domain socket relay: a socket path is validated to sit inside the authorized workspace, but the host later reconnects by re-resolving that same pathname. A malicious guest can swap an intermediate directory in the path for a symlink during the window between validation and connection, tricking the host into connecting to an arbitrary AF_UNIX socket outside the shared workspace. Successful exploitation lets the guest read data from, or invoke capabilities exposed by, the targeted host-side socket, with high confidentiality and integrity impact on both the vulnerable component and subsequent systems per the CVSS 4.0 vector (8.7, local attack vector, no privileges or user interaction required). Any developer or environment using Docker Sandboxes to run semi-trusted or untrusted code is affected, since the attacker must already control code inside a sandbox. No public proof of concept exists, the flaw is not on the CISA KEV list, and no exploitation in the wild is known. Do: Apply the vendor fix as soon as Docker publishes patched builds, and check Docker's security advisory (assigned by [email protected]) for the exact fixed version of Docker Sandboxes/Docker Desktop. Until patched, treat Sandboxes as isolation-best-effort only: do not run untrusted code, and audit which host AF_UNIX sockets are reachable through the relay, since those become the blast radius of a successful race. Monitor guest workspaces for processes rapidly creating or renaming directories along shared socket paths, which is characteristic of exploitation attempts. | 8.7 | — |
| large≈100,000–1,000,000 developers (subset of Docker's roughly 20 million monthly active developers who use the opt-in Sandboxes feature) |
Full article812 words · extracted from thehackernews.com · click to collapse
Malicious code running inside a Docker Sandboxes virtual machine on macOS could escape the project directory shared into it and read or change files anywhere else on the host, Docker warns in a security announcement on September 15.
The escape runs with the rights of the host account that runs the virtual machine. The flaw, CVE-2026-77179, is rated Critical, affects versions 0.28.0 up to but not including 0.42.0 on macOS, and was fixed in 0.42.0 on September 7.
Docker Sandboxes runs each AI coding agent in its own small virtual machine with the project directory shared in. The code that could escape is whatever runs inside that machine, such as a coding agent that has been turned against its user, or anything malicious the agent installs and runs.
Docker has not reported any exploitation. CISA's added assessment on the CVE record lists exploitation as none, and the flaw is not in CISA's Known Exploited Vulnerabilities catalog as of the catalog version released on September 16.
The flaw needs malicious code inside the sandbox, and protecting the host from what an agent runs is what the sandbox is for. The agent installs packages and runs commands with sudo inside the virtual machine, and Docker's isolation documentation says the hypervisor boundary "is the isolation control, not in-VM privilege separation."
The escape goes through the virtio-fs host server, the host side of the file sharing between the Mac and the virtual machine, which followed symlinks when it reopened a removed file from a stored path, Docker said.
A guest, meaning whatever runs inside the virtual machine, could replace a parent directory with a symlink and then read or change files as the VMM user, the host account under which the virtual machine monitor runs, Docker said, "potentially leading to code execution on the host."
Docker's documentation has said since March that symlinks pointing outside the workspace, Docker's term for the shared project directory, are not followed.
The same release fixes a second flaw, CVE-2026-79994, rated High by Docker with a CVSS score of 8.7, in the relay that allows a sandbox to connect to Unix domain sockets within its authorized workspace.
The relay checked that a socket path was inside the workspace, then reconnected using the path name. A guest that replaced a directory along that path with a symlink between the check and the connection could make the host connect to any AF_UNIX socket outside the workspace, Docker said, "exposing data or host-side capabilities provided by that socket."
That flaw affects versions 0.37.0 through 0.41.9, but not 0.42.0. Docker lists the first flaw as macOS-only but states no platform for it, whereas Docker Sandboxes runs on macOS, Windows, and Linux hosts. CISA's assessment on its record also lists exploitation as none, and it is not in the KEV catalog either.
Affected Versions and What to Install
| CVE | Component | Affected versions | Platform | Docker rating |
|---|---|---|---|---|
| CVE-2026-77179 | virtio-fs host server | 0.28.0 up to but not including 0.42.0 | macOS | Critical, CVSS 9.4 |
| CVE-2026-79994 | Guest-to-host Unix socket relay | 0.37.0 up to but not including 0.42.0 | None stated | High, CVSS 8.7 |
- Update to 0.42.0 or later. As of September 17, the most recent release is 0.43.0, published on September 15.
- If you cannot update yet, use clone mode and avoid adding read-write host mounts. That is Docker's advice for both flaws.
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, and it is 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, not from reading. The repository is mounted read-only at /run/sandbox/source, and untracked files such as .env stay readable inside the sandbox, Docker's documentation says.
Docker published the CVE records and the advisory on September 15, eight days after 0.42.0 shipped.
The 0.42.0 release notes on GitHub and on Docker's documentation site do not 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 and 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 and Jurre van Bergen of ThreatNotify with finding 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.
Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
Text extracted automatically; images, tables and formatting may be missing. Original: https://thehackernews.com/2026/09/critical-docker-sandboxes-flaw-lets.html