Metadata as an Attack Surface

Docker images contain metadata. This is by design - labels, descriptions, author information, and other annotations are used to document images, configure automation, and provide context to tools that interact with them. Dockerfile LABEL fields are a standard, ubiquitous mechanism for attaching this metadata. They're informational. They're inert. Or at least, they used to be.

When Docker introduced Ask Gordon, an AI assistant integrated into Docker Desktop and the Docker CLI, it gave the AI the ability to read image metadata as part of its context-gathering process. The Model Context Protocol (MCP) acts as a bridge between the language model and the local environment - files, containers, databases, and system configuration. Gordon uses MCP to understand what's happening in the Docker environment and provide helpful responses to user queries.

Noma Labs, the cybersecurity firm that discovered the vulnerability, identified the fundamental problem: the MCP Gateway cannot distinguish between informational metadata (like a standard Docker LABEL saying the image was built on Tuesday) and a pre-authorized, runnable instruction. To the Gateway, context is context. If Gordon reads it and interprets it as something to act on, the Gateway executes it. No validation step exists between "Gordon reads a label" and "Gordon runs a command."

The Three-Stage Attack

The attack Noma Labs demonstrated, codenamed DockerDash, proceeds through three stages that each happen with zero validation:

Stage one: An attacker embeds malicious instructions inside a Docker image's LABEL fields. These labels look like ordinary metadata to anyone inspecting the image manually or through conventional tools. The instructions are crafted to be interpreted by an AI assistant as executable directives.

Stage two: When a user asks Gordon a question about the image - anything that causes Gordon to read the image's metadata - the AI reads the malicious labels as part of its context. Gordon treats the metadata as trustworthy input and forwards the interpreted instruction to the MCP Gateway.

Stage three: The MCP Gateway receives what it treats as a legitimate command from Gordon and executes it through MCP tools. In cloud and CLI environments, this means arbitrary command execution. In Docker Desktop, where Gordon operates with read-only permissions, the attack shifts to data exfiltration and reconnaissance.

Noma Labs called the underlying technique "Meta-Context Injection" - a name that captures what makes this vulnerability different from a traditional prompt injection. The attack doesn't require tricking a user into entering a malicious prompt. It works by poisoning the context that the AI automatically ingests when performing its normal function. The user doesn't have to do anything wrong. They just have to ask Gordon a question about an image that someone has already poisoned.

Two Paths, Same Entry Point

The impact of DockerDash diverges depending on the deployment environment, but the initial attack vector is identical.

In cloud and CLI systems, where Docker commands run with elevated privileges, the vulnerability enables critical-impact remote code execution. An attacker's instructions, embedded in image metadata, can be translated by Gordon into Docker CLI commands that execute on the host system. This is the kind of access that would normally require compromising a user's credentials or exploiting a software bug in Docker itself. Instead, it requires writing a text string in a LABEL field.

In Docker Desktop, the attack produces a different but still severe outcome. Because Gordon operates with read-only permissions in the Desktop environment, direct command execution is limited. However, attackers can still exfiltrate sensitive data - container configurations, environment variables, network settings, installed MCP tools, images, and system configuration. The exfiltration works by instructing Gordon to embed collected data into outbound requests, bypassing controls that focus on command execution rather than unauthorized reads.

In both cases, the attack enables enumeration of the victim's Docker environment, providing detailed reconnaissance for further exploitation.

The Disclosure and Fix

The timeline on this one is worth noting for its relative professionalism. Noma Labs discovered and reported DockerDash to Docker's security team on September 17, 2025. Docker confirmed the vulnerability on October 13, 2025. The fix shipped in Docker Desktop version 4.50.0 on November 6, 2025. Public disclosure followed on February 3, 2026.

Docker's response implemented two mitigations that address the vulnerability's mechanics directly. First, Gordon no longer renders user-provided image URLs, blocking the data exfiltration path that relied on injecting attacker-controlled URLs into Gordon's output. Second, Gordon now requires explicit user confirmation before executing any MCP tool - whether built-in Docker CLI commands or user-added custom MCP servers. This human-in-the-loop control breaks the automated execution chain that made DockerDash possible.

Both mitigations are sensible. The URL blocking eliminates a specific exfiltration technique. The human-in-the-loop requirement addresses the broader architectural problem: an AI assistant shouldn't be able to silently translate metadata into executable actions without a human deciding whether that's appropriate.

The MCP Trust Problem

DockerDash is part of a pattern that extends well beyond Docker. The Model Context Protocol is increasingly used to connect AI assistants to local environments, and the trust model it operates under is fundamentally permissive. MCP is designed to provide context - to give AI access to the information it needs to be helpful. But "context" and "instructions" are not categories that current MCP Gateway implementations reliably distinguish between.

When you design a protocol for feeding information to an AI, and the AI has the ability to request tool execution based on that information, you've created a system where data can become commands. The distinction between "here is some metadata about this image" and "here is an instruction to execute" exists in the minds of human architects, but not reliably in the execution chain. The AI interprets, the Gateway relays, the tool executes. The question "should this actually be done?" gets asked only if someone explicitly inserts a step to ask it.

Docker's fix - requiring user confirmation - is that inserted step. But it's a fix applied at the application level to a problem that exists at the protocol level. Every MCP-connected AI assistant that can read untrusted input and invoke tools faces some version of the same vulnerability. The specific details will vary (Docker labels in this case, file contents or web pages in others), but the structural issue is consistent: treating context as trustworthy creates an attack surface wherever untrusted data enters the context.

For Docker users, the immediate action is simple: upgrade to version 4.50.0 or later. For the broader ecosystem of AI-integrated development tools, DockerDash is an illustration of what happens when the things AI reads and the things AI does share the same trust boundary - and nobody notices until a security researcher puts an instruction in a LABEL field.