1. Executive summary
Docker disclosed CVE-2026-77179 on 15 September 2026, a critical sandbox-escape flaw (CVSS 9.4, CWE-59) in Docker Sandboxes on macOS. Malicious code inside a sandbox VM, typically an AI coding agent or something it installed, can escape the shared project directory and read or modify files anywhere on the host, running with the rights of the host account that operates the virtual machine monitor. The escape works through the virtio-fs host server following a symlink when it reopens a removed file from a stored path, and Docker states it can lead to code execution on the host. The flaw affects versions 0.28.0 up to but not including 0.42.0, was fixed in 0.42.0 on 7 September, and is not in the CISA KEV catalog; CISA's assessment lists exploitation as none. The same 0.42.0 release fixes a second flaw, CVE-2026-79994 (CVSS 8.7, High), a time-of-check-to-time-of-use symlink race in the workspace socket relay that lets a guest redirect the host to arbitrary AF_UNIX sockets outside the workspace. For EMEA financial services firms running AI coding agents on developer Macs, the exposure is developer workstations holding source code, credentials, and secrets, not production infrastructure.
2. Regulatory framing
| Article | Trigger (the fact in this item) | Practical impact |
|---|---|---|
| DORA Art. 24: digital operational resilience testing — general requirements | The sandbox boundary is the sole isolation control for untrusted AI-agent code, and Docker's own documentation states the hypervisor boundary "is the isolation control, not in-VM privilege separation"; the escape defeats that boundary | Include Docker Sandboxes and AI-agent sandboxing in resilience testing scope: verify sandbox escape paths, test that agent workloads cannot reach host files, and validate clone-mode configurations as part of the testing programme |
| DORA Art. 28: ICT third-party risk — general principles | Docker Sandboxes is a third-party tool executing untrusted third-party code (AI agents and their package installs) on developer endpoints, and the vendor's release notes did not name either CVE as of 17 September | Track the tool in the ICT third-party inventory, require version pinning at 0.42.0 or later, and factor the vendor's delayed CVE disclosure into third-party risk assessment |
No NIS2 or UK NIS article is engaged by the specific facts of this item. The flaw is a vendor vulnerability disclosure with no reported exploitation, not an incident affecting network and information systems.
3. Technical analysis & attack chain
Docker Sandboxes runs each AI coding agent in its own small virtual machine on macOS, with the project directory shared in via virtio-fs. The design assumption is that the hypervisor boundary is the isolation control; in-VM privilege separation is explicitly not, and agents routinely install packages and run commands with sudo inside the VM. CVE-2026-77179 breaks that boundary.
Confirmed attack chain:
- Malicious code is present inside the sandbox VM. Realistic paths are an AI coding agent turned against its user, or any malicious package or command the agent installs and runs during a task.
- The guest replaces a parent directory of a file the virtio-fs host server has a stored path for with a symlink pointing outside the workspace, and removes the original file.
- The virtio-fs host server, the host side of the file sharing between the Mac and the VM, reopens the removed file from the stored path and follows the symlink.
- The guest reads or modifies files anywhere on the host, running as the VMM user, the host account under which the virtual machine monitor runs. Docker assesses this can lead to code execution on the host.
The mechanism is a symlink-following flaw (CWE-59, improper link resolution before file access) in the host-side virtio-fs server. It contradicts Docker's own documentation, which has stated since March that symlinks pointing outside the workspace are not followed. Affected range is 0.28.0 up to but not including 0.42.0, macOS only per Docker's CVE record. Fixed in 0.42.0, released 7 September; the most recent release as of 17 September is 0.43.0, published 15 September.
The second flaw in the same release, CVE-2026-79994 (CVSS 8.7, High per Docker), affects the relay that lets a sandbox connect to Unix domain sockets within its authorized workspace. The relay validated that a socket path was inside the workspace, then reconnected using the path name. A guest that swapped a directory along that path for a symlink between the check and the connection could make the host connect to any AF_UNIX socket outside the workspace, exposing data or host-side capabilities provided by that socket. It affects versions 0.37.0 through 0.41.9 and does not affect 0.42.0. Docker lists the first flaw as macOS-only but states no platform for this one, even though Docker Sandboxes runs on macOS, Windows, and Linux hosts; treat the platform scope of CVE-2026-79994 as unconfirmed. CISA's assessment on its record also lists exploitation as none, and it is not in the KEV catalog.
Two caveats on sourcing. First, the technical detail here is single-sourced: it rests on Docker's security announcement and CVE records as reported by The Hacker News on 17 September, and Docker's 0.42.0 release notes on GitHub and its documentation site did not name either CVE as of that date. Second, the 0.42.0 release notes list a separate fix for "a sandboxed process could get the daemon to open a host D-Bus transport and execute an arbitrary command on the host"; the source text is truncated before Docker's full description, so we cannot confirm whether that fix relates to either CVE. No exploitation of either flaw has been reported by Docker or CISA.
4. Mitigation & containment
P1, within 24 hours:
- Inventory developer macOS endpoints for Docker Sandboxes and identify any install in the 0.28.0 to 0.41.x range. Both CVEs are absent from KEV and unexploited, but the affected population is small and the fix is a version bump.
- Update to 0.42.0 or later; 0.43.0 is current as of 17 September. This remediates both CVE-2026-77179 and CVE-2026-79994.
- Until patched, block or suspend use of
sbx runwith default read-write sharing of the current directory on affected versions. The default shares the working directory into the sandbox with read and write access.
P2, within 72 hours:
- Where patching is delayed, switch sandboxes to clone mode and remove read-write host mounts. Docker gives this advice for both flaws. Clone mode is set at sandbox creation and only works for Git repositories, so existing sandboxes must be removed and recreated with
--clone. - Note the limits of clone mode: it protects the repository from modification, not from reading. The repository is mounted read-only at
/run/sandbox/source, and untracked files such as.envremain readable inside the sandbox. Move secrets out of the working tree or exclude them before running agents. - Review what the VMM user account can reach on developer Macs: SSH keys, cloud credentials, browser profiles, and source trees outside the workspace are all readable and modifiable in a successful escape.
P3, within 7 days:
- Add Docker Sandboxes version checks to endpoint baselining so pre-0.42.0 installs are flagged automatically.
- Update AI-agent usage policy: agents run with sudo inside the VM by design, so treat everything an agent installs or executes as untrusted code whose blast radius is the host account, not the VM.
- Track Docker's disclosure practice: the CVEs were published on 15 September, eight days after 0.42.0 shipped, and were absent from the release notes as of 17 September. Do not rely on release notes alone for this vendor's vulnerability signal.
5. Indicators of compromise
No indicators of compromise available in the source material. The flaw is a vulnerability disclosure with no reported exploitation, and the sources contain no hashes, domains, IPs, or other atomic indicators.
6. Detection
Insufficient indicators to author detection rules. The sources describe a vulnerability mechanism and vendor remediation but contain no strings, command lines, file artefacts, or log events of an exploit in the wild.
CVE assessment
1 referenced CVE — 1 critical (CVSS ≥ 9.0)
| CVE | CVSS | Exploited | EPSS | Summary |
|---|---|---|---|---|
| CVE-2026-77179 | 9.4 Critical | — | 0% | On macOS, the virtio-fs host server used by Docker Sandboxes improperly follows symlinks when reopening an unlinked file from a… |
7. Sources
- The Hacker News, "Critical Docker Sandboxes Flaw Lets Malicious Guest Code Read and Modify macOS Host Files", https://thehackernews.com/2026/09/critical-docker-sandboxes-flaws-lets.html, 2026-09-17
8. Adverse Trace position
We assess CVE-2026-77179 as a critical-severity flaw (CVSS 9.4) with a credible and specific escape mechanism, but with no observed exploitation: it is not in CISA KEV, CISA lists exploitation as none, and EPSS is at 0%. The realistic attack path for a financial services client is a malicious or manipulated package installed by an AI coding agent inside a sandbox on a developer Mac, escalating to read and modify host files as the VMM user, which places source code, SSH keys, and cloud credentials at risk; the second flaw extends that reach to arbitrary host AF_UNIX sockets. The exposure is concentrated in developer endpoint estates rather than production systems, and the fix is straightforward, so we rate the practical client impact as moderate and driven by patch coverage and secrets hygiene on developer machines. All technical detail is single-sourced to Docker's announcement as reported by The Hacker News, and the platform scope of CVE-2026-79994 is unconfirmed; verify both against Docker's CVE records before enforcing version policy. We will monitor for exploitation reports, KEV listing, or a public proof of concept and will reissue this advisory if any of those appear.
Published via PulseTrace — Adverse Trace threat intelligence.