CSIPE

Published

- 21 min read

Docker Patched Two Sandbox Flaws. Check the Shared Folder Next

AI Agents Sandboxing Application Security Docker

Books by the author

Compare all 5

As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog.

A coding agent runs inside a small virtual machine on a Mac. It has root privileges in that machine, which is expected, but it should see only the project folder shared by the developer. Then code inside the virtual machine changes a path at just the right moment. The file-sharing service follows that path beyond the project and opens a file elsewhere on the Mac.

The virtual machine is still running. The agent never asks for a broader folder. Yet the computer has crossed the line the sandbox was meant to hold.

Docker disclosed that failure as CVE-2026-77179 on 15 September 2026. The Docker-authored CVE record says Docker Sandboxes versions from 0.28.0 up to, but not including, 0.42.0 were affected on macOS. A malicious guest could read or change arbitrary host files with the rights of the account running the virtual machine, potentially leading to code execution on the host. Version 0.42.0, released on 7 September, contains the fix.

The same release repaired another boundary error. CVE-2026-79994 let a guest redirect a host-side Unix socket connection beyond the authorised workspace. Docker rates the first flaw Critical at 9.4 under CVSS 4.0 and the second High at 8.7. As of 18 September, Docker has not reported exploitation; The Hacker News independently checked the affected versions, fixes, and public exploitation status.

If you use Docker Sandboxes, update to 0.42.0 or later and prove which version is actually running. Then inspect the routes that make the sandbox useful: the writable project folder, host sockets, forwarded credentials, local tool servers, and anything that runs automatically after the agent edits a file. The lasting lesson is simple. A virtual machine can be a strong wall, but every opening cut through that wall becomes part of the security boundary.

What Docker disclosed, and what it did not

Docker Sandboxes is designed for coding agents that need to run commands, install packages, build containers, and modify a project. Docker’s current product documentation says each agent gets an isolated microVM with its own filesystem, network, and Docker daemon. The host shares only resources the operator chooses to expose.

That design addresses a real problem. A coding agent does more than suggest text. It executes package installers, test scripts, compilers, shell commands, and code drawn from a repository. Any of those inputs can be broken or hostile. Giving the workload its own kernel and its own Docker daemon keeps ordinary guest processes away from the host’s processes and container engine.

CVE-2026-77179 affected the bridge used to make a host project available inside that virtual machine on macOS. The bridge used virtio-fs, a file-sharing system for virtual machines. According to the CVE record, its host-side server improperly followed symbolic links when reopening an unlinked file from a stored path. A symbolic link is a filesystem signpost that points somewhere else. If a guest could swap a parent directory for such a signpost between two parts of the operation, the server could reopen the path outside the approved workspace.

This class of error is often called a time-of-check to time-of-use race. The service checks a path while the directory tree has one shape, then uses that path after the guest has changed the tree. Both steps can look reasonable in isolation. The gap between them creates the opening.

The impact follows the account on the host side, not the account name shown inside the guest. The CVE says the file access occurs as the virtual machine monitor user. On a developer laptop, that may be the same user who owns source code, shell configuration, local application data, cached sessions, and files in the home directory. The record therefore describes possible host code execution, although the exact consequence depends on which files the host account can reach and what the attacker changes.

The second flaw reached through a different opening. Docker Sandboxes can relay a guest’s request to a Unix domain socket, a local communication endpoint represented by a filesystem path. CVE-2026-79994 says the relay first checked that the requested socket lived inside an authorised workspace. It later reconnected by pathname. A malicious guest could replace an intermediate directory with a symbolic link between those steps and cause the host to connect to a different socket outside the workspace.

That does not make every local socket an instant shell. A socket exposes whatever service is listening behind it. The risk depends on that service’s authority and protocol. A redirected connection might reveal data, invoke a local capability, or do nothing useful to the caller. The important architectural fact is that the workspace check no longer guaranteed the destination.

Both defects were fixed in 0.42.0. Docker’s public release page for version 0.42.0 is dated 7 September 2026, eight days before the CVE records appeared. As of 18 September, the release notes list several security-related fixes but do not name these two CVEs. That timing is a useful reason to verify versions from the advisory data rather than searching release notes for a familiar identifier.

The public record also has limits. The Hacker News reports no known exploitation and says neither issue appeared in the US Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities catalogue as of its 16 September version. That means the available evidence does not support claiming an active campaign. It does not turn an affected installation into a fixed one, and it does not prove that no researcher, malicious package, or compromised agent ever exercised the path. Patch for the capability the flaw created, then let evidence determine whether an incident review needs to widen.

The wall held; the opening did not

A sandbox diagram usually puts a neat rectangle around the agent. The host sits outside. A folder arrow crosses the rectangle so the agent can work on the project. Perhaps another arrow carries network traffic through a policy proxy. The rectangle receives the label “isolated,” and attention moves to the code inside it.

The Docker flaws happened in the arrows.

That distinction matters because the hypervisor did not need to collapse for host files to become reachable. The guest used host-side services deliberately placed at the boundary. File sharing and socket relaying were features, not accidental ports. Their job was to accept a request from the less-trusted side and perform a narrow action on the more-trusted side.

Docker’s isolation documentation is unusually direct about the model. The coding agent runs as a non-root user with sudo inside the virtual machine. The hypervisor boundary, not privilege separation within the guest, is the isolation control. That is the right assumption for agent workloads. If a package script or generated command gains root inside the sandbox, the host should still remain outside its reach.

A shared filesystem complicates that clean model. The host and guest need to agree on names for files, directories, links, deletions, and renames. The host-side server must translate a guest’s request into an operation on the host. Any mismatch between “the path we authorised” and “the object we finally opened” can make the shared folder wider than it looks.

Think of a secure workshop with one service hatch. A worker inside may hand a numbered request through the hatch, and an employee outside retrieves the matching item from one approved shelf. The workshop door can stay locked. If the worker can change the shelf label after the employee checks it but before the employee picks up the item, the service hatch defeats the room’s boundary without touching the door.

The socket flaw has the same shape with a different object. The relay checked one destination and then connected to a name the guest could redirect. The check answered a question about the earlier directory tree. The connection acted on the later one. Security decisions tied to mutable names are fragile when the untrusted side can change what those names resolve to.

Running in a virtual machine is a useful property but an incomplete review. Inventory every host-mediated capability available to that guest. Start with shared directories and mark each one read-only or writable. Then trace reachable host services, relayed sockets, and the points where credentials are inserted. Name every local Model Context Protocol server that runs on the host, what it can do, and which actions occur after the sandboxed process writes a file. Count the crossings.

A strong wall narrows the review. It does not remove the openings from the drawing.

A writable project is already a route back to the host

The patched flaws allowed access beyond the intended workspace. The intended workspace itself still deserves care because it is not passive storage. Modern repositories contain files that other tools execute.

Docker documents the difference plainly. With a direct mount, the agent and host see the same working tree, and agent writes appear on the host immediately. The documentation calls out Git hooks, continuous-integration files, build scripts, editor tasks, and coding-agent settings as examples of files that can execute later when a developer commits, pushes, builds, installs, or opens the project.

A coding agent does not need a sandbox escape to alter package.json, a Makefile, an editor task, or a workflow file if those files belong to the mounted project. The agent may be authorised to make exactly those changes. The risk appears when a human treats “the edit came from inside a sandbox” as evidence that the edited file is safe to run on the host.

The safe mental model is closer to a pull request from an unfamiliar contributor. The proposed code may be useful. It may pass tests. It may also change the machinery that runs those tests, a hook that fires on commit, or configuration that another coding agent reads at startup. Review has to cover effects, not only application logic.

Git makes part of this easier and part harder. A normal diff shows tracked file changes, which is valuable. It does not automatically show a new or modified file under .git/hooks/, because that directory is outside the tracked tree. Untracked files can also sit outside the default diff. Docker’s isolation guide specifically tells users to inspect host Git hooks after an agent session in a directly mounted workspace.

