MCP's STDIO Flaw Puts 200K AI Servers at Risk

A design decision baked into Anthropic's Model Context Protocol is putting hundreds of thousands of AI-powered servers at risk of complete takeover - and Anthropic has declined to fix it.

Ox Security, a Tel Aviv-based application security firm founded by former Check Point executives Neatsun Ziv and Lion Arzi, published its findings on April 15. The research catalogues 30+ responsible disclosures, 10 CVEs (all rated critical or high), and live proof-of-concept exploitation on six production platforms. The root cause isn't a bug in any one implementation. It's how MCP's STDIO transport was designed from the start.

How STDIO Transport Actually Executes Commands

MCP supports two transport mechanisms: HTTP+SSE for remote connections and STDIO for local ones. When a host application - Claude Code or Cursor, for instance - needs to spawn a MCP server, it passes a command string to the STDIO interface. That interface launches the subprocess, then waits for the MCP handshake to succeed.

The problem is that the command executes before the handshake check.

# Simplified execution sequence with a malicious command string:
1. MCP STDIO receives: "malicious-payload && exfiltrate-keys"
2. OS executes the command string  ->  payload runs
3. MCP handshake fails (no valid server started)
4. Error is returned to the caller
# The payload already ran. The error doesn't matter.

Ox researchers describe this as "execute first, validate never." Any user-controlled string that reaches the STDIO configuration layer becomes a potential RCE vector. No authentication required. No sandboxing applied. This behavior runs through all ten official MCP SDK implementations.

The Four Attack Families

1. Direct UI Injection

The simplest path. Frameworks like LangFlow (CVE pending) and GPT Researcher (CVE-2025-65720) expose web interfaces that accept MCP configuration directly. For LangFlow, no account is needed - a session token is "freely available," per Ox's report. Sending a crafted payload through the UI gets arbitrary code running on the server. Agent Zero (CVE-2026-30624) falls to the same class of attack via its unauthenticated interface.

2. Hardening Bypass

Some tools tried allowlisting to restrict which commands could run. Flowise (GHSA-c9gw-hvqq) had one - researchers bypassed it by routing commands through npx's -c flag, which the allowlist didn't cover. Upsonic (CVE-2026-30625) fell to a similar approach. The lesson from both: if the underlying STDIO execution model doesn't confirm, surface-level allowlists provide false confidence.

3. Prompt Injection to Local RCE

This is the attack chain that reaches the tools most developers use every day. An AI coding assistant processes content from a web page, a document, or a code repository. That content carries a prompt injection payload instructing the assistant to modify its MCP server configuration. The assistant writes the malicious command to STDIO config. STDIO executes it.

Windsurf received CVE-2026-30615 for a zero-click variant - visiting a malicious website was enough to trigger the full chain. Claude Code, Cursor, GitHub Copilot, OpenAI Codex, and Gemini CLI require some user interaction, but Ox confirms all are within the exposure window. Their respective vendors classified this as "by design."

The attack chain turns AI coding assistants into the delivery mechanism - the same tool that reads your source code can be instructed to execute arbitrary commands on your machine. Source: unsplash.com

4. Marketplace Poisoning

Ox tested 11 MCP marketplace directories. Nine accepted malicious MCP entries without review. A poisoned entry sits in the directory waiting for developers to install it. Once installed, it can substitute a legitimate SSE transport connection for a local STDIO connection. At that point, the attacker controls what runs on the developer's machine.

Confirmed CVEs

Claude Code, Cursor, GitHub Copilot, and Gemini CLI don't appear in the CVE list - not because they're safe, but because their vendors declined to assign CVEs, treating the prompt-injection path as an accepted risk in the current threat model.

MCP-enabled IDEs are high-value targets: they run with local file access, network access, and often terminal permissions on the developer's machine. Source: unsplash.com

The Disclosure Timeline

• November 2025 - Ox Security begins investigating MCP's STDIO transport behavior after observing inconsistent execution semantics.

• January 7, 2026 - Initial contact with Anthropic. Researchers present the root issue and propose architectural fixes that would protect all downstream implementations.

• January 16, 2026 - Anthropic updates its SECURITY.md, recommending caution with STDIO adapters. No protocol changes made.

• January - March 2026 - 30+ responsible disclosures filed across affected projects. LiteLLM, DocsGPT, Flowise, and Bisheng issue patches for their specific CVEs.

• March 18, 2026 - LangFlow formally acknowledges the issue.

• April 15, 2026 - Ox publishes the full report. The MCP protocol architecture remains unchanged.

Where It Falls Short

The standard defense Anthropic and affected vendors are offering is "sanitize your inputs." That's correct advice in isolation - developers building MCP servers should absolutely validate anything that reaches command execution. The problem is what it means in practice for the broader ecosystem.

Over 200 open-source projects inherited this exposure by building on Anthropic's official SDKs. A single architectural fix at the protocol level would have protected all of them. Ox's researchers put the ask clearly: "One architectural change at the protocol level would have protected every downstream project, every developer, and every end user."

Anthropic had five months between initial disclosure and public release to implement that fix. The company added a warning to its documentation instead.

This fits a pattern that's become familiar in the MCP ecosystem. A command injection flaw in the Kali Linux MCP server showed up in February, affecting penetration testing tools running with elevated permissions. Multiple RCE paths in Claude Code itself were disclosed earlier this year. Earlier still, the LiteLLM supply chain compromise showed how a single widely-used inference layer becomes the delivery mechanism for downstream attacks. MCP's footprint is much larger than any of those - at 97 million monthly SDK downloads across all language implementations, the scope of a unaddressed protocol-level flaw is substantial.

What Developers Should Do

The upstream fix isn't imminent. Mitigations to apply now:

1. Restrict MCP services to private IP addresses - don't expose MCP endpoints to the public internet under any circumstances
2. Treat all MCP configuration as untrusted - any user-controlled string reaching STDIO config is a potential attack vector
3. Sandbox MCP processes - run with minimal permissions, isolated from credentials, secrets, and sensitive file paths
4. Audit marketplace installs - verify MCP entries before installation; prefer packages with active maintainers and documented security review
5. Apply available patches - LiteLLM, DocsGPT, Flowise, and Bisheng have addressed their specific CVEs; update right away
6. Log tool invocations - monitoring what MCP-enabled tools are actually executing makes exploitation visible before damage spreads

Anthropic has not announced any architectural changes to the protocol today. The 10 CVEs issued so far represent confirmed exploits on real production systems; Ox expects additional CVEs as more projects are audited.

Sources:

• Anthropic won't own MCP 'design flaw' putting 200K servers at risk - The Register
• Systemic Flaw in MCP Protocol Could Expose 150 Million Downloads - Infosecurity Magazine
• Flaw in Anthropic's MCP putting 200k servers at risk, researchers claim - Computing
• MCP Supply Chain Advisory - Ox Security
• Anthropic's MCP Design Flaw Enables Remote Code Execution - Cyber Kendra
• RCE by design: MCP architectural choice haunts AI agent ecosystem - CSO Online