The guest-to-host Unix-domain socket relay in Docker Sandboxes validates that a socket path is inside an…

CVE-2026-79994 is a time-of-check-to-time-of-use (TOCTOU) race condition in the guest-to-host Unix-domain socket relay used by Docker Sandboxes versions 0.37.0 through 0.41.9. The relay validates that a requested socket path lives inside the sandbox's authorized workspace directory, but then reconnects to the path by name rather than by a pinned file descriptor. A malicious guest process can swap an intermediate directory component for a symlink in the window between validation and connection, redirecting the host relay to *any* reachable AF_UNIX socket outside the workspace — including docker.sock, the host Docker daemon's control plane.

Docker tagged this 8.7 / High on some advisories, and that assessment is directionally correct but slightly generous. The TOCTOU race is reliable with retry loops, so attack complexity is effectively low once you have guest code execution — which is the *entire threat model* for a sandbox product that runs untrusted AI-agent code. However, the product launched in March 2026 and its installed base is still narrow compared to Docker Engine or Desktop. The blast radius is real but the exposure population tempers the fleet-wide urgency. We assess HIGH (7.5) rather than CRITICAL because the reachable socket inventory on a typical macOS developer host or CI runner is bounded, and because there is no confirmed exploitation or public PoC weaponizing this chain.

Why this verdict

