docker-model-runner-model-file-rce

Docker Model Runner ‘model_file’ flaw lets containers execute Python on your Docker Desktop host, an information security emergency

What happened

The sticky detail is simple and ugly, the model_file field in Docker Model Runner’s config.json can point at a Python file that gets imported and run, thanks to the MLX-LM backend using importlib with no safety gate.

The vulnerability is tracked as CVE-2026-5843 and affects the MLX inference backend in Docker Model Runner on macOS. The backend runs without sandboxing, so when a model’s config.json names a model_file, arbitrary Python from that file executes on the Docker host as the Docker Desktop user.

Any container on the Docker network can trigger this by calling the model-runner.docker.internal API to pull a malicious model from an attacker-controlled OCI registry and request inference. The vendor severity listed with the advisory is 8.2, labelled High. When this was reported, and whether a patch exists, has not been disclosed in the advisory text I was given.

Why this matters to businesses

When containers can run code on the host as your logged-in Docker Desktop user, what seemed like isolated workloads stop being isolated. Given that many developer machines and CI runners use Docker Desktop, this is an obvious supply-chain and insider-risk vector.

Customers, partners and suppliers are at risk if credentials or images are stolen, or if a compromised host is used to sign or publish malicious images. Boards should worry about downtime, incident response costs and possible contract fallout if a build or registry is abused.

And yes, calling container isolation ‘good enough’ and doing patch later thinking will get you into trouble, honestly.

If you’ve got the same weakness, here’s what happens next

If you run Docker Model Runner or allow teams to pull models from public OCI registries, an attacker can quietly drop a malicious model that executes on the host when inference is requested. That gives them the same user privileges as Docker Desktop, access to local files and any credentials the user holds.

From there, attackers can persist, move laterally into CI systems or registries, and abuse signing pipelines. Recovery costs can spiral, because you need to clean developer machines, rotate keys and revalidate images, not just rebuild a single container.

What to do on Monday morning

• Inventory where Docker Model Runner runs, especially macOS developer machines and CI runners, and isolate any unmanaged instances.

• Block or limit access to the model-runner.docker.internal API at the network level until you have mitigations or patches in place.

• Restrict model pulls to trusted OCI registries and add allow-lists or image signing checks in your CI pipeline.

• Check the vendor advisory for a patch and apply it, or if none exists, implement a temporary policy that forbids using untrusted models or disables model_file handling where possible.

• Rotate Docker and registry credentials that might have been exposed and audit recent pulls and image creation activity.

• Increase logging and alerting for unusual model pulls, new containers requesting inference and any host-level process invocation coming from Model Runner.

• Run restore and build pipeline exercises so you know how long recovery takes, and where backups or signed images are required.

Where ISO standards fit, without the sales pitch

An ISO 27001-aligned management system helps here, because a proper asset inventory, supplier controls and change management reduce the chance you run arbitrary models in production, see https://synergosconsultancy.co.uk/iso27001/ for a practical breakdown of controls you can adopt.

When continuity and recovery are in play, ISO 22301 thinking helps you plan for developer machine compromises and CI outages, see https://synergosconsultancy.co.uk/iso-22301-business-continuity-management-system-bcms/ for guidance on testing recovery plans that actually work.

For baseline certification and pragmatic technical controls, IASME-level hygiene helps you prioritise the small things that stop big compromises, see https://synergosconsultancy.co.uk/iasme-certifications/.

Put simply, standards won’t magically stop a flawed importlib call, but they force you to know where the risky bits live and to harden or isolate them so a single malicious model can’t own your build farm.

Actionable standards and a tidy supplier policy buy you time to patch without melting down operations.

Think of it like closing a single, obvious window before someone climbs through and sets up a tent in your office.

Take a breath, then act. If you run Docker Model Runner, check for vendor fixes, isolate instances, lock registries and audit credentials right away.