GPU VulnDB

Database/Container, Kubernetes & orchestration

Docker MCP Gateway: OCI image label controls run arguments, allowing host mounts and UID 0

CVSS 8.7CVE-2026-55887Container, Kubernetes & orchestrationcurated

Impact

For direct docker:// references and catalog snapshot imports, the gateway YAML-unmarshalled the attacker-controlled io.docker.server.metadata image label into the broad catalog.Server struct, then appended runtime-shaping fields - Volumes, User, ExtraHosts - to the docker run argument vector with no origin allowlist. A malicious image author can therefore have the victim's own gateway mount the host filesystem or the Docker socket and run the container as UID 0. Because the boundary is crossed at container-creation time rather than inside the container, no-new-privileges does not help: no in-container escalation is needed. Where MCP gateways run on shared agent hosts pulling third-party server images, one attractive image is enough to get code execution as the daemon's host user and, via the socket, control of every container on the box.

Who can reach it

A local Docker MCP Gateway user who selects or pulls a malicious image, or imports a catalog snapshot referencing one. No credentials needed by the attacker; the victim's act of pulling or running the image is the trigger.

What to do

Upgrade Docker MCP Gateway to 0.42.2, which applies an origin allowlist to the label-derived runtime fields, and restart the gateway process. No node reboot. Until then, run only images from catalogs you control, avoid importing untrusted catalog snapshots, and do not run the gateway on a host where the Docker socket grants more than you are willing to lose.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.