GPU VulnDB

Database/Container, Kubernetes & orchestration

Docker Sandboxes: symlink race in the socket relay lets a guest reach arbitrary host AF_UNIX sockets

CVSS 8.7CVE-2026-79994Container, Kubernetes & orchestrationcurated

Impact

The relay validates that a requested socket path lies inside an authorized workspace, then reconnects using the pathname rather than the validated handle. A malicious guest can swap an intermediate directory for a symlink in between, so the host connects to any AF_UNIX socket it can reach. That is a sandbox escape in the direction that matters: whatever the targeted socket offers - a container runtime API, an agent daemon, a credential helper - becomes available to code running inside the sandbox. Operators running untrusted or agent-generated code in Docker Sandboxes on shared hosts should treat this as a containment failure, not a hardening gap.

Who can reach it

Local, from inside a sandbox guest. Requires only the ability to run code in the sandbox and manipulate the shared workspace filesystem - no authentication to the host side. The race is a timing window, reflected in the AT:P attack-requirements metric.

What to do

Upgrade to Docker Sandboxes v0.42.0 or later (per the linked release) and restart the sandbox daemon; running sandboxes must be recreated to pick up the new relay. Until then, do not run untrusted workloads in Docker Sandboxes on a host with sensitive AF_UNIX sockets, and keep sandbox workspaces off shared filesystems the guest can restructure.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.