The disclosure of CVE-2026-77179 and CVE-2026-79994 in Docker Sandboxes highlights an increasingly important cybersecurity challenge as organisations adopt AI-powered coding assistants: the security of an AI agent depends not only on what the agent is instructed to do, but also on the strength of the environment containing the code it executes. Docker Sandboxes is designed to run coding agents inside isolated microVMs, allowing them to install packages, execute commands and modify project files without gaining unrestricted access to the developer's host system. However, the newly disclosed vulnerabilities demonstrate how implementation weaknesses in the mechanisms connecting a sandbox to its host can undermine that intended isolation. The critical vulnerability may allow malicious guest code to access or modify files outside the authorised workspace on macOS, while a second vulnerability can expose host-side capabilities through improper handling of Unix domain socket paths.

The most serious issue, CVE-2026-77179, is a critical vulnerability with a CVSS score of 9.4. It affects Docker Sandboxes versions 0.28.0 through 0.41.9 on macOS and resides in the virtio-fs host server responsible for sharing files between the virtual machine and the host. Under normal operation, an AI coding agent receives access to a specified project directory so it can inspect source code, modify application files and perform development tasks. The security boundary is intended to prevent the agent from accessing files outside that explicitly shared workspace. The vulnerability breaks this assumption because malicious code running inside the guest can manipulate filesystem paths in a way that causes the host-side file-sharing service to follow a symbolic link outside the authorised directory. 

The underlying weakness involves a subtle but dangerous filesystem behaviour. The virtio-fs host server could reopen a previously unlinked file using a stored path. A malicious guest could replace a parent directory along that path with a symbolic link before the reopening operation occurred. When the host server subsequently followed the modified path, it could access a location outside the original workspace. This creates a path-manipulation vulnerability in which a filesystem operation that initially appears confined to an authorised directory can be redirected toward another location. Because the operation is performed through the host-side virtual machine infrastructure, the malicious guest may obtain access to files using the privileges of the host account running the virtual machine monitor. 

The potential consequences are particularly concerning because developer workstations frequently contain far more sensitive information than the project directory shared with an AI assistant. SSH keys, cloud authentication material, source-code repositories, application configuration files, development certificates and other credentials may reside elsewhere in a developer's home directory. If malicious code inside a vulnerable sandbox can read files beyond the intended workspace, it may potentially access sensitive information that the developer never authorised the AI agent to inspect. The ability to modify arbitrary accessible host files introduces additional risks, including tampering with development tools, modifying configuration files or creating conditions that could lead to code execution on the host. The actual consequences depend on the host account's permissions and the specific files accessible to it, rather than implying that the vulnerability automatically provides unrestricted root access to macOS. 

The attack conditions are important to understand. CVE-2026-77179 does not mean that simply installing Docker Sandboxes immediately compromises a computer. Exploitation requires malicious code to execute inside an affected sandbox. That code could originate from a compromised dependency, an untrusted package, a malicious script within a repository or an AI coding agent that has been manipulated into executing attacker-controlled instructions. This distinction is central to the threat model because Docker Sandboxes is specifically designed to contain potentially unsafe operations performed by coding agents. The vulnerability becomes serious precisely because it weakens a security boundary that users rely upon when allowing an agent to run software they would otherwise hesitate to execute directly on their own computers. 

The connection to AI coding agents makes the issue particularly relevant to modern development environments. These agents may autonomously inspect repositories, install packages, execute build commands, run tests and invoke command-line utilities while attempting to complete a legitimate task. An attacker who controls part of the material encountered by an agent may attempt to influence its behaviour through malicious repository instructions, compromised dependencies or other untrusted content. If the agent subsequently executes malicious code inside a vulnerable sandbox, the filesystem escape could potentially expand the impact from compromise of the isolated development environment to exposure of resources on the host. However, Docker has not reported an observed attack chain combining prompt injection with this vulnerability, so such a scenario should be understood as a plausible risk rather than a confirmed incident. 

