Docker Sandboxes CVE-2026-77179

Requires the attacker to already control a guest workload running inside a Docker Sandbox on macOS (versions 0.28.0 through 0.41.x) with a shared workspace bind-mount served over the virtio-fs host server - this is the default for 'sbx run', which mounts the current directory. The specific primitive is replacing a parent directory of a workspace file with a symlink so the virtio-fs server follows it when reopening an unlinked file from a stored path. Limiting factors: exploitation is LOCAL to the host (attacker must have code execution in the guest first, e.g. an untrusted agent/repo), it is macOS-specific, it depends on winning a directory-swap timing race (SSVC Automatable:no), and impact is bounded by the privileges of the VMM user rather than root. Not exploitable against a sandbox created without a workspace bind mount.

This is a genuine sandbox-escape leading to host compromise, but the raw 9.4 CVSS 4.0 score should be read alongside the other signals rather than at face value. The vendor-supplied CVSS 4.0 vector begins with AV:L, correctly reflecting that the attacker is not a remote internet actor but a malicious guest already executing inside a Docker Sandbox VM on a macOS host; AC:L and PR:N/UI:N indicate that once you control the guest, no host credentials or user interaction are required to trigger the symlink race. The VC/VI/VA:H plus SC/SI/SA:H combination models the crux of the bug well: the vulnerable virtio-fs component is fully compromised and the impact propagates to the subsequent system (host files, potentially host code execution as the VMM user). Counterbalancing signals lower the urgency: SSVC returns Exploitation:none (no observed exploitation) and Automatable:no (the parent-directory-replacement-with-a-symlink race is not a spray-and-pray primitive), even though Technical Impact:total. There is no CISA KEV listing, no public POC referenced, and no EPSS score provided - consistent with a freshly-disclosed, vendor-reported (Docker) issue rather than an actively exploited one. Net: real and worth patching promptly for anyone running untrusted or agent-driven workloads in Docker Sandboxes, but it is a privilege-boundary/isolation escape requiring an already-hostile guest, not a wormable internet-facing RCE. Note the vector is LOCAL to the host despite the 'RCE' tag - 'remote' only applies in the sense that the guest workload may itself have been reached remotely.

An attacker who can run code inside a Docker Sandbox (e.g. via a malicious AI agent task, untrusted repository, or compromised build step) replaces a parent directory of a file under the shared workspace with a symlink pointing outside the workspace. When the virtio-fs host server reopens the unlinked file from its stored path, it follows the attacker's symlink and reads or writes arbitrary files as the VMM user on the macOS host, potentially escalating to host code execution. No public exploit code is identified at time of analysis, and the TOCTOU-style directory-swap race makes reliable exploitation non-trivial (SSVC Automatable:no).