Docker (supernova123) MCP Server

Tools that read sensitive data ([compose_logs]) and tools that can send data out ([exec_in_container]) are exposed together. An agent can move private data to the sink.

Evidence: sources [compose_logs] → sinks [exec_in_container]

Fix: Keep secret-reading and egress capabilities on separate, separately-approved servers.

Location: flow compose_logs → exec_in_container

Tool "exec_in_container" appears to run shell commands or evaluate code (keyword "exec" in tool name). Arbitrary execution driven by model input is one of the most dangerous MCP capabilities; combined with any untrusted input it becomes RCE.

Fix: Sandbox execution, allowlist commands/arguments, and never pass model output to a shell unescaped.

Location: tool exec_in_container

In the server's implementation (`dist/tools/compose.js:1`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: exec as execCb } from "child_process"; import { existsSync, statSync } from "fs"; import { join } from "path"; import {

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server dist/tools/compose.js

In the server's implementation (`dist/tools/health.js:4`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: (checks port open), and exec (runs command inside container). Auto-detects probe type from the container's HEALTHCHECK c

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server dist/tools/health.js

In the server's implementation (`src/tools/compose.ts:1`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: exec as execCb } from "child_process"; import { existsSync, statSync } from "fs"; import { join } from "path"; import {

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server src/tools/compose.ts

In the server's implementation (`src/tools/health.ts:9`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: (checks port open), and exec (runs command inside container). Auto-detects probe type from the container's HEALTHCHECK c

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server src/tools/health.ts

In the server's implementation (`dist/tools/compose.js:29`): A shell/process command assembled from concatenated or interpolated values is command injection when any part is attacker-influenced — the OWASP canonical RCE flow. Verify what reaches the interpolated value. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: const result = execSync(`docker compose -f "${filePath}" ${args.join(" ")}`, { encoding: "utf-8",

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server dist/tools/compose.js

In the server's implementation (`src/tools/compose.ts:39`): A shell/process command assembled from concatenated or interpolated values is command injection when any part is attacker-influenced — the OWASP canonical RCE flow. Verify what reaches the interpolated value. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: ry { const result = execSync(`docker compose -f "${filePath}" ${args.join(" ")}`, { encoding: "utf-8", t

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server src/tools/compose.ts

Tool "exec_in_container" can mutate/egress but declares no destructiveHint. Clients that don't default to spec-safe behavior may not prompt before running it.

Fix: Declare accurate annotations, and gate destructive tools on user confirmation regardless.

Location: tool exec_in_container

In a packaging/dev/install script (shipped, but not the server runtime) (`tests/compose.test.ts:10`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: vi.fn(), })); vi.mock("child_process", () => ({ execSync: mockExecSync, exec: vi.fn(), })); vi.mock("fs", () => ({

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server tests/compose.test.ts