AIDEFEND in Action AIA-0105 Validated Research Published: Oct 26, 2026

Docker MCP Gateway: Image Metadata Becomes Host-Mount Authority

Docker MCP Gateway launches tool servers from container images. CVE-2026-55887 allowed attacker-controlled OCI image metadata to populate privileged runtime fields, which became docker run arguments. The disclosed path can mount the host and Docker socket and run as root. Docker fixed versions before 0.42.2; neither prompt filtering nor no-new-privileges repairs these creation-time grants.

Tool Argument TamperingSupply Chain DefenseRuntime IsolationMCP SecurityAI Infrastructure
3 applicable AIDEFEND defenses
Source: Argument injection via OCI image label YAML in Docker MCP Gateway 
Author: @mickael-docker / Docker
Original article: Jun 16, 2026

Threat Analysis

  • Metadata becomes authority: the attacker controls image-label YAML, which populates runtime configuration and then Docker arguments. A description supplied by an image has crossed into permission to mount the host.
  • The container starts privileged: root identity and host mounts are granted at creation. A flag preventing later privilege acquisition does not remove access already handed to the container. No model decision is required.
  • Contain the engine as well as the tool: isolating only the launched container is insufficient when the Gateway can ask a host Docker daemon to create broader mounts. The engine and Gateway must share the restricted outer boundary.

Applicable AIDEFEND Defenses (3)

AID-H-003.010
Deployed AI Software Vulnerability Remediation Lifecycle
Very High
Replace affected Gateway binaries with 0.42.2 or a later supported fixed release and verify the binary actually constructing container arguments. Test a synthetic image whose metadata requests unauthorized volumes, user and command fields, and require rejection or policy-owned runtime values before Docker receives the request. Reconcile all catalog/snapshot and docker:// paths. The corrected parser must not let an image assign its own privileged runtime configuration.
AID-I-001.002
MicroVM & Low-Level Sandboxing
High
For a managed high-risk deployment, run the Gateway and its dedicated Docker engine inside a verified hardware-virtualized runtime, with no outer-host mounts, Docker socket or privileged management channel exposed to that guest. The guidance requires an operator-owned runtime profile, attested effective runtime and no-fallback admission tests; a container label or ordinary Docker-in-Docker alone is insufficient. Even if the guest daemon is compromised, this limits outer-host impact. It is a containment deployment, not a repair of image metadata parsing.
AID-H-034.001
MCP Server Deployment Profile, Transport & Exposure Baseline
High
The runtime owner can enforce the MCP server baseline independently at Docker container creation: reject root, host-root/socket mounts, privileged or host-namespace settings and commands outside an approved profile. A daemon authorization plugin or equivalent protected launch broker must examine the final Engine JSON with matching decoding semantics and deny uninspected or alternate routes, including unsupported gRPC/upgrade paths. Read back effective mounts/user/capabilities. A Kubernetes securityContext file, image USER, read-only rootfs or no-new-privileges alone cannot override injected Docker grants.

What Defenders Should Do Now

  • Upgrade the effective Gateway binary and test every image intake route with synthetic prohibited metadata, observing actual Docker requests.
  • Keep runtime privileges under administrator policy and review images before use. A digest or signature identifies bytes; it does not make attacker-requested mounts acceptable.
  • Where stronger containment is required, isolate the Gateway and its dedicated engine together. Verify no outer-host socket, mounts or management bypass undermines that boundary.
  • Put an independent final container-creation policy in front of the actual Docker engine, covering mounts, user, namespaces, capabilities and command. Audit unsupported daemon routes before treating an authorization plugin as enforcement.

Conclusion

AIDEFEND  maps this case to verified Gateway remediation and stronger runtime containment. The trust rule is concrete: a tool image may provide descriptive data, while the defender retains authority over its user, command and host mounts.

Last updated: