Docker Sandboxes Vulnerabilities Let Malicious Guests Escape Workspace and Access Host Files

The tar extraction routines in moby/go-archive (Unpack, UnpackLayer, Untar/UntarUncompressed, and the ApplyLayer helpers) fail to confine filesystem operations to the destination directory: entry placement is decided with lexical string checks, but the actual filesystem operations follow OS-resolved paths, so links shipped inside an archive can escape the extraction target. An attacker who controls the contents of an archive being extracted — for example a malicious image layer or a supplied tar handled by Moby-based tooling — can create or overwrite files at arbitrary paths writable by the extracting process. The CVSS 4.0 vector (AV:L, AT:P, UI:A) indicates exploitation requires local access to the extraction context plus certain preconditions, rather than remote unauthenticated access. Anyone running software that embeds the vulnerable moby/go-archive routines, notably Moby/Docker-based container engines that apply image layers or unpack untrusted archives, is potentially affected. There is no evidence of exploitation so far: no public proof-of-concept, not listed in CISA KEV, and EPSS puts 30-day exploitation probability at 0.3%.

Do: Upgrade affected Moby/Docker components to the vendor-patched release once Docker's advisory specifies fixed versions, and if you consume moby/go-archive as a Go module, bump it to the fixed version and rebuild. Until patched, avoid extracting untrusted tar archives (docker load, layers from untrusted registries, automated tar unpacking jobs) on hosts where the extracting process holds write access to sensitive paths, and run extraction under least-privilege accounts. Review CI/CD pipelines and cron jobs that unpack user-supplied archives into privileged locations, as these are the most likely attack paths.

An out of bounds read vulnerability in the grpcfuse kernel module present in the Linux VM in Docker Desktop for Windows, Linux and macOS up to version 4.61.0 could allow a local attacker to cause an unspecified impact by writing to /proc/docker entries. The issue has been fixed in Docker Desktop 4.62.0 .

Docker Model Runner (DMR) is software used to manage, run, and deploy AI models using Docker. Versions prior to 1.0.16 expose a POST `/engines/_configure` endpoint that accepts arbitrary runtime flags without authentication. These flags are passed directly to the underlying inference server (llama.cpp). By injecting the --log-file flag, an attacker with network access to the Model Runner API can write or overwrite arbitrary files accessible to the Model Runner process. When bundled with Docker Desktop (where Model Runner is enabled by default since version 4.46.0), it is reachable from any default container at model-runner.docker.internal without authentication. In this context, the file overwrite can target the Docker Desktop VM disk (`Docker.raw` ), resulting in the destruction of all containers, images, volumes, and build history. However, in specific configurations and with user interaction, it is possible to convert this vulnerability in a container escape. The issue is fixed in Docker Model Runner 1.0.16. Docker Desktop users should update to 4.61.0 or later, which includes the fixed Model Runner. A workaround is available. For Docker Desktop users, enabling Enhanced Container Isolation (ECI) blocks container access to Model Runner, preventing exploitation. However, if the Docker Model Runner is exposed to localhost over TCP in specific configurations, the vulnerability is still exploitable.

Docker Model Runner (DMR) is software used to manage, run, and deploy AI models using Docker. Prior to version 1.1.25, Docker Model Runner contains an SSRF vulnerability in its OCI registry token exchange flow. When pulling a model, Model Runner follows the realm URL from the registry's WWW-Authenticate header without validating the scheme, hostname, or IP range. A malicious OCI registry can set the realm to an internal URL (e.g., http://127.0.0.1:3000/), causing Model Runner running on the host to make arbitrary GET requests to internal services and reflect the full response body back to the caller. Additionally, the token exchange mechanism can relay data from internal services back to the attacker-controlled registry via the Authorization: Bearer header. This issue has been patched in version 1.1.25. For Docker Desktop users, enabling Enhanced Container Isolation (ECI) blocks container access to Model Runner, preventing exploitation. However, if the Docker Model Runner is exposed to localhost over TCP in specific configurations, the vulnerability is still exploitable.

The vllm-metal inference backend in Docker Model Runner on macOS unconditionally sets trust_remote_code=True when loading model tokenizers, and runs without sandboxing. This causes transformers.AutoTokenizer.from_pretrained() to import and execute arbitrary Python files included in any model pulled from an OCI registry, resulting in arbitrary code execution on the Docker host as the Docker Desktop user when inference is triggered. Any container on the Docker network can trigger this by calling the model-runner.docker.internal API to pull a malicious model and request inference.

A symlink-resolution flaw (CWE-59) in the virtio-fs host server used by Docker Sandboxes on macOS allows a malicious guest VM to break out of its shared workspace. The bug occurs when the host server reopens an unlinked file from a stored path: the guest can replace a parent directory with a symlink so the reopen resolves outside the intended share. A successful exploit lets the guest read or modify arbitrary files on the macOS host as the VMM user, with potential host code execution, reflected in a CVSS 4.0 score of 9.4 (critical). This affects users running Docker's Sandboxes feature on macOS hosts, particularly where the sandbox is used to execute untrusted or AI-generated code. No public proof of concept is known and the flaw is not listed in CISA's KEV, so exploitation status is none known.

Do: Update Docker Desktop on macOS to the latest release, which contains Docker's fix for the virtio-fs symlink handling, as soon as it is available to you. Until patched, disable the Sandboxes feature on macOS hosts and avoid executing untrusted or AI-generated code inside it. If the feature has been used with untrusted code, review the host for unexpected file modifications or processes running as the VMM user.

Docker Sandboxes contains a time-of-check/time-of-use race condition (CWE-367) in the guest-to-host Unix-domain socket relay: a socket path is validated to sit inside the authorized workspace, but the host later reconnects by re-resolving that same pathname. A malicious guest can swap an intermediate directory in the path for a symlink during the window between validation and connection, tricking the host into connecting to an arbitrary AF_UNIX socket outside the shared workspace. Successful exploitation lets the guest read data from, or invoke capabilities exposed by, the targeted host-side socket, with high confidentiality and integrity impact on both the vulnerable component and subsequent systems per the CVSS 4.0 vector (8.7, local attack vector, no privileges or user interaction required). Any developer or environment using Docker Sandboxes to run semi-trusted or untrusted code is affected, since the attacker must already control code inside a sandbox. No public proof of concept exists, the flaw is not on the CISA KEV list, and no exploitation in the wild is known.

Do: Apply the vendor fix as soon as Docker publishes patched builds, and check Docker's security advisory (assigned by [email protected]) for the exact fixed version of Docker Sandboxes/Docker Desktop. Until patched, treat Sandboxes as isolation-best-effort only: do not run untrusted code, and audit which host AF_UNIX sockets are reachable through the relay, since those become the blast radius of a successful race. Monitor guest workspaces for processes rapidly creating or renaming directories along shared socket paths, which is characteristic of exploitation attempts.