Docker has closed two flaws in Docker Sandboxes, the isolated environment it ships for running AI agents and other untrusted code, that let whatever runs inside the sandbox reach back out and touch files on the host Mac. The more serious of the two is scored 9.4 out of 10.
The fix is version 0.42.0, which Docker published on 7 September. The two CVE records only reached the US National Vulnerability Database on 15 September, and Peru's national digital security centre, the CNSD, relayed them in an integrated security alert dated 17 September. That lag is why the pair is circulating now rather than when the patch shipped.
The same trick, played twice
Both bugs are one idea in two places. A symlink is a file that is really just a signpost pointing somewhere else, and in each case the host checks that a path leads somewhere safe, then follows that same path again a moment later. The guest gets to move the signpost in between.
In CVE-2026-77179, Docker's own description says the virtio-fs host server on macOS improperly follows symlinks when reopening an unlinked file from a stored path. A malicious guest replaces a parent directory with a symlink, escapes the shared workspace, and can then read or modify arbitrary host files as the user running the virtual machine monitor, potentially achieving code execution on the host. Docker assigned the identifier itself and scores it 9.4 under version 4 of the CVSS scale.
CVE-2026-79994, which Docker rates 8.7, is the same race run against the relay that carries Unix socket traffic from the guest to the host. The relay confirms that a socket path sits inside an authorized workspace, then reconnects using the pathname rather than the thing it just validated. Swap an intermediate directory for a symlink between those two steps and the host connects to an arbitrary socket outside the workspace, which Docker says can expose data or host-side capabilities.
The wall was the whole product
An escape hurts more here than an ordinary bug in a developer tool would, because the isolation is the point of the thing. Docker Sandboxes exists so that code nobody has vetted, increasingly code an AI agent wrote or fetched a minute ago, can run on a laptop without the laptop being at stake. Both flaws are specific to macOS. The CNSD alert gives the affected range as 0.28.0 up to 0.42.0.
Neither Docker nor the CVE records report any exploitation, and no proof-of-concept is public. It is the second host-reaching Docker issue IntelFusions has covered in five weeks, after a container escape in August, and the two are unrelated bugs in different products.
Move to 0.42.0, Macs first
Update Docker Sandboxes to 0.42.0 or later. Docker names no workaround and presents the release itself as the fix. Where a fleet-wide update will take time, the CNSD advises prioritising macOS machines that actually run untrusted code, using clone mode, and cutting the host resources a sandbox shares down to the minimum.
Sandboxes are being handed more to do this year, and more of what they hold at arm's length is now written by something that never reads its own output. That makes the strength of the wall a question worth asking more than once.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.