Docker Model Runner CVE-2026-5843: Two Flaws That Let a Bad Model Own Your Mac

Docker Model Runner has two high-severity code execution flaws on macOS. Both let any container on your Docker network run arbitrary code on your host — as your own user, with access to your files, credentials, and source code. If you’re on a Mac and haven’t updated Docker Desktop to 4.71.0, you are exposed. Update now, then read on.

What is Docker Model Runner?

Docker Model Runner is Docker Desktop’s built-in local AI inference engine, generally available since mid-2025. It lets you pull and run LLMs — Llama, Mistral, Gemma, and others — using standard Docker commands, with an OpenAI-compatible API at model-runner.docker.internal. Models are distributed as OCI artifacts, just like container images. For developers who want to test AI features in their local loop without hitting external APIs, it’s become a fast default.

The catch: Docker Model Runner’s macOS inference backends treated model content as trusted. They shouldn’t have.

CVE-2026-5843: The MLX Backend Executes Whatever config.json Tells It To

The MLX inference backend — used on Apple Silicon for hardware-accelerated inference — loads model configuration from config.json. When that file specifies a model_file pointing to a Python script, MLX-LM uses Python’s importlib to load and execute it. No trust gate. No sandbox. The code runs directly on the Docker Desktop host as the current user.

The attack path is straightforward:

1. An attacker publishes a model with a malicious config.json to any OCI registry — Docker Hub, Hugging Face OCI, or a private registry you’ve added.
2. A developer pulls and runs the model via Docker Model Runner.
3. On the first inference request, the malicious Python file executes on the host.
4. The attacker now has host-level access: files, SSH keys, environment variables, source code.

No elevated privileges required. Any container on the Docker bridge network can call model-runner.docker.internal and trigger this. CVE-2026-5843 carries a CVSS 4.0 base score of 8.8. It was patched in Docker Desktop 4.71.0.

CVE-2026-5817: The vllm-metal Backend Trusts All Tokenizers, Always

The vllm-metal inference backend — also macOS-only — has a different but structurally identical flaw. It calls transformers.AutoTokenizer.from_pretrained() with trust_remote_code=True hardcoded and unconditional.

That flag tells the Hugging Face transformers library to download and execute any Python tokenizer code the model specifies. It exists for a reason — some tokenizers need custom code — but it’s supposed to be an explicit opt-in by the developer, with awareness of the trust implications. Here, Docker enabled it for every model, from every source, automatically.

Any container on the Docker network can trigger this the same way: pull a crafted model, request inference, get host code execution. CVE-2026-5817 was patched in Docker Desktop 4.68.0, with the fix removing the unconditional flag and adding sandbox isolation for inference.

The Root Cause: Model Code Ran on the Host

Both CVEs share the same failure: the inference backends ran model-supplied Python code in the host process context rather than sandboxed inside Docker’s isolation boundary. A container can’t read your SSH keys by default. A malicious model loaded by Model Runner’s macOS backends could.

This isn’t just a Docker bug — it’s a category of problem that applies to every local AI inference tool. AI models aren’t inert data. Tokenizers, model scripts, and config files can contain executable Python. trust_remote_code=True is a real flag with real consequences. Tools that load models from registries need to treat model content as untrusted, the same way a package manager treats a dependency from a public registry.

Fix It: Update to Docker Desktop 4.71.0

Check your version: Docker Desktop → “About Docker Desktop.” If you’re below 4.71.0, update via Settings → Software Updates.

Docker Desktop 4.71.0 is notable beyond the patch: it disabled Docker Model Runner by default. You now have to explicitly enable it in Settings. That’s a significant change from the previous default-on stance, and it signals Docker’s own assessment of the trust boundary problem.

Until you’ve updated, the interim mitigations are: restrict container network access to model-runner.docker.internal to trusted containers only, and only pull models from sources you control or fully trust. Avoid pulling models from unnamed community uploads on Docker Hub or Hugging Face OCI.

The Bigger Picture: Model Supply Chain Is the New npm Supply Chain

Models distributed via OCI registries aren’t just weights and configs — they can carry executable Python. Popularity on a hub isn’t a proxy for safety. A poisoned model disguised as a popular LLM variant is a viable attack vector, and with Docker Model Runner on 3.3 million developer machines, the surface is significant.

The TeamPCP supply chain attack (February 2026) showed how attackers can compromise developer-trusted tools through npm and PyPI. The model supply chain — OCI registries, Hugging Face Hub, Docker Hub — is the next frontier for the same playbook. These two Docker CVEs make that concrete: a malicious model, distributed through legitimate channels, can own a developer’s machine with no user error required beyond pulling a model that looked legitimate.

Treat models from public registries with the same skepticism you’d apply to a dependency from a stranger on npm. That means version pinning, source verification, and ideally signing. The NVD entry for CVE-2026-5843 and the CVE-2026-5817 advisory have full technical details if you need them for incident response. For now, the most actionable step is simpler: update Docker Desktop.