Docker Model Runner let model configuration execute on the Mac host

A model's configuration file could tell Docker Model Runner to import a Python file, and that import ran on the Mac host. The caller could be a container. That combination explains CVE-2026-5843 more precisely than the general description of a container escape. The vulnerable path crossed the isolation boundary through an inference service that deliberately accepted requests from containers.

Docker's CVE record, published May 22, describes the MLX inference backend's use of MLX-LM. A model_file field in config.json selected Python code that MLX-LM loaded through importlib. The library performed the import without a trust_remote_code gate or an equivalent safety check. Docker says the MLX backend ran without sandboxing, so the code executed with the authority of the Docker Desktop user.

The fix predates today's disclosure. The Desktop 4.71.0 release notes date the release April 27. Docker's security announcement confirms that release fixed the vulnerability. May 22 is the publication date of the detailed CVE description, not the date users first had a patched Desktop available.

An inference request became a host import

The attack sequence in Docker's record starts with a container that can call model-runner.docker.internal. Through that API, the container requests a model from an attacker-controlled OCI registry and then requests inference. The malicious material travels as a model artifact. Its configuration points the loader at Python supplied with the model.

This matters because the caller does not need to persuade a person to open that Python file in an editor or run it as a script. The loader imports it while preparing the model. The dangerous decision occurs inside the software that interprets the model directory, after the API has accepted the request and obtained the artifact.

Docker identifies the problem as inclusion of functionality from an untrusted control sphere, CWE-829. That classification fits the mechanism. Configuration controlled by the artifact publisher chooses executable functionality in the process consuming the artifact. The model's publisher gains influence over more than model parameters or inference settings.

The API connection and the import each have a different role. Network reachability lets the container ask the host-side service to perform work. The unguarded import turns that requested work into execution of code chosen by the model publisher. Closing only an unrelated container permission would leave the service's own trust decision unexplained.

The advisory says any container on the Docker network can trigger the path. Its stated affected configuration is Docker Model Runner enabled with the MLX inference backend on macOS. This is a specific exposure condition. The record does not describe every container installation, every inference backend, or Linux Docker Engine as affected by this issue.

The host process determines the consequence

The Python code executes as the Docker Desktop user. That detail defines the authority gained by the attacker and should remain attached to any description of the flaw. Docker does not describe this particular path as unconditional root execution. A host user account can still have substantial access, and the advisory explicitly identifies arbitrary host code execution as the outcome.

Container isolation cannot contain operations that a reachable host service performs outside the container. In this case the container sends a request, while the MLX backend performs the import in its own execution environment. The record's statement that the backend lacks sandboxing explains why loading model code has consequences beyond the requesting container.

I value Docker for repeatable builds and for the ability to ship a small service image between machines. A multi-stage build ending in a static Go binary remains my preferred packaging approach. This disclosure concerns a different part of the same product. The contents of a service image do not describe all the authority of an adjacent model-loading service.

That distinction changes how the event should be interpreted. A carefully constructed application image can coexist with a vulnerable Desktop capability. Here, the relevant questions concern the enabled inference backend and the service requests available to containers. Image size and application dependency selection do not answer whether the model loader executes publisher-supplied Python on the host.

A model artifact can contain executable behavior

The revealing field is model_file. A JSON configuration file looks like data at the syntax level, but its meaning depends on the consumer. In the vulnerable MLX-LM path, the value selects a Python file for import. Describing the file as configuration does not reduce the authority of the action taken in response to it.

The CVE's reference to a missing trust_remote_code gate is similarly specific. It identifies the absence of an explicit safety decision before the loader imports code associated with a model. The record does not provide enough information to claim that adding one particular flag fully describes Docker's patch. It establishes what the vulnerable behavior lacked and names the Desktop version containing the fix.

This is also why an OCI registry should not be treated as proof that an artifact is inert. In the documented attack, the registry supplies a malicious model directory. The execution arises when the inference backend interprets that directory. Transporting the artifact through the same distribution mechanism used for container images does not establish the semantics of the model loader.

For this event, the distinction between model weights and accompanying implementation code is central. A loader capable of selecting executable Python has a broader trust requirement than one consuming only values. The disclosure gives a concrete example of how a model package can exercise that broader capability without an adequate check.

April changed the default as well as shipping a fix

Desktop 4.71.0 also changed Model Runner's activation behavior. The release notes say it is disabled by default and must be enabled explicitly in Settings. When enabled, TCP host-side support becomes active automatically. Those statements belong alongside the vulnerability fix because they describe how the capability becomes available after the update.

The default change is useful, but it should not be confused with the complete explanation of remediation. Those release notes separately list the security fix for MLX-LM model_file loading. The sources establish both changes without saying that default disablement alone is the implementation of the fix.

The affected-version range in Docker's CVE record begins at Desktop 4.56.0 and ends before 4.71.0 on macOS. Docker names Model Runner with MLX enabled as the configuration at issue. A machine outside that configuration does not acquire the documented exposure merely because its Desktop version appears in the range.

For machines that cannot update immediately, Docker documents two workarounds. Disable Model Runner, or run only trusted containers on Desktop instances where Model Runner is enabled. The second option depends on trust in the callers that can reach the service. It should be understood with the advisory's attack sequence, which permits a container to initiate the malicious model pull and inference request.

My preference is to keep optional host execution capabilities explicit. Model inference can justify a service outside the application container, but that service needs its own artifact trust policy. The vulnerability demonstrates why the permission to request inference and the permission to run a model publisher's implementation code need separate treatment.

The workaround also helps explain the threat model. Disabling the service removes the documented request path. Restricting containers instead leaves the service available but narrows the set of callers trusted to initiate model loading. Those choices impose different functional costs. The first removes local model inference through Model Runner, while the second constrains the workloads that can share the Desktop instance. Neither statement requires assuming a kernel defect or a privileged application container. Docker locates the failure in the service that accepts model requests and in the code-loading behavior of its MLX backend.

What today's disclosure establishes

The May 22 record supplies the mechanism behind an April security update and credits David Rochester and Nicholas Gould as finders. It gives enough detail to identify the affected backend and the crossing of the host boundary. It does not establish that this issue was exploited in the wild, so an exploitation claim would go beyond the published evidence.

For an affected Mac, the concrete remediation is Desktop 4.71.0 or a later patched release. For a review of the failure itself, the decisive point is the import performed by MLX-LM under the Desktop user's account. A model-loading API reachable from a container accepted an artifact whose configuration selected host-executed Python, and the backend provided no sandbox to contain that execution.