• Sandbox escape is the threat model: Docker Sandboxes exist to run untrusted AI-agent code. The attacker's prerequisite — guest code execution — is the *default operating condition*, not an additional barrier. This eliminates the usual 'requires local access' friction discount.
• TOCTOU reliability: Filesystem symlink races are historically reliable with retry loops. Academic and practical research shows >90% success rates within seconds. Attack complexity is effectively LOW despite the race window.
• Role multiplier: Docker Sandboxes occupy two deployment roles: (a) *developer workstations* (macOS/Linux) where host sockets include docker.sock, SSH agent, credential managers — escape → host root or credential theft; (b) *CI/CD runners* where escape → supply-chain pivot via build-server access. Both are high-value roles. On developer machines (~70%+ of installs by Docker's own marketing), reaching docker.sock = full host compromise. On CI runners (~20% of installs), the chain ends in build-pipeline control. The floor is HIGH.
• No exploitation or PoC yet: EPSS 0.00106, no KEV listing, no public exploit code. This prevents escalation to CRITICAL despite the role multiplier.
• Narrow installed base: Product launched March 2026. Even aggressive adoption estimates put it at a fraction of Docker Desktop's ~20M developer base. Fleet-wide urgency is tempered by exposure population.

Why not higher?

CRITICAL would require either active exploitation evidence, a public weaponized PoC compressing the response window, or a much larger installed base making fleet-scale compromise plausible today. The product launched six months ago, has no confirmed exploitation, and the reachable socket inventory varies significantly by host configuration — many developer machines may not have high-value sockets exposed in paths reachable via the relay.

Why not lower?

MEDIUM would undercount the blast radius. This is a sandbox-escape bug in a product whose *entire value proposition* is isolation of untrusted code. The prerequisite (guest code execution) is not friction — it is the expected operating condition. On any host where docker.sock or credential-agent sockets are reachable, the chain ends in full host compromise or credential theft. The role multiplier on developer workstations and CI runners floors the verdict at HIGH.

1. Upgrade to Docker Sandboxes 0.42.0+ immediately — The patch resolves the TOCTOU by using fd-pinned socket references instead of pathname-based reconnection. This is the definitive fix. Per the noisgate mitigation SLA for HIGH, deploy within 30 days — but given the simplicity of the upgrade (single binary), aim for days not weeks.
2. Switch sandboxes to clone mode — Clone mode copies the workspace into the microVM rather than mounting it, eliminating the host-side directory traversal path entirely. This breaks the symlink-swap attack chain at step 2. Use this as an interim control if patching is delayed.
3. Remove read-write host mounts from sandbox configurations — If clone mode is not feasible, convert all host mounts to read-only. The TOCTOU requires the guest to *write* (delete + symlink) an intermediate directory — read-only mounts prevent this. Review all --mount and workspace configuration flags.
4. Audit host socket inventory — Enumerate sensitive AF_UNIX sockets on hosts running Docker Sandboxes (find / -type s 2>/dev/null on Linux, sudo lsof -U on macOS). Restrict filesystem permissions on high-value sockets (docker.sock, SSH agent, gpg-agent) to prevent the relay process from connecting even if the symlink race succeeds.
5. Enable host-side audit logging for sandbox relay process — On Linux, add auditd rules for connect() syscalls from the sandbox relay binary targeting socket paths outside /workspace. On macOS, use Endpoint Security Framework or OpenBSM. This provides detection coverage while the patch rolls out.

Run this script on any host where Docker Sandboxes is installed. It checks the installed sbx binary version against the patched version. Requires no special privileges — just access to the sbx CLI. Example: bash check_cve_2026_79994.sh

#!/usr/bin/env bash
# check_cve_2026_79994.sh
# Checks whether the installed Docker Sandboxes version is vulnerable to CVE-2026-79994
# TOCTOU race in guest-to-host UDS relay (affects 0.37.0 – 0.41.9, fixed in 0.42.0)
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

VULN_FLOOR="0.37.0"
FIX_VERSION="0.42.0"

version_gte() {
  # Returns 0 if $1 >= $2 using sort -V
  [ "$(printf '%s\n%s' "$1" "$2" | sort -V | head -n1)" = "$2" ]
}

# Try to find the sbx binary
if command -v sbx &>/dev/null; then
  SBX_BIN="sbx"
elif command -v docker-sandbox &>/dev/null; then
  SBX_BIN="docker-sandbox"
elif [ -x "$HOME/.docker/cli-plugins/docker-sbx" ]; then
  SBX_BIN="$HOME/.docker/cli-plugins/docker-sbx"
else
  echo "UNKNOWN — Docker Sandboxes (sbx) binary not found on this host."
  exit 2
fi

# Extract version
RAW_VERSION=$($SBX_BIN version 2>/dev/null || $SBX_BIN --version 2>/dev/null || echo "")
VERSION=$(echo "$RAW_VERSION" | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -n1)

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — Could not parse Docker Sandboxes version from: $RAW_VERSION"
  exit 2
fi

echo "Detected Docker Sandboxes version: $VERSION"
echo "Vulnerable range: >= $VULN_FLOOR and < $FIX_VERSION"

if version_gte "$VERSION" "$FIX_VERSION"; then
  echo "PATCHED — Version $VERSION is >= $FIX_VERSION. CVE-2026-79994 is fixed."
  exit 0
elif version_gte "$VERSION" "$VULN_FLOOR"; then
  echo "VULNERABLE — Version $VERSION is in the affected range ($VULN_FLOOR – pre-$FIX_VERSION)."
  echo "Action: Upgrade to Docker Sandboxes >= $FIX_VERSION immediately."
  exit 1
else
  echo "PATCHED — Version $VERSION predates the vulnerable code (< $VULN_FLOOR). Not affected."
  exit 0
fi

Sources

1. CybersecurityNews — Critical Docker Sandbox Vulnerabilities
2. The Hacker News — Docker Sandboxes Flaw Lets Malicious Guest Code Access Host Files
3. SecurityOnline — Docker Sandboxes Vulnerabilities Patched
4. LinuxSecurity — Docker Sandbox Unix Socket Exploit CVE-2026-79994
5. OSV / GHSA-p436-gjf2-799p — GitHub Security Advisory
6. Docker Blog — Why MicroVMs: Architecture Behind Docker Sandboxes
7. GBHackers — Docker Sandboxes Vulnerabilities Let Guests Escape Workspace