SURIQ
If you use Docker's MCP Gateway to run the small tool programs that AI assistants call (the servers behind the Model Context Protocol, or MCP), a single malicious container image can do far more than misbehave inside its sandbox. It can break out of the container and take over the host. Docker disclosed the flaw on June 24 as GHSA-r2xf-7jw5-pjg6, tracked as CVE-2026-55887 and rated 8.7 out of 10. The Zero Day Initiative, whose researcher reported it, published its own writeup as ZDI-26-363 (it scores the flaw 8.6). The fix shipped in version 0.42.2. If you run the gateway, updating is this week's work, and the reason is worth understanding because it is the kind of trust mistake that will keep happening as AI tooling grows.
What the MCP Gateway is, and why this reaches the host
Docker's MCP Gateway is the docker mcp command-line plugin, and the MCP Toolkit is built on top of it. It is how a growing number of teams run MCP servers: the small tool programs an AI assistant calls to read files, query a database, or hit an API. Each server runs in its own container, and the gateway is the thing that decides how to launch each one. To make those decisions, it reads metadata that the image carries with it.
That last part is the soft spot. A container is supposed to be a boundary, and the host is supposed to be in charge of how a container starts. Here, the image got to influence how the host launched it.
The bug: a label that turns into command-line arguments
Every OCI image (the standard format Docker images use) can carry labels, which are simple metadata strings baked into the image by whoever built it. The gateway read one specific label, io.docker.server.metadata, and parsed it as YAML. Per Docker's advisory, that parsed data was loaded straight into the structure the gateway uses to launch a server, and crucially that structure included fields the runtime obeys: which volumes to mount, which user to run as, what command to run, and which extra hosts to add. Those values then flowed into the docker run invocation with nothing checking them along the way.
In plain terms: the settings that decide what a container can mount, which user it runs as, and what it executes were lifted from a string an attacker controls and handed to the command that starts the container. So a hostile image author can set that label so the host mounts its entire filesystem into the container and runs it as the root user. From there, code in the container is code on the host, running as root. Docker classifies it as CWE-88, argument injection, and ZDI describes the root cause as a user-controlled string reaching a system-call argument without being validated first.
The CVE record is blunt about the payoff: an attacker whose image a victim references can mount the host's filesystem, run as user ID zero, and execute code of their choosing on the host itself.
What it takes to be hit
This is not a worm. The CVSS breakdown records that user interaction is required and that the attack is delivered locally rather than over the network. The trigger is the victim referencing the malicious image: either pointing the gateway at it directly through a docker:// reference, or having a catalog that pulls a snapshot from it. No password is needed on the attacker's side, and no prompt warns the victim, because to the gateway this looks like a normal image with normal metadata.
The exposed versions are 0.21.0 through 0.42.1. If your gateway falls in that range and it ever launches a server image you did not build yourself, you are in scope. As MCP catalogs grow and people pull tool servers the way they pull npm packages, "an image someone else built" stops being an edge case and becomes the normal case.
What to do this week
Three things, in order:
-
Update the gateway to 0.42.2 or later. In the patched build the parser reads only the descriptive parts of the label and ignores anything that would set runtime options, so the metadata can no longer steer
docker run. This is the real fix; everything else is containment. -
Treat MCP server images like any third-party dependency. Run servers only from images you trust or have reviewed, and be deliberate about what catalogs your gateway is allowed to pull from. The supply-chain question (who built this image, and why do I trust it) is the same one you already ask of packages and base images.
-
Hunt for the outcome, not just the version. The signature of exploitation is a container doing something a tool server never should: running as root, bind-mounting the host root (
/), or mounting the Docker socket (/var/run/docker.sock). Audit running and recent containers on any host that runs the gateway for those mounts and that user, and alert on them going forward. A host that flags any container mounting the host filesystem or the Docker socket it was not meant to touch will catch this class of escape even when the specific bug is new.
The pattern worth remembering
The interesting thing here is not one parser bug. It is that the boundary failed in the direction nobody was watching. Everyone treats the container as the thing to be contained; almost nobody treats the image's metadata as untrusted input that can reach back and reconfigure the host. AI tooling is now generating exactly this shape of risk at speed: agents pulling and running tool servers, catalogs aggregating images from many authors, and convenience layers that read "helpful" metadata to set things up automatically. Each one is a place where data from an outside author quietly becomes a decision the host makes. The fix in 0.42.2 closes this instance. The habit it should leave you with is to ask, of every new AI integration, which strings it trusts and what those strings are allowed to control.