CVE-2026-5817: 
Docker Desktop vulnerability analysis and mitigation

CVE-2026-5817 is a remote code execution vulnerability in the vllm-metal inference backend of Docker Model Runner on macOS, where the backend unconditionally sets trust_remote_code=True when loading model tokenizers and operates without sandboxing. This causes transformers.AutoTokenizer.from_pretrained() to import and execute arbitrary Python files embedded in any model pulled from an OCI registry, resulting in code execution on the Docker host as the Docker Desktop user. The vulnerability affects Docker Desktop versions 4.62.0 through 4.67.x (fixed in 4.68.0) and was published on May 22, 2026. It carries a CVSS v3.1 base score of 8.6 (High) and a CVSS v4.0 base score of 8.8 (High) (Red Hat CVE, ENISA EUVD).

The root cause is classified as CWE-829 (Inclusion of Functionality from Untrusted Control Sphere): the vllm-metal backend passes trust_remote_code=True unconditionally to transformers.AutoTokenizer.from_pretrained(), which allows arbitrary Python code bundled within a model's tokenizer files to execute during model loading. Because the inference backend runs without any sandboxing on macOS, there is no isolation boundary between the model-loading process and the Docker host. Any container with access to the Docker internal network can exploit this by calling the model-runner.docker.internal API to instruct the Model Runner to pull a malicious OCI-packaged model and trigger inference, at which point the attacker-controlled Python code executes on the host. A public proof-of-concept is available that includes a fake OCI registry server (rce_registry.py), Docker Compose orchestration, and automated exploitation scripts (PoC GitHub, Exploit Intel).

Successful exploitation grants an attacker arbitrary code execution on the Docker host with the privileges of the Docker Desktop user, affecting confidentiality, integrity, and availability at both the vulnerable component and system scope. An attacker operating from any container on the Docker network can exfiltrate sensitive data accessible to the Desktop user, modify host files, install persistent backdoors, or disrupt host operations. The changed scope (S:C in CVSS v3.1) reflects that exploitation breaks out of the container boundary entirely, enabling lateral movement from a compromised container to the macOS host (Red Hat CVE, ENISA EUVD).

1. Reconnaissance: Identify a target macOS system running Docker Desktop 4.62.0–4.67.x with the Model Runner feature enabled. Confirm that the model-runner.docker.internal API endpoint is reachable from within a container on the Docker network.
2. Set up malicious OCI registry: Deploy a rogue OCI-compliant registry server (e.g., using rce_registry.py from the public PoC) that serves a crafted model containing a malicious tokenizer file (e.g., a tokenizer_config.json referencing a custom Python class, or a tokenizer.py with embedded payload code).
3. Trigger model pull: From within any container on the Docker network, call the model-runner.docker.internal API to instruct Docker Model Runner to pull the malicious model from the attacker-controlled OCI registry.
4. Trigger inference: Send an inference request via the Model Runner API referencing the pulled malicious model. This causes the vllm-metal backend to invoke transformers.AutoTokenizer.from_pretrained() with trust_remote_code=True, loading and executing the attacker's Python payload.
5. Achieve host code execution: The malicious Python code runs on the Docker host as the Docker Desktop user, enabling reverse shell establishment, data exfiltration, persistence mechanisms, or further lateral movement (PoC GitHub, Exploit Intel).

• Network: Unexpected outbound connections from the Docker host to unknown external IP addresses or domains following model inference requests; containers making HTTP requests to model-runner.docker.internal to pull models from unrecognized or external OCI registries.
• Logs: Docker Model Runner logs showing AutoTokenizer.from_pretrained() calls with trust_remote_code=True loading models from non-standard or external registries; unusual model pull events in Docker daemon logs referencing unknown image sources.
• Process: Unexpected child processes spawned by the vllm-metal inference backend process (e.g., bash, python3, curl, wget, nc) on the macOS host; new processes running as the Docker Desktop user that are unrelated to normal Docker operations.
• File System: New or modified files in the Docker Desktop user's home directory or temp directories created around the time of model inference; unexpected cron jobs, launch agents (~/Library/LaunchAgents/), or login items added under the Docker Desktop user account.
• Artifacts: Presence of unfamiliar Python scripts or tokenizer files within Docker Model Runner's model cache directory (PoC GitHub, Exploit Intel).

Docker has addressed this vulnerability in Docker Desktop 4.68.0; users should upgrade immediately (Docker Release Notes). As interim workarounds prior to patching: restrict network access to the model-runner.docker.internal API so only explicitly trusted containers can reach it; disable or avoid using the vllm-metal inference backend on macOS; implement network segmentation to prevent untrusted containers from accessing the Docker internal network. Organizations should also audit which containers have access to the Docker network and remove unnecessary access (Red Hat CVE, Docker Security).

The vulnerability received coverage in Cyfirma's weekly intelligence report for May 29, 2026, highlighting it as a notable container-to-host escape risk (Cyfirma). A technical write-up was published by Infinit Security detailing the container-to-host code execution mechanism via the unsandboxed trust_remote_code setting (Infinit Security). The vulnerability was also noted in CISA's vulnerability bulletin SB26-145 and discussed on Bluesky by security community accounts. Community sentiment reflects concern about the broad attack surface introduced by AI/ML model loading pipelines that implicitly trust remote code.