Docker MCP Plugin: RCE via OCI Label, Urgent…

ZDI-26-363: The YAML label io.docker.server.metadata in the Docker MCP Gateway enables remote code execution as root. The fix isolates descriptive fields from runtime fields.

The Zero Day Initiative published advisory ZDI-26-363 on June 24, 2026, documenting a remote code execution vulnerability in the Docker MCP Plugin. The flaw allows an attacker to achieve root execution on the host by tricking the victim into referencing a malicious Docker image. The mechanism exploits not a bug in the runtime, but in the gateway code that prepares the docker run command, rendering the system-applied --security-opt no-new-privileges flag ineffective.

Key Takeaways

Advisory ZDI-26-363 confirms remote RCE on Docker MCP Plugin installations with user interaction: the victim must reference an image via the docker:// URI scheme.
The vector is the OCI label io.docker.server.metadata, whose YAML content is unmarshalled directly into a Go struct containing container runtime fields.
Fields Volumes, User, Command, ExtraHosts are appended as docker run flags without an allowlist, enabling arbitrary mounts and execution as UID 0.
The fix, documented in GitHub Security Advisory GHSA-r2xf-7jw5-pjg6 published June 16, 2026, restricts the parser to descriptive fields only.

How the OCI Label Becomes Command Execution

The specific flaw lies in the handling of the OCI label io.docker.server.metadata. According to the GitHub Security Advisory, this label is deserialized from YAML directly into the catalog.Server struct, a Go structure that carries both descriptive metadata and fields that shape container execution.

The MCP gateway code invokes these fields to build the docker run command line. No step filters or validates the mapping: values pass through as -v, -u, --add-host flags. An attacker who controls the label of an OCI image can inject -v /:/host to mount the host root, -u root to force UID 0, or -v /var/run/docker.sock:/var/run/docker.sock to expose the Docker socket.

Execution occurs as root on the host machine. The GitHub advisory notes that the container/host trust boundary is bypassed at container-creation time: the escalation requires no post-start exploit. The container does not need to acquire additional privileges; it receives them from the gateway at creation.

Why --security-opt no-new-privileges Does Not Protect

The Docker MCP Gateway applies the --security-opt no-new-privileges flag to containers it launches. This measure prevents a process from gaining new capabilities via execve. In the ZDI-26-363 attack chain, the flag is ineffective because the compromise occurs before the container exists.

Container security assumes the trust boundary is established at creation time: whoever controls the docker run parameters controls the container. When those parameters derive from an unverified OCI label, the trust boundary collapses onto the image source. The GitHub advisory states it plainly: "The container/host trust boundary is bypassed at container-creation time, so the --security-opt no-new-privileges flag the gateway applies provides no protection: no in-container privilege escalation is needed."

Jabr Al-Otaibi's Disclosure and the Vendor Fix

Jabr Al-Otaibi, researcher with handle @DarkCov, reported the vulnerability on May 20, 2026, in collaboration with Trend Micro's Zero Day Initiative. The GitHub Security Advisory was released June 16, 2026; the coordinated ZDI release followed on June 24, 2026.

The fix modifies the OCI label parser to populate only descriptive fields, excluding those that control runtime. It is an architectural separation of the parsing surface from the control surface. Sources do not specify a commit hash or exact patched package version.

"A maliciously crafted OCI image label can inject arbitrary arguments into the docker run command line constructed by the MCP Gateway." — GitHub Security Advisory GHSA-r2xf-7jw5-pjg6

What to Do Now

Organizations running Docker MCP Gateway must apply the official fix as soon as the vendor makes a packaged version available. Any instance processing OCI labels from sources not explicitly trusted remains exposed.

The CVSS 4.0 vector published by GitHub — AV:L/AC:L/AT:P/PR:N/UI:A/VC:R/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H — encodes high impact on confidentiality, integrity, and availability. The aggregate numerical score is not reported in available sources.

Verification efforts should focus on two points: confirm that the gateway in use processes labels only from images with controlled provenance, and verify that the installed version includes the restrictive parser. No alternative workaround to the patch is documented in sources.

Limits Documented in Primary Sources

Available primary sources present explicit limits. The CVE ID is not yet assigned or does not appear in consulted sources. The numerical CVSS is not calculated or published: only the vector string is available. Specific affected versions of the Docker MCP Plugin are not numerically enumerated. Sources do not indicate whether in-the-wild exploits exist, nor is the number of potentially vulnerable installations estimated.

The Architectural Pattern Behind ZDI-26-363

Vulnerability ZDI-26-363 illustrates a data-code boundary pattern: a field conceived for descriptive metadata is repurposed for execution parameters. The missing separation between descriptive surface and control surface is the architectural defect that makes the attack possible.

The case stands apart from other container compromises by its temporality. Execution occurs at creation time, not during runtime. This renders standard post-start countermeasures inapplicable.

The vendor's response — cleanly separating descriptive fields from runtime fields in the parser — confirms the diagnosis: the problem is structural, not implementational. The fix does not add validation on dangerous fields; it removes them from the parsing surface.

For organizations, the operational lesson lies in controlling image provenance. The MCP gateway can no longer be considered a safe indirection layer: if it processes OCI labels, the trust chain ends at the image builder, not the gateway.

Information verified against cited sources and current as of publication.

Sources

Sources and references