The second vulnerability, CVE-2026-79994, affects a different boundary between the sandbox and its host. Rated High with a CVSS score of 8.7, it affects versions 0.37.0 through 0.41.9 and concerns the guest-to-host Unix domain socket relay. Docker Sandboxes includes a mechanism allowing authorised connections to Unix sockets located within the permitted workspace. The vulnerable implementation checked whether a socket path was inside that workspace but subsequently established the connection using the pathname. A malicious guest could replace an intermediate directory with a symbolic link between those two operations, potentially redirecting the host into connecting to a Unix socket outside the authorised directory. 

This is an example of a time-of-check-to-time-of-use vulnerability, commonly called a TOCTOU race condition. A security check may correctly determine that a resource is permitted at one moment, but the underlying filesystem state can change before the resource is actually accessed. When the program later relies on the previously validated pathname, the object it reaches may no longer be the same one that passed the security check. In the Docker Sandboxes vulnerability, this could allow malicious guest code to interact with host-side Unix sockets that were never intended to be accessible from the sandbox. 

Unix domain sockets deserve particular attention because they frequently provide access to local services and administrative interfaces. Depending on the service associated with a socket, access may expose sensitive information or provide capabilities that would otherwise be unavailable to an isolated process. For example, local management sockets may allow software to issue commands to services operating with different privileges. CVE-2026-79994 does not establish that every host socket can automatically be used to gain root privileges or control the host Docker daemon, but it demonstrates why exposing unintended socket connections can undermine the security model of an isolated execution environment. 

Together, the two vulnerabilities illustrate a common architectural weakness: checking whether a resource is authorised is insufficient if the program subsequently accesses that resource through a mutable pathname. Symbolic links, directory replacement and filesystem race conditions can cause the resource reached during execution to differ from the one originally validated. Secure filesystem operations need to preserve the relationship between the object that was checked and the object that is ultimately accessed. This principle applies not only to AI sandboxes but also to container runtimes, archive extraction utilities, file-upload systems, backup software and privileged services handling files controlled by less-trusted users. 

The disclosure also demonstrates why sandbox isolation cannot be evaluated solely by the presence of a virtual machine. Docker Sandboxes uses microVMs with separate kernels to isolate coding agents from the host environment, and this provides an important security boundary. However, practical development workflows require controlled connections across that boundary so agents can read source code, modify project files and interact with approved services. Each shared directory, proxy, credential broker and socket relay becomes a carefully controlled exception to isolation. An implementation defect in any of these bridging mechanisms may create a path around protections that otherwise function correctly at the hypervisor level. 

Another important distinction concerns the privileges available to the AI agent inside its sandbox. Docker permits agents to install packages and execute commands using elevated privileges within the microVM. This is part of the intended development workflow, rather than proof that the agent already possesses host privileges. Docker's security model relies primarily on the virtual machine boundary to prevent those guest privileges from extending into the host. Consequently, vulnerabilities affecting the host-side sharing services deserve particular attention because they can potentially allow actions originating from a highly privileged guest environment to influence resources outside the virtual machine. 

The default workspace-sharing configuration adds practical relevance to the findings. When users start an agent through the normal sandbox workflow, Docker Sandboxes can mount the current project directory with read-write permissions so changes made by the agent appear directly in the developer's working tree. This improves productivity, but it also means that agent-generated modifications to build scripts, configuration files and project dependencies can affect subsequent operations performed outside the sandbox. Even after the disclosed vulnerabilities are fixed, organisations should remember that intentionally shared files remain within the agent's authorised reach. Isolation prevents access to resources outside the defined boundary; it does not automatically make every modification within the shared workspace trustworthy. 

Docker addressed both vulnerabilities in version 0.42.0, released on September 7, 2026. The company subsequently published its security advisory on September 15. Administrators and developers using affected installations should upgrade to version 0.42.0 or later. At the time of the September 17 reporting, version 0.43.0 was the most recent release. Organisations should verify the actual version installed on developer workstations, build environments and centrally managed systems rather than assuming that a successful application launch indicates that the relevant security fixes have been applied. 

