A critical security vulnerability in Docker Sandboxes could allow malicious code running inside a sandboxed virtual machine to escape its isolation and access or modify files on the underlying macOS host.
Tracked as CVE-2026-77179, the vulnerability carries a CVSS score of 9.4 and affects Docker Sandboxes versions 0.28.0 through 0.41.x on macOS. Docker addressed the issue in version 0.42.0, released on September 7, 2026.
Sandbox Escape Could Compromise Host Files
Docker Sandboxes are designed to isolate AI coding agents and other potentially untrusted workloads inside lightweight virtual machines. The user’s project directory is normally shared with the sandbox so the agent can work with project files.
The newly disclosed vulnerability undermines that isolation under certain conditions.
According to Docker, malicious code running inside the virtual machine could exploit the virtio-fs host server, which manages file sharing between the guest environment and the host. The flaw involves the handling of symbolic links when a previously removed file is reopened using a stored path.
An attacker-controlled process inside the sandbox could manipulate a parent directory and replace it with a symbolic link. This could redirect file operations outside the intended project directory and potentially allow access to files belonging to the host operating system.
Because the operation occurs with the privileges of the account running the virtual machine monitor, a successful attack could potentially lead to further compromise of the macOS host.
Malicious AI Agents Could Increase the Risk
The vulnerability is particularly relevant to Docker’s AI-focused sandboxing environment. While the flaw does not allow an attacker to compromise a host from nowhere, malicious code must first be executing inside the sandbox.
That code could originate from a compromised coding agent, a malicious package, an injected instruction, or another piece of software introduced into the virtual machine.
Docker’s security documentation treats the virtual-machine boundary as the primary isolation mechanism. Applications and agents operating inside the sandbox can have significant privileges within the guest environment, making protection at the hypervisor boundary particularly important.
Docker said it has not identified exploitation of CVE-2026-77179. The vulnerability also was not listed in CISA’s Known Exploited Vulnerabilities catalog as of the September 16 catalog update.
Second Docker Sandboxes Vulnerability Fixed
Docker’s 0.42.0 update also resolves another security issue, CVE-2026-79994, affecting the mechanism used to connect sandbox workloads to Unix domain sockets on the host.
The vulnerability has a CVSS score of 8.7 and is classified as High severity by Docker.
The affected relay first checked whether a socket path was located inside the authorized workspace. However, a malicious process could potentially alter a directory in the path and replace it with a symbolic link before the connection was established.
This race condition could cause the host to connect to a Unix socket located outside the permitted workspace. Depending on the socket involved, this could expose sensitive information or provide access to host-side capabilities.
CVE-2026-79994 affects Docker Sandboxes versions 0.37.0 through 0.41.9 and is fixed in version 0.42.0.
Docker Users Urged to Upgrade
Docker recommends upgrading Docker Sandboxes to version 0.42.0 or later. As of September 17, the newest available release was 0.43.0, published September 15.
For users who cannot immediately upgrade, Docker recommends using clone mode and avoiding additional read-write mounts from the host.
Clone mode is available for projects stored in Git repositories. It mounts the repository as read-only inside the sandbox, helping prevent modifications to the source repository.
However, clone mode does not completely prevent data exposure. Files that are not tracked by Git, including potentially sensitive files such as .env files, can still be readable from within the sandbox.
Users should therefore avoid assuming that clone mode provides complete protection for sensitive host information.
Vulnerability Disclosure Details
Docker published its security advisory and CVE information on September 15, shortly after the security fixes became available.
The company credited Oren Yomtov of accomplish.ai with discovering CVE-2026-77179 and Jurre van Bergen of ThreatNotify with identifying CVE-2026-79994.
Docker’s release documentation did not initially associate either CVE with the 0.42.0 release. The release notes nevertheless included several sandbox security fixes, including one involving a sandboxed process potentially causing the daemon to open a host D-Bus transport and execute commands on the host.
The CVE record for CVE-2026-79994 also initially contained an incorrect first-fixed-version reference. Docker subsequently corrected the information to identify version 0.42.0 as the fixed release.
Earlier Docker Sandbox Security Concerns
The latest disclosures follow earlier research highlighting security risks surrounding AI coding agents operating in Docker-based environments.
In April 2026, security researchers demonstrated how a prompt-injected coding agent running inside a Docker sandbox could potentially be manipulated into exploiting another Docker Engine vulnerability to attack its host.
The incidents highlight an important security challenge as AI coding agents increasingly receive permission to install software, execute commands and interact with development environments.
Security Recommendations
Docker Sandbox users should:
- Upgrade to Docker Sandboxes 0.42.0 or later.
- Prefer the latest available release where possible.
- Use clone mode if an immediate upgrade is not possible.
- Avoid unnecessary read-write host mounts.
- Review sensitive files that may be accessible from sandbox environments.
- Treat third-party packages and AI-generated code as potentially untrusted.
- Monitor systems for unexpected access to host files or services.
The vulnerabilities demonstrate that virtualization and sandboxing mechanisms must be kept updated because weaknesses in the host-side components can potentially undermine the isolation they are designed to provide.
