Docker Sandboxes — the microVM that runs your coding agent could read and modify arbitrary macOS host files through a virtio-fs symlink race (CVE-2026-77179, CVSS 9.4) and reach any host Unix socket (CVE-2026-79994, 8.7); fixed in 0.42.0 alongside a D-Bus host-command bug and a cross-sandbox OAuth hijack

View raw markdownEdit on GitHub ↗

TL;DR

Docker Sandboxes is Docker's product for running AI coding agents (Claude Code, Codex, Copilot, Cursor, Devin, Gemini, Kiro, OpenCode and others) in per-agent microVMs with the project directory shared in — the isolation layer a lot of readers adopted after the run-of-agent escape bugs tracked here. Docker's docs promised "Symlinks pointing outside the workspace scope are not followed." Two advisories published 2026-09-15 show they were. CVE-2026-77179 (CVSS 4.0 9.4, Critical, CWE-59; Oren Yomtov, accomplish.ai): on macOS the virtio-fs host server followed symlinks when reopening an unlinked file from a stored path, so a malicious guest process could replace a parent directory with a symlink and "read or modify arbitrary host files as the VMM user, potentially achieving host code execution." CVE-2026-79994 (8.7, High, CWE-367; Jurre van Bergen, ThreatNotify): the guest-to-host Unix-socket relay validated a socket path and later reconnected by pathname, so a symlink swap between check and use made "the host connect to an arbitrary AF_UNIX socket outside the shared workspace." Both fixed in 0.42.0 (2026-09-07), whose release notes also close a bug where "a sandboxed process could get the daemon to open a host D-Bus transport and execute an arbitrary command on the host" and one where "a malicious sandbox could hijack another sandbox's OAuth login." The "malicious guest" is whatever your agent runs — a poisoned dependency, a prompt-injected agent, a test suite from an untrusted repo. Upgrade; until then prefer clone mode over read-write mounts.

What happened

What the product is. Docker's docs: "Docker Sandboxes run AI coding agents in isolated microVM sandboxes. Each sandbox gets its own Docker daemon, filesystem, and network." Workspaces are mounted three ways — mountless, direct read-write mount, or clone mode (host repo mounted read-only at /run/sandbox/source, agent works on a private clone). API credentials stay on the host and are injected by a proxy. The product's supported-agents page lists Claude Code, Codex, Copilot, Cursor, Devin, Docker Agent, Droid, Gemini, Kiro, OpenCode and a bare shell. It is, in other words, the sandbox this repo's agent-sandboxing guidance tells people to put beneath their agent.

CVE-2026-77179 — virtio-fs symlink follow (macOS). NVD (CNA Docker): "On macOS, the virtio-fs host server used by Docker Sandboxes improperly follows symlinks when reopening an unlinked file from a stored path. A malicious guest can replace a parent directory with a symlink, escape the shared workspace, and read or modify arbitrary host files as the VMM user, potentially achieving host code execution." The VMM runs as the developer, so "arbitrary host files as the VMM user" is the developer's home directory: ~/.ssh, ~/.aws, ~/.claude.json, shell profiles — write access to any of which is host code execution on next login. CVSS 4.0 vector AV:L/AC:L/AT:N/PR:N/UI:N with high impact on the subsequent system (SC:H/SI:H/SA:H) — the "local" is the guest, which is exactly where untrusted code runs. Affected 0.28.0 ≤ v < 0.42.0 on macOS; Docker's own docs had said since March that outside-workspace symlinks are not followed.

CVE-2026-79994 — socket-relay TOCTOU. "The guest-to-host Unix-domain socket relay in Docker Sandboxes validates that a socket path is inside an authorized workspace, but later reconnects using the pathname. A malicious guest can replace an intermediate directory with a symlink between validation and connection, causing the host to connect to an arbitrary AF_UNIX socket outside the shared workspace. This can expose data or host-side capabilities provided by the targeted socket." On a developer Mac the interesting sockets are the Docker daemon's, the SSH agent's, and the ones IDEs and password managers listen on. Affected 0.37.0 ≤ v < 0.42.0, all platforms. Fix references: docker/sailor PR 2021 and docker/sandboxes PR 5342.