The lesson extends beyond malicious agents. A well-intentioned agent can install a tool that writes an activation script, update an editor task incorrectly, or follow a repository instruction that assumes a disposable build worker. The sandbox may absorb the immediate command while the resulting file waits for a later host action. That is a delayed crossing of the boundary.

A practical workflow therefore separates three claims. “The agent process could not directly access the host” is one claim. “The agent could modify only this repository” is another. “Nothing it wrote will execute on the host without review” is a third. A team needs evidence for each one; proving the first does not establish the other two.

Clone mode changes the default here. Docker says --clone mounts the host repository read-only and gives the agent a private clone inside the virtual machine. The agent’s edits stay in that clone until the developer fetches them. That adds an integration step between agent output and the host working tree, much like receiving changes from a remote contributor.

Clone mode has a sharp limit. Docker says the read-only source mount includes untracked and ignored files under the repository root. A .env file can still be read even though it cannot be changed. Secrets therefore belong outside the working tree or behind a credential mechanism that does not disclose their values to the guest. Read-only is an integrity control; it is not confidentiality.

Patch level is a property of the running path

“Update Docker” sounds like one action. Developer machines often have several layers that can make that sentence ambiguous: Docker Desktop, a standalone sbx command, a package-manager formula, a nightly channel, an old binary earlier in PATH, and sandboxes created before the update.

The CVE records give the minimum fixed line: 0.42.0. The task is to connect that number to the process that provides the sandbox on each affected Mac. A downloaded installer, updated formula index, or current GitHub page is not proof that the running command crossed that line.

Start with the command the developer or automation actually invokes. Record its resolved path and reported client and server versions. Docker’s 0.42.0 release added a machine-readable sbx version --json response that includes whether the backend is running, which makes a saved receipt easier to produce. If the command is launched through an editor, desktop wrapper, or script, inspect that launch path rather than assuming it resolves the same binary as an interactive shell.

Then check the lifecycle of existing sandboxes. A management tool may be current while an already-created environment keeps state, mounts, or processes from an earlier session. Follow Docker’s current upgrade instructions and recreate a sandbox when the chosen mitigation or version transition requires it. The Hacker News reports that moving an existing workspace to clone mode requires removing and creating the sandbox again with --clone; a flag typed against an old environment does not retroactively change its mount.

Version evidence should be boring. A useful record contains the machine or fleet identifier, the binary path, the client and backend version output, the time checked, and the person or automation that checked it. Teams with managed developer fleets can collect this centrally. A small team can keep the same facts in the change ticket.

Do not substitute a process list from one laptop for an inventory. The affected macOS range begins at 0.28.0. Find Macs where Docker Sandboxes is installed, including test devices and shared build machines, then identify which copies fall below 0.42.0. Linux and Windows systems still need normal maintenance, but CVE-2026-77179’s affected-platform statement names macOS. CVE-2026-79994 does not state a platform in its CVE affected-product block, so check every installation that used versions 0.37.0 through 0.41.x rather than assuming the first CVE’s platform limit applies to both.

If an installation cannot be updated immediately, reduce what the guest can touch while the exception is open. The Hacker News reports Docker’s advice as using clone mode and avoiding added read-write host mounts. That does not repair the faulty host service. It reduces the useful host-facing paths available to code inside the guest. Record the exception, the compensating controls, and an expiry date rather than letting a temporary setup become the permanent one.

A patched version closes the two disclosed paths. It does not certify every future path or every local integration. Keep the version receipt, then review the architecture that remains.

Host helpers carry host authority

The file server and socket relay are examples of a wider pattern: a small helper outside the sandbox performs work for a caller inside it. The helper may inject an API credential, forward an SSH authentication request, run a local tool, open a port, copy text to the clipboard, or connect to a service on the host.

Those helpers exist because useful coding work needs controlled access to real resources. Removing every bridge would produce a clean but unproductive virtual machine. The security job is to make each bridge narrow, authenticated where necessary, observable, and unable to silently change its own scope.

Credentials show the difference between value and authority. Docker’s isolation guide says its host-side proxy can inject model-provider credentials into approved outbound requests so the secret value never enters the virtual machine. That prevents straightforward secret-file theft. The sandbox can still exercise whatever request authority the proxy deliberately provides. A protected key that can be used without a tight destination and operation policy is still powerful.

