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. Update 2026-11-05: a third symlink finding, CVE-2026-103916 (sbx cp follows a workspace symlink on the host side, 0.28.0 before 0.51.0), is fixed only in 0.51.0; see the Update below.

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 for the virtio-fs and socket bugs; >= 0.51.0 for the sbx cp symlink follow (CVE-2026-103916, Update 2026-11-05)
# 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.

Docker's CNA record CVE-2026-103916 (published 2026-11-03 16:19 UTC, CVSS 4.0 8.4 AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H) says sbx cp "does not safely confine host-side paths to a shared workspace": a malicious sandbox can create or replace a workspace symlink so that a later user-initiated copy reads a host file outside the workspace into the sandbox, or writes sandbox-controlled data to a host path outside the workspace with the invoking user's permissions. Affected 0.28.0 before 0.51.0. The record's references are the Sandboxes docs and the v0.51.0 release; there is no GHSA. This is the third symlink finding in the product after CVE-2026-77179 and CVE-2026-79994 above, and the escape is on the host side of the copy rather than in virtio-fs.

Endor Labs (Peyton Kennedy, 2026-11-03) describes the mechanism: sbx cp resolves symlinks in the host paths it receives outside the sandbox's allowlist, and the -L flag guards only the last path component, so an agent that controls a workspace can plant a symlink at a parent component. The post demonstrates a read (host file pulled into the sandbox; needs a guessable filename and an operator-run copy) and a write (host file overwritten with sandbox-authored content), and says the write "could lead to code execution" through a shell profile or a git hook as reasoning, not as a demonstration. Timeline per the post: the fix was first scheduled for v0.48.0 on 2026-10-13, Docker then found that fix incomplete, and the final fix shipped in v0.51.0 on 2026-11-03. The report date is not given. The post also cites CVE-2026-17106 (Docker CNA, 2026-08-18), an earlier tar-extraction link-following bug in moby/go-archive that the record lists as affecting Docker Sandboxes before 0.38.0 beside Desktop, Engine, CLI and Compose, which this file had not recorded.

The releases page (read 2026-11-05) shows v0.51.0 (03 Nov) with "sbx cp blocks symbolic links in mounted directories from escaping onto other host paths", a Windows substituted-drive escape block, same-account verification of daemon sockets on Unix, sbx kit sign no longer running configured Git filter drivers, and network-policy commands rejecting empty --sandbox values; and v0.50.0 (26 Oct) with "sbx cp rejects symlinks that escape a workspace when reached through alternate host paths, such as junctions or Linux bind mounts", host Git commands no longer running programs a sandbox configures through the workspace's .git directory, helpers running only from trusted system locations, MCP OAuth requests blocking cross-origin credential redirects, Windows named-pipe owner checks, and environment MCP commands requiring approval on the host. None of the release notes carries a CVE id. The Hacker News ThreatsDay roundup of 2026-11-05 lists the Endor Labs post as its item 9.

Action: upgrade sbx to 0.51.0 or later (sbx version; the self-update path is the one the 0.50.0 notes mention), and until then do not run sbx cp out of a workspace an untrusted agent has written to. The -L flag is not a mitigation.

Update — 2026-11-07: CVE-2026-121614, host-side Git runs a program the sandbox configured in the workspace repository (0.31.0 before 0.50.0, fixed 2026-10-26); ZDI-26-894 published 2026-11-06

Docker's CNA record CVE-2026-121614 (published 2026-11-03, CVSS 4.0 7.1 AV:L/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H, title "Docker Sandboxes host Git executes repository-controlled programs") says versions 0.31.0 before 0.50.0 "do not neutralize repository-controlled Git configuration when running certain host-side Git commands": an attacker who can modify a host repository's Git configuration, "for example through a direct-mode sandbox with the repository mounted read-write, can configure core.fsmonitor or another Git setting that invokes an external program", and Git runs it "during a later clone-mode fetch or, starting in version 0.39.0, an sbx kit push initiated by the user", on the host, with the invoking user's permissions, outside the microVM. ZDI-26-894 (published 2026-11-06, CVSS 3.1 7.8 AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, credit Nitesh Surana of TrendAI Research) is the same finding, reported to Docker on 2026-08-28; its description names sandbox creation in clone mode and says "Docker has issued an update to correct this vulnerability." The two scores come from two providers on two CVSS versions and the same description; this file keeps critical for the September bugs and rates this one high.

The fix is in v0.50.0, dated 26 Oct on the releases page, whose Security section reads "Host Git commands no longer run programs configured by a sandbox through the workspace repository's .git directory"; the page prints no CVE and does not name fsmonitor or clone mode. The record's range therefore ends one release before the 0.51.0 sbx cp fix in the 2026-11-05 update above, and an installation that upgraded for that one has this one too. The mechanism is the GitSpawn class tracked in the git-config agent RCE cluster: the sandbox is the untrusted party, the workspace .git/config is the carrier, and the host's own git invocation is the executor. A direct-mode sandbox with a read-write mount is the stated path to the configuration; the record also says the read-only host mount given to a clone-mode sandbox does not prevent the later host-side command from reading the configuration.

Action: sbx version; 0.31.0 up to 0.49.x runs host Git against sandbox-written configuration (the record starts the range at 0.31.0), and 0.28.0 up to 0.50.x has the sbx cp symlink bug as well. Until upgraded, do not run sbx kit push or create a clone-mode sandbox from a repository an untrusted sandbox has written to with a read-write mount.

Sources