docker-mcp EUVD-2026-109587

Exploitation requires docker-mcp version 0.1.0 or 0.2.0 running on Windows, because the vulnerable code path is the Windows-specific _build_windows_command function in docker_executor.py, and the attacker must be able to supply or influence the project_name argument passed into that Docker command builder. The CVSS UI:P metric indicates a user or agent action is needed to invoke the vulnerable tool, so it does not fire passively. Limiting factors: only the two early versions are named as affected, the Windows command-construction path is required (non-Windows deployments use a different path), and the attacker must reach and trigger the MCP tool interface; the 'remote' characterization depends on the server being network-exposed rather than local stdio.

Signals point to a moderate, not urgent, priority. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P, score 5.3) describes a network-reachable, low-complexity, unauthenticated flaw that still requires passive user interaction (UI:P), and VulDB scored all impacts Low (VC:L/VI:L/VA:L). The vuln.today decision label is 'this_month' - meaningfully below act_now/emergency. No CISA KEV listing is present, no EPSS probability was supplied, and no verified exploit code is indicated, so exploitation pressure appears speculative rather than demonstrated. There is tension worth flagging: the weakness is OS command injection (CWE-78), which normally grants arbitrary command execution, yet VulDB rated confidentiality/integrity/availability only Low - I assess the technical impact as higher than that rating (see assessed vector). Also note the 'initiate the attack remotely' claim contrasts with the typical deployment of MCP servers on localhost/stdio; AV:N should be verified against how the server is actually exposed. EPSS is simply absent (not low) - that is missing data, not a reassuring signal. Net: a real but niche medium-severity issue affecting a small developer tool, appropriate to patch on a routine cycle rather than as an emergency.

An attacker (or a prompt-injected AI agent) supplies a crafted project_name containing shell metacharacters to the docker-mcp server running on Windows; when _build_windows_command concatenates that unsanitized value into a command string, the injected commands execute on the host in the server's context. No verified public exploit is indicated, and the attack path needs the vulnerable tool to be invoked (UI:P), so it is not point-and-click against an idle service.