Where an immediate upgrade is not possible, Docker recommends using clone mode and avoiding additional read-write host mounts. Clone mode allows the agent to work on a private copy of a Git repository rather than directly modifying the original host working tree. This reduces the risks associated with allowing an agent to make unrestricted changes to a shared development directory. However, the distinction between protection against modification and protection against disclosure is important: Docker's documentation states that the repository remains readable through a read-only mount, including untracked files such as .env. Organisations should therefore avoid placing secrets inside repositories or shared workspaces simply because those files are excluded from version control. 
Clone mode must also be configured when the sandbox is created, meaning that existing sandboxes may need to be removed and recreated to obtain the intended configuration. A team that updates its operating procedures without checking already provisioned environments may continue running sandboxes with older, less restrictive sharing arrangements. Security controls should be verified against the actual running configuration, and organisations should establish standard deployment profiles that define which host directories, network destinations and credentials an AI agent is permitted to access.

The incident introduces a particularly important lesson about secrets management. Development environments commonly contain cloud API keys, deployment credentials, database connection strings and access tokens required for building or testing applications. If these credentials are placed directly in files accessible to an agent, sandbox isolation cannot protect them from that agent because access has been explicitly granted. Docker provides host-side credential proxying so supported credentials can be inserted into authorised outbound requests without exposing their raw values inside the microVM. Organisations should use appropriate credential isolation, narrowly scoped tokens and short-lived authentication material rather than allowing coding agents unrestricted access to sensitive environment files. 

Network controls remain another essential defensive layer. A malicious agent or compromised dependency that obtains access to sensitive information may attempt to transmit it to an external destination. Restricting outbound connections to approved services can reduce opportunities for data exfiltration, although permitted destinations and legitimate development infrastructure must still be evaluated carefully. Security teams should review sandbox network policies, monitor unusual outbound connections and avoid broad allow rules that grant more connectivity than an agent actually needs. These controls complement filesystem isolation but cannot repair the disclosed vulnerabilities themselves. 

The enterprise implications extend beyond individual developer laptops because AI coding agents are increasingly incorporated into automated software-development workflows. Agents may operate within CI/CD pipelines, generate code changes, install dependencies and interact with repositories containing proprietary intellectual property. If an organisation assumes that placing an agent inside a sandbox eliminates the need for further controls, it may overlook risks associated with shared source code, build artifacts, trusted credentials and external integrations. A secure deployment model should treat the agent's instructions, retrieved content, dependencies and generated files as potentially untrusted until appropriate controls and review processes establish otherwise. 

Monitoring and incident response also require special consideration. Docker had not reported exploitation of either vulnerability at the time of disclosure, and neither was listed in CISA's Known Exploited Vulnerabilities catalog in the reporting reviewed. Organisations should therefore avoid presenting these vulnerabilities as confirmed attack campaigns. Nevertheless, a developer environment that executed untrusted code while running an affected version may warrant closer examination if suspicious activity is observed. Investigators should assess unexpected changes outside the authorised project directory, unusual host-side process execution, unauthorised access to sensitive files and suspicious network communication. Any investigation should consider the specific privileges of the host account and the actual filesystem and socket resources accessible in that environment. 

The broader lesson is that AI agent security must be based on clearly defined and independently enforced trust boundaries. An AI coding assistant may be performing an authorised task while encountering malicious content from a compromised repository or software package. A sandbox should ensure that any resulting unsafe execution remains confined to the intended environment. The Docker vulnerabilities demonstrate how a flaw in the mechanisms providing legitimate access to host resources can weaken that confinement, even when the virtual machine itself continues operating as designed. Security teams therefore need to evaluate the entire execution architecture, including filesystem sharing, socket forwarding, credential handling, network access and host-side management services. 

Ultimately, CVE-2026-77179 and CVE-2026-79994 demonstrate that the security of AI-assisted development depends on far more than placing an agent inside a container or virtual machine. The critical macOS filesystem escape could allow malicious guest code to access files outside its permitted workspace and potentially achieve host code execution, while the Unix socket vulnerability could expose capabilities associated with unauthorised host services. Docker has provided corrected releases, and organisations should prioritise upgrading affected installations, reducing shared-resource exposure and reviewing their AI-agent deployment policies.

Malicious code running inside a Docker Sandboxes virtual machine on macOS could escape the project directory shared into it and read or change files anywhere else on the host, Docker warns in a security announcement on September 15. The escape runs with the rights of the host account that runs the virtual machine. The flaw, CVE-2026-77179, is rated Critical, affects versions

Source: Critical Docker Sandboxes Flaw Lets Malicious Guest Code Read and Modify macOS Host Files via The Hacker News — published 17 Sep 2026.