SSH agent forwarding deserves the same distinction. A private key can remain on the host while a process in the guest asks the forwarded agent to authenticate or sign. Keeping the key bytes out of the sandbox is valuable. It does not make every requested signature safe. If the task does not require SSH, disable forwarding. If it does, treat the reachable identities and destinations as part of the task’s permission set.

Local tool servers can cross the wall even more directly. Docker’s documentation notes that local standard-input Model Context Protocol servers run on the host, outside the sandbox virtual machine. If such a server starts a Docker container, it uses the host’s Docker engine. The sandboxed agent may therefore be isolated while one of its tools acts with host authority.

That arrangement can be sound, but only with explicit controls. The tool should expose narrow operations, validate every argument, use a dedicated identity, and log the request and result. A server that accepts arbitrary commands turns the sandbox boundary into scenery. A server that can create one scoped test resource under a fixed directory is much easier to reason about.

Network proxies also need an authority map. An allowlist limits destinations, but a broad software-hosting domain may still contain attacker-controlled content. Blocking direct User Datagram Protocol traffic does not settle what an approved HTTPS request can download. The policy has to match the task: which destinations, methods, identities, data volumes, and time window does this run need?

The Secure Harness argues for useful autonomy held inside controls the workload cannot rewrite. Docker’s patch repairs two places where mutable paths undermined those controls. Your local helpers still need the same review, because the strongest isolation layer cannot compensate for a tool that intentionally performs unrestricted host actions on the agent’s behalf.

Check the exposure without inventing an incident

A critical severity score can push teams into one of two bad responses. The first is to dismiss the issue because there is no reported exploitation. The second is to treat every affected Mac as compromised and rotate everything within reach. Neither position follows the evidence available on 18 September.

The known facts support a bounded review. Affected code running inside a sandbox had a way to cross the workspace boundary through host-side file handling, and some versions had a way to redirect a host socket connection. Public sources do not report exploitation. Your job is to determine whether an affected version ran, what untrusted code it handled, what host authority was nearby, and whether retained evidence shows an unexpected effect.

Begin with time. Record when each affected installation first entered the vulnerable version range, when it reached 0.42.0 or later, and which sandbox sessions ran in between. Package-manager history, installation receipts, endpoint-management records, and shell history may help. If you cannot establish the start, say so rather than choosing the date that makes the review convenient.

Next, identify the workloads that deserved the sandbox. Repositories from unknown contributors, generated code, package installation, issue text copied from public sources, and autonomous agent sessions carry different exposure from a private repository containing only reviewed code. This is prioritisation, not proof. A familiar repository can still pull a hostile dependency, while an unfamiliar one may be harmless.

Map the host account’s reachable assets during those sessions. Relevant categories include source repositories outside the workspace, shell startup files, Git and package-manager configuration, cloud and source-control credentials, SSH agent access, local service sockets, browser or editor integration, and host-side tool servers. Keep the map tied to actual configuration. Do not paste a generic list into an incident ticket and call it scoping.

Then look for effects outside the expected project. Useful evidence may include host file metadata, endpoint telemetry, shell configuration changes, new startup items, credential-use records, source-control audit logs, package-registry activity, cloud identity logs, and local helper logs. A suspicious change deserves escalation. A clean search means only that the chosen sensors saw no matching effect during their retained window.

Review the workspace separately because authorised edits can create delayed host execution. Compare tracked changes, list untracked files, inspect .git/hooks/, examine build and install scripts, check editor tasks, and review agent configuration. Do this before running the project’s tests or opening it in an editor that automatically trusts workspace tasks. Preserve a copy when something looks wrong rather than immediately cleaning the only evidence.

Credential rotation should follow reachable authority and evidence. If a vulnerable session could read a .env file because it lived under the repository root, rotate the secrets in that file. If SSH agent forwarding was disabled, do not pretend the forwarded identity was exposed by this route. When logs are missing and a high-consequence credential was within reach, uncertainty can justify rotation, but write down that reasoning.

