Docker Model Runner exposed runtime configuration to containers

A container did not need a mounted host directory to reach the vulnerable Docker Model Runner configuration service. The service was available at model-runner.docker.internal, and its configuration endpoint accepted runtime flags without authentication. One accepted flag selected a log file. That made a setting for an inference server into a way to overwrite files with the permissions of the Model Runner process.

Docker's Model Runner advisory, published February 27, identifies this as CVE-2026-28400. Nitesh Surana of TrendAI Research reported it. The advisory describes destructive file overwrite and a conditional route to container escape. Those consequences deserve separate treatment because the conditions for one are not automatically the conditions for the other.

The surrounding release is Docker Desktop 4.62.0, dated February 23. Its security section lists this vulnerability alongside a gRPC-FUSE out-of-bounds read. The Model Runner advisory gives more specific remediation information than that release-note entry. It names Model Runner 1.0.16 as patched and tells Desktop users to update to 4.61.0 or later. Treating 4.62.0 as the first fixed Desktop version for Model Runner would misstate the advisory.

The configuration endpoint granted file-writing authority

The vulnerable request was a POST to /engines/_configure. Model Runner passed supplied runtime flags directly to llama.cpp, the underlying inference server. According to the advisory, an attacker who could reach the API could inject --log-file and select a file accessible to the Model Runner process. The resulting write could create a file or overwrite an existing one.

This mechanism does not require a shell to reinterpret a command string. The dangerous meaning is already present in a legitimate program option. A configuration service can therefore avoid shell expansion and still grant excessive authority if the caller controls options that select filesystem paths. Quoting an argument correctly does not make the requested file operation appropriate.

There is a useful distinction between permission to submit inference work and permission to configure the process that executes it. The former needs access to a model-serving API. The latter can affect resources owned by that service. In this case, the reported endpoint did not authenticate the caller before accepting arbitrary runtime flags. A network connection to the service was enough to reach configuration behavior with consequences outside an individual inference response.

My interest in Docker has always been its repeatable build file and its ability to move an environment between machines. A multi-stage build ending in a scratch image with one static Go binary remains my preferred way to ship a service. This advisory concerns a different part of the product, but it affects how much isolation that service can assume when somebody runs it on a development machine.

The application inside an image does not choose every service made available by its execution environment. Here, Docker's advisory says Model Runner has been enabled by default in Desktop since 4.46.0 and is reachable from default containers without authentication. A small application image consequently does not establish that the application has access only to small, narrowly privileged services. The surrounding Desktop installation contributes to its effective capabilities.

Destruction and escape have different conditions

The advisory gives Docker.raw, the Docker Desktop VM disk, as a possible overwrite target. It describes destruction of containers and images, along with volumes and build history. The significance is the shared resource involved. Damage to the VM disk can extend beyond the particular container that reached the service.

That changes the recovery problem. A disposable container can be recreated, but a volume may hold state that its image cannot reproduce. Build history and local images have different recovery costs again. The file overwrite described here can affect all of them through their common storage. Classifying a workload as disposable says little about the value of everything else stored by the same Desktop installation.

The advisory also says that specific configurations, together with user interaction, can turn the vulnerability into a container escape. It does not describe every affected installation as an automatic host-code-execution case. The file overwrite is the concrete capability described in the impact section. Escape is a further outcome with additional conditions.

That distinction helps explain the practical scope without minimizing it. Destructive access to local development state is sufficient reason to patch even when an escape chain is unavailable. Conversely, a possible escape should not become an unsupported claim that every container can execute arbitrary host commands. The published conditions matter to anyone trying to establish which consequence applies to a particular installation.

The write also runs under the Model Runner process's permissions. That qualification belongs in the threat description because it defines which paths the primitive can affect. The problem is a caller obtaining another process's file-writing capability through a configuration API. An inventory of host mounts alone would miss the authority delegated through that service.

The component version resolves the release-note ambiguity

Two version numbers matter for remediation. The GitHub advisory lists affected Model Runner versions below 1.0.16 and identifies 1.0.16 as patched. Its Desktop recommendation is 4.61.0 or later. The February 23 Desktop 4.62.0 release notes also say they address CVE-2026-28400. These statements should be reported together, with the advisory supplying the fixed-version guidance.

For a component distributed inside a larger application, a security entry in the application's next changelog is insufficient evidence of the first fixed component bundle. The advisory explicitly answers that question here. A vulnerability report that looks only for the CVE in release-note headings can therefore produce a different minimum version from the one the component maintainer gives.

The separate gRPC-FUSE issue makes the distinction operationally relevant. Docker's CVE record for CVE-2026-2664 identifies Desktop versions before 4.62.0 as affected. Thus the Model Runner recommendation does not imply that 4.61.0 fixes both vulnerabilities discussed in the 4.62.0 release. Each defect needs its own version boundary.

An installation record should retain the product version and the affected component when an advisory names both. Otherwise, a statement that Desktop is patched can conceal which vulnerability somebody checked. For this event, the most precise account is that the Model Runner advisory identifies an earlier fixed Desktop bundle, while the gRPC-FUSE record requires the February 23 release.

Isolation blocks a route, with a stated exception

Docker documents Enhanced Container Isolation as a workaround because it blocks container access to Model Runner. The same advisory warns that exposing Model Runner to localhost over TCP in specific configurations can leave the vulnerability exploitable. That exception limits what the workaround proves. Blocking one route to an API does not repair the API's behavior if another route remains available.

This is why I care about the destination of a container's network requests as well as its filesystem mounts. An accessible service may perform an operation using permissions the calling container does not possess directly. Restricting that connection can remove the delegation path, while updating the service addresses the vulnerable implementation. The advisory supplies a reason to consider both without treating the workaround as equivalent to the patch.

The distinction also matters for installations that deliberately expose local model serving to additional clients. The word localhost describes an address, but the relevant security question is which callers can reach the exposed endpoint under that configuration. Docker's warning specifically preserves an exception for TCP exposure. An exposure assessment needs to account for that exception before treating Enhanced Container Isolation as complete mitigation.

gRPC-FUSE has a separate input-validation defect

CVE-2026-2664 concerns the grpcfuse kernel module inside Desktop's Linux VM on Windows, Linux, and macOS. Docker's CVE description says a local attacker could trigger an out-of-bounds read by writing to /proc/docker entries. It identifies Desktop 4.62.0 as the fix. This is a separate mechanism from Model Runner accepting an inference-server option.

The February 25 disclosure from Zero Day Initiative explains the memory error more closely. Procfs argument handling failed to validate user-supplied data properly, allowing a read past an allocated buffer. The disclosure describes information exposure and says an attacker would first need the ability to execute low-privileged code. It credits Pumpkin of DEVCORE Research Team.

ZDI discusses combining the flaw with other vulnerabilities to escalate privileges and execute kernel-context code. That is a statement about a chain, not proof that an out-of-bounds read alone supplies arbitrary execution. The distinction mirrors the care needed with Model Runner's conditional escape, although the underlying defects are different. One grants an unsafe configuration operation, while the other mishandles the bounds of input consumed by kernel code.

Desktop 4.62.0 also adds named MCP server profiles and custom catalogs, according to its release notes. Those additions make it easier to organize services supplied through Desktop. The security disclosures make the authority of those surrounding services relevant to the same installation. For the two reported vulnerabilities, the actionable version information remains specific to each component, with Desktop 4.62.0 covering the gRPC-FUSE fix as well as the Model Runner issue listed in its notes.