Docker Sandboxes EUVD-2026-57236

Exploitation requires that the attacker already has unprivileged code execution inside the Docker Sandbox (sbx) guest environment - this is the product's intended operating model for running untrusted workloads, so this condition is expected to be met in targeted deployments. The vulnerable condition is specifically triggered when the operator attaches a host directory using read-only mount semantics; if no host directory is mounted read-only, the misconfiguration does not apply. The attacker must additionally be able to derive or enumerate the virtio-fs shared-export path on the guest side, which the description indicates is achievable by unprivileged code. Exploitation is limited to integrity impact on host directories that are actually mounted and to the specific paths exposed via the shared-export allowlist - the attacker cannot reach arbitrary host filesystem locations beyond what the operator granted.

The supplied CVSS 4.0 base score of 5.7 (Medium) reflects AV:L and PR:L - an attacker must already have low-privileged code execution inside the sandbox, materially limiting the attack surface to workloads that intentionally run untrusted or semi-trusted code inside sbx environments, which is the product's stated use case. AT:P (attack requirements present) indicates a specific condition must hold: a host directory must be mounted with the read-only intent for the misconfiguration to be exploitable. The integrity impact is assessed as VI:H, capturing that the attacker can write to host filesystem paths outside the sandbox boundary, which violates container isolation guarantees. There is no confidentiality or availability impact in the CVSS vector. No EPSS data was provided, no KEV listing exists, and no POC is known - this is an unconfirmed-exploitation, medium-severity finding. The real-world risk is highest in AI or multi-tenant workload environments where Docker Sandboxes is used specifically to isolate untrusted code from the host, because that isolation is the primary control being bypassed. The attack is not trivially automatable (AT:P, path derivation required), but the privileged-code-already-in-sandbox assumption aligns exactly with the sbx threat model.

An attacker with low-privileged code execution inside a Docker Sandbox - for example, a malicious or compromised AI workload running in the sbx environment - enumerates or derives the virtio-fs shared-export path for a host directory the operator mounted as read-only. Because the host-edge grant carries no access mode restriction, the attacker writes arbitrary data to that host path, potentially overwriting configuration files, injecting content into shared data directories, or tampering with artifacts that other host processes will subsequently consume. No public proof-of-concept code has been identified at time of analysis.