Technical description
OX Security researchers discovered that the Model Context Protocol's (MCP) STDIO transport—the default method for connecting AI agents to local tools—executes any operating system command it receives without sanitization. No execution boundary exists between configuration and command. A malicious command returns an error only after the command has already executed. OX Security scanned the ecosystem and found 7,000 servers on public IPs with STDIO transport active, extrapolating to an estimated 200,000 total vulnerable instances. The research team confirmed arbitrary command execution on six live production platforms with paying customers and produced more than 10 CVEs rated high or critical across LiteLLM, LangFlow, Flowise, Windsurf, Langchain-Chatchat, Bisheng, DocsGPT, GPT Researcher, Agent Zero, LettaAI, and others.
Attack vector
Four exploitation families identified: (1) Unauthenticated command injection through AI framework web interfaces (demonstrated against LangFlow and LiteLLM); (2) Hardening bypasses where OX bypassed command allowlists via argument injection (npx -c) in tools like Flowise and Upsonic; (3) Zero-click prompt injection in AI coding IDEs where malicious HTML modifies local MCP configuration files—Windsurf (CVE-2026-30615) required zero user interaction, while Cursor, Claude Code, and Gemini-CLI require user approval but do not surface execution consequences in the UI; (4) Malicious package distribution through MCP registries, where OX submitted a benign proof-of-concept to 11 registries and nine accepted it without security review. The insecurity is not a coding bug but a design default in Anthropic's MCP specification that propagated into every official language SDK (Python, TypeScript, Java, Rust).
Affected systems
All MCP deployments using the default STDIO transport. Confirmed vulnerable products include: LiteLLM (patched), LangFlow (partially patched), Flowise (hardening bypassed), Windsurf (CVE-2026-30615 patched), Langchain-Chatchat, Bisheng, DocsGPT, GPT Researcher, Agent Zero, LettaAI, Upsonic, Cursor, Claude Code, Gemini-CLI, NextChat (ChatGPTNextWeb, CVE-2026-7644), and at least 7 additional single-author GitHub MCP servers. Anthropic confirmed the behavior is by design and declined to modify the protocol, characterizing STDIO's execution model as a secure default with input sanitization as the developer's responsibility. OX Security counters that expecting 200,000 developers to sanitize inputs correctly is the systemic problem. The critical gap: every vendor patch fixes their product, but no patch changes the MCP protocol's STDIO behavior. A security director who patches LiteLLM today and configures a new MCP STDIO server tomorrow inherits the same insecure default.
Mitigation
Immediate: Treat MCP STDIO as a privileged execution surface, not a connector. Apply deny-by-default policies, allowlist specific commands, deploy sandbox controls, and stop assuming downstream input validation will hold at scale. For IDE deployments (Cursor, Claude Code, Gemini-CLI, Windsurf): verify that your vendor has patched prompt-injection-to-config-modification chains; check if configuration changes surface execution consequences in the UI before user approval. For AI framework deployments (LiteLLM, LangFlow, Flowise, etc.): apply vendor patches immediately, but recognize that the patches fix product-specific bugs, not the protocol design. Conduct an MCP deployment audit: identify all STDIO transports in your environment, map what OS-level access they have, apply least-privilege and network segmentation. Longer-term: consider migrating to SSE (server-sent events) transport where feasible, though this is not universally supported. Monitor MCP registry submissions if you allow developers to install community servers; 9 of 11 registries accepted a proof-of-concept without security review.