The two extra fixes in 0.42.0. The release notes name two more issues without CVEs: a sandboxed process "could get the daemon to open a host D-Bus transport and execute an arbitrary command on the host," and "a malicious sandbox could hijack another sandbox's OAuth login." The second matters for teams running several agents side by side: one poisoned sandbox could take the OAuth session another agent was completing. The same release also adds Devin as a built-in agent and defaults ports to tcp4.

Exploitation. None reported; Docker's advisories and The Hacker News (2026-09-17) both say no known exploitation. The precondition — attacker code running inside the sandbox — is the normal condition for anyone using the product for what it is for.

Sources and dating. The vendor is the CNA; NVD published both CVEs 2026-09-15 and the GitHub Advisory Database mirrors them (GHSA-4x2g-7mfh-8rx6, GHSA-wq46-97v9-q386). The fix shipped 2026-09-07 in docker/sbx-releases v0.42.0 (release notes carry the CVE text); public write-ups followed on 2026-09-17 (The Hacker News). Dated here by the advisory publication.

Am I affected?

sbx version 2>/dev/null || docker sandbox version 2>/dev/null   # need >= 0.42.0
# macOS: is the host-side VMM process older than the fix? Check the release you installed:
ls -la ~/.docker/sandboxes 2>/dev/null; docker desktop version 2>/dev/null
# Which workspaces were shared read-write (direct mount) rather than clone/mountless?
sbx ls 2>/dev/null

If a sandbox ran untrusted code (an unreviewed repo's tests, a dependency install, an agent that read attacker-controlled content) on a vulnerable version, assume the host user's files were readable and possibly modified.

If you are affected

Prevention

  • Prefer clone mode or mountless workspaces; Docker's own guidance for direct mounts is to "treat sandbox-modified workspace files the same way you would treat a pull request from an untrusted contributor."
  • A sandbox is a mitigation, not a boundary; keep secrets off the host user's disk where the VMM runs and lean on the credential proxy. prevention/agent-sandboxing.md, prevention/credential-hygiene.md.

Update — 2026-09-22: v0.45.0 (2026-09-21) fixes a credential-revocation gap in the proxy and closes a reverse-DNS policy bypass — no CVE, release-note lines only

Docker Sandboxes v0.45.0 (released 2026-09-21) carries a one-item "Security" section: "Fixed an issue where revoking a sandbox's OAuth or API-key credential could leave its running proxy authorized until the sandbox was recreated." In other words, the credential proxy this file recommends leaning on kept honouring a credential after the user revoked it, for as long as the sandbox stayed up — revocation was not revocation until recreate. The same release's networking notes say reverse-DNS lookups are now restricted to policy-authorised IPs, closing "the previous policy bypass" (a sandboxed process could previously resolve names the egress policy was meant to block, per the note's own framing). Neither fix has a CVE or an advisory-tab entry, and no vulnerable version range is stated — same pattern as Codex's Heapjack release-note line. If you rotated an agent's provider credential while its sandbox was running on < 0.45.0, assume the old one worked until the sandbox was recreated; upgrade and recreate long-lived sandboxes. Pre-releases v0.45.1-rc1 and v0.46.0-rc2 were published 2026-09-22 with no security notes.

Update — 2026-09-30: v0.46.0 (2026-09-28) carries the credential-revocation fix and the reverse-DNS restriction as release-note lines again, plus bulk credential revocation; 0.47.0-rc1/rc2 (09-28 / 09-30) add nothing security-labelled

The sbx-releases page on 2026-09-30 lists v0.46.0 (2026-09-28) as latest stable with a security section repeating the 0.45.0 item — "revoking a sandbox's OAuth or API-key credential could leave its running proxy authorized" — alongside a new bulk credential-revocation capability and the network-policy tightening "Reverse-DNS lookups are now allowed only for destination IPs already authorized by policy." No CVE is attached to either. v0.47.0-rc1 (2026-09-28) and rc2 (2026-09-30) are pre-releases with no security note. The upgrade advice stands: ≥ 0.46.0, and revoke credentials from the credential store rather than assuming a deleted key is dead inside a running sandbox.

Sources