This review can stay small for a patched developer Mac that ran only known code, used clone mode, exposed no sensitive untracked files, forwarded no credentials, and shows no unexpected host changes. It should widen for an affected direct-mount session that installed public packages, handled untrusted instructions, reached host helpers, or ran under an account with broad production access. The method stays stable while the scope follows the facts.

A practical response sequence

The response should produce three results: the disclosed flaws are removed, unnecessary crossings are narrowed, and someone can explain what was checked. Run the repair and evidence work in parallel when possible so investigation does not delay the update.

  1. Inventory the running installations. Find every Mac and shared development system that runs Docker Sandboxes. Capture the resolved sbx path, client and backend versions, installation channel, and wrapper or editor that launches it. Check non-macOS installations for CVE-2026-79994 as well, because its CVE record does not state a platform restriction.

  2. Move to 0.42.0 or later. Follow Docker’s current installation guidance, stop old processes, and confirm the version from the command that developers and automation really invoke. Save the output with the check time. Do not close the task on a downloaded package or a release-page screenshot.

  3. Reduce direct host writes. Prefer clone mode for unfamiliar repositories, autonomous runs, and tasks that install or execute third-party code. Remove additional read-write host mounts that the task does not need. Remember that clone mode still exposes repository contents for reading, including ignored .env files, so move secrets outside the tree.

  4. List every intentional bridge. For each sandbox profile, record workspace mounts, socket relays, network policy, credential proxy, SSH forwarding, shared skills, editor connection, published port, clipboard capability, and local tool server. Name the host-side authority behind each bridge. If nobody can explain why a route exists, disable it until there is a task that needs it.

  5. Review the vulnerable window. Identify sessions that ran on affected versions and rank them by untrusted input and host authority. Check effects outside the workspace using host and service records. Review the workspace for delayed execution paths before running anything from it on the host.

  6. Rotate only what was plausibly reachable. Revoke or replace credentials found in readable workspace files, available through forwarded agents, or exposed to powerful host helpers when evidence or uncertainty warrants it. Keep the decision attached to the authority map so the team can explain why one identity changed and another did not.

  7. Test the boundary from the guest side. In a disposable project with fake credentials, verify that the effective policy matches the diagram. Confirm that out-of-scope paths remain unavailable, clone-mode changes stay inside the private clone, denied network destinations stay denied, and host tools reject operations beyond their narrow contract. Do not reproduce the published race on a valuable workstation; test the security properties the repaired system promises.

  8. Write a closure receipt. Record the installations checked, fixed versions, recreation steps, routes removed, sessions reviewed, evidence sources and retention limits, unexpected effects, credential actions, and remaining exceptions. “Docker updated” is an activity. A closure receipt is a claim another engineer can audit.

This sequence should become part of the normal agent-platform review rather than a one-time CVE ritual. A new mount, tool server, credential path, or editor integration changes the boundary even when the hypervisor stays the same.

The useful question is what crosses the boundary

Docker’s disclosure does not show that virtual-machine isolation is pointless. It shows why isolation has to be reviewed as a system. The microVM can keep its own kernel, processes, and Docker engine while a host-side file service makes one unsafe decision about a mutable path.

Version 0.42.0 repairs the two disclosed decisions. Install it. Verify it. Keep the receipt.

Then resist the urge to stop at the rectangle marked “sandbox.” Follow every arrow that crosses it. A shared project gives the agent immediate write authority over files the host may execute later. A read-only clone protects integrity while still revealing ignored files. A credential proxy hides a secret value while granting some use of its authority. A local tool server can act on the host even though the agent process cannot.

Using coding agents and Docker Sandboxes remains reasonable when those terms are explicit. Isolation buys a smaller, clearer set of crossings. Engineering decides whether each crossing is narrow enough, visible enough, and outside the workload’s control.

The next time a product promises that an agent runs “inside a sandbox,” ask for the second half of the diagram. Which folders, sockets, identities, tools, and later host actions pass through the wall? The answer is the real boundary.

For practical security lessons without the noise, join the newsletter. It is one email per month.

Sources