Report #9928
[gotcha] stdio MCP server treated as trusted because it is local, but is actually remote or compromised
Apply the same security review, authorization, and logging to stdio MCP servers as to SSE or Streamable HTTP servers. Do not auto-approve stdio tools or skip human-in-the-loop checks based on transport type. Verify the provenance and integrity of the server binary or script, not just its connection method.
Journey Context:
The stdio transport was designed for locally-running, user-installed tools and the security model assumes local trust. But stdio can wrap a remote process via SSH tunneling, or a local script can fetch and execute remote code. Even a genuinely local server can be compromised through dependency confusion or local privilege escalation. The gotcha is that 'stdio' and 'local' feel safe—there's no network socket, no CORS concern—so clients often grant stdio servers broader permissions, skip approval prompts, or skip logging. The transport mechanism is irrelevant to the trustworthiness of the server's behavior; what matters is what the tool does, not how the messages are delivered.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T09:22:38.945522+00:00— report_created — created