Docker Sandboxes trusted paths that a guest could replace

Docker Sandboxes checked or remembered a pathname, then used it after a guest could change its meaning. Today's two disclosures describe different consequences of that mistake. One let a malicious guest reach host files through the macOS shared filesystem server. The other let it redirect a host-side Unix socket connection outside the authorized workspace.

The Docker security announcement says Sandboxes 0.42.0 fixed both vulnerabilities on September 7. Their detailed CVE records were published September 15. This is a disclosure of already repaired failures, and the relevant fixed version is the Sandboxes version, not an assumed Desktop release number.

Both failures concern operations deliberately permitted across the guest boundary. Sharing files and relaying sockets requires host software to act on a guest's behalf. The question is whether that software continues to enforce the workspace boundary when the guest changes the filesystem during the operation.

Reopening an unlinked file escaped the workspace

CVE-2026-77179 affects the virtio-fs host server used by Docker Sandboxes on macOS. The record identifies a stored-path fallback used when reopening an unlinked file. During that operation, the host server improperly followed symlinks.

A malicious guest could replace a parent directory with a symlink. The remembered pathname would then lead somewhere outside the shared workspace when the host reopened the file. Docker describes the result as reading or modifying arbitrary host files as the VMM user, with potential host code execution.

The stored path matters because its text can remain unchanged while the object it reaches changes. A directory component has a meaning established by the filesystem at the moment of resolution. Remembering the string does not preserve the identity of the file that originally occupied that location.

The fallback therefore needed the same confinement property as the normal access path. Otherwise an operation intended to preserve access to a file could acquire authority over an unrelated host path. The disclosure identifies reopening after unlinking as the setting where that property failed.

Docker marks versions from 0.28.0 up to, but not including, 0.42.0 as affected on macOS. Its CVE record rates the vulnerability critical and classifies the weakness as improper link resolution before file access. That platform qualification should accompany the version range. The record does not assign this particular virtio-fs failure to every supported host operating system.

A socket relay repeated the same trust decision later

CVE-2026-79994 concerns the guest-to-host Unix-domain socket relay. The relay validated that a socket path lay inside an authorized workspace. It later reconnected using the pathname, which allowed a guest to change an intermediate directory between validation and connection.

Replacing that directory with a symlink redirected the connection to an arbitrary host AF_UNIX socket outside the shared workspace. The exposure depends on the data or capabilities offered by that socket. Docker describes both as possible consequences and rates the vulnerability high.

This record identifies a time-of-check, time-of-use race, CWE-367. The original check could have been correct about the filesystem state it observed. The problem was treating that result as sufficient for a later connection after the path's components could change.

The socket case differs from the file case in the authority it exposes. A connection to a host service can make that service's capabilities reachable without reading or overwriting its socket file as ordinary data. The relevant effect is the connection established by the host relay on the guest's behalf.

The affected range begins at Sandboxes 0.37.0 and ends before 0.42.0. Unlike the virtio-fs entry, Docker's affected-product entry does not limit this issue to macOS. Combining the two disclosures into a single platform and version range would erase information needed to identify exposed installations.

Workspace boundaries must survive guest mutation

The shared pattern is a host operation whose authorized target is represented by a path. In one case the host stores that path for fallback use. In the other it validates the path before reconnecting. Both designs need to preserve the relationship between the authorized workspace and the eventual operation despite changes initiated by the guest.

This is a stronger requirement than checking that a visible string begins with an approved directory. The check has to constrain what the operating system ultimately accesses. A guest that can replace directory components can influence resolution without asking for an obviously outside pathname.

The two CVE descriptions explain the vulnerable behavior, but they do not describe every detail of the repaired implementation. It would be speculation to claim a particular file-descriptor strategy or syscall as the complete patch. The supported conclusion is that 0.42.0 repairs these disclosed escapes through the stored-path fallback and the socket relay.

I value Docker's ability to make a build environment repeatable across machines. That preference also makes the behavior of workspace sharing important to me. A repeatable environment is useful only if the surrounding file access still matches the authority intentionally granted to it.

The disclosures show why the host services that implement sharing belong in the isolation model. A guest does not need to defeat every isolation mechanism if a permitted host operation reaches beyond its intended scope. The broker's path handling can determine the effective boundary of the environment.

Clone mode is the documented temporary measure

Docker gives the same workaround for both vulnerabilities. Use --clone mode and avoid additional read-write host mounts. The security announcement repeats that advice for installations that cannot update to 0.42.0 or later.

The second part matters alongside the first. Adding a read-write host mount changes the sharing arrangement that the workaround asks users to avoid. Treating the mode name alone as a universal guarantee would omit an explicit condition from Docker's guidance.

The advisory's wording also helps distinguish mitigation from remediation. Clone mode with restricted mounts is a way to reduce exposure while the vulnerable software remains installed. The fixed Sandboxes release addresses the implementations described by the CVEs. Those are different interventions with different effects on the user's working environment.

No published command example is necessary to reproduce the attack in order to explain this distinction. The essential operation is a host-side reopening or connection after a guest-controlled path change. The workaround alters sharing conditions, while the update repairs the software responsible for handling those operations.

My view is that sharing should be an explicit capability with a narrow scope. The convenience of a live workspace is real, but its implementation has to treat the guest as capable of deliberate filesystem changes. A boundary designed around cooperative file access does not establish that it survives an adversarial guest.

The difference between the affected ranges is useful historical information as well. The file-sharing issue reaches back to 0.28.0, while the relay issue starts at 0.37.0. An installation can therefore fall within one range without falling within both. The disclosure supports that narrower assessment and gives a shared endpoint for remediation. Treating every earlier version as equally affected by both would misstate the published product records.

Read the two impact statements separately

The virtio-fs record says file access occurs as the VMM user and can potentially produce host code execution. It does not establish unconditional root access. The socket record says the relay can connect outside the shared workspace and expose the targeted socket's data or capabilities. It does not say every host socket offers the same authority.

Those qualifications make the disclosures more useful. They identify which process acts for the attacker and what operation escapes its intended scope. The resulting risk follows from the files writable by that user or the services reachable through the redirected socket, with the affected implementation determining which path applies.

Docker credits Oren Yomtov of accomplish.ai for the virtio-fs issue and Jurre van Bergen of ThreatNotify for the socket issue. Their findings identify separate failures, even though both involve symlink substitution. The shared 0.42.0 fix boundary makes one upgrade relevant to both, but it does not make the vulnerabilities interchangeable.

For operators, the meaningful inventory is the installed Sandboxes version and the host sharing configuration. On an affected macOS version, the stored-path fallback exposes host files. On affected socket-relay versions, the connection can leave the authorized workspace. Updating to 0.42.0 closes the two disclosed paths, while Docker's clone-mode guidance supplies the stated temporary alternative when that update is unavailable.