200,000 MCP servers expose a command execution flaw that Anthropic calls a feature

Anthropic developed the Model Context Protocol (MCP) as a standard for communication between AI agents and tools. OpenAI adopted this standard in March 2025, followed by Google DeepMind. In December 2025, Anthropic donated MCP to the Linux Foundation. With over 150 million downloads, MCP faced a significant challenge when four researchers from OX Security discovered a critical architectural flaw affecting all implementations.

The MCP’s STDIO transport, which is the default for linking AI agents to local tools, executes any operating system command it receives without sanitization or an execution boundary. A malicious command can return an error post-execution, and the development toolchain does not flag this.

Researchers Moshe Siman Tov Bustan, Mustafa Naamnih, Nir Zadok, and Roni Bar from OX Security investigated the ecosystem and identified 7,000 servers with active STDIO transport on public IPs, estimating a total of 200,000 potentially vulnerable instances. They confirmed the execution of arbitrary commands on six active production platforms. This research led to more than ten high or critical CVEs across platforms like LiteLLM, LangFlow, Flowise, Windsurf, Langchain-Chatchat, Bisheng, DocsGPT, GPT Researcher, Agent Zero, LettaAI, and others.

Kevin Curran, an IEEE senior member and cybersecurity professor at Ulster University, told Infosecurity Magazine that the research highlighted “a shocking gap in the security of foundational AI infrastructure.”

Anthropic acknowledged the behavior as intentional and opted not to alter the protocol, describing STDIO’s execution model as secure by default, with input sanitization as the developer’s duty. This characterization was attributed to OX, as Anthropic’s only public statement was that the behavior was “expected.” Anthropic has not made a separate public announcement and did not respond to VentureBeat’s request for comment.

OX argues that relying on 200,000 developers to sanitize inputs is problematic. Anthropic counters that sanitizing STDIO would either disrupt the transport or shift the payload to another layer. Both arguments have merit, leaving the question of how to proceed unresolved.

While major outlets covered the disclosure, none provided the in-depth product-by-product audit necessary for a security director to assess MCP deployments. This article aims to fill that gap.

Five key questions assess if your MCP deployments are exposed, if patches are effective, and what actions to take starting Monday.

Am I exposed?

If your teams deployed any AI agent using MCP with the default STDIO transport, you are exposed. This is not a coding flaw in a particular product, but a design default in Anthropic’s MCP specification, which has been integrated into every official SDK: Python, TypeScript, Java, and Rust. Any downstream project relying on the protocol is affected.

OX identified four exploitation categories: unauthenticated command injection via AI framework web interfaces (seen in LangFlow and LiteLLM), bypasses in tools with command allowlists (seen in Flowise and Upsonic), zero-click prompt injection in AI coding IDEs (notably in Windsurf, CVE-2026-30615), and malicious package distribution through MCP registries.

Carter Rees, VP of AI and Machine Learning at Reputation and a member of the Utah AI Commission, told VentureBeat that the approach needs a shift. “MCP stdio is a privileged execution surface, not a connector. Enterprise teams should treat it like production shell access. Deny by default, allowlist, sandbox, and stop assuming downstream input validation will hold at scale,” Rees said.

The IDE vulnerabilities are particularly concerning because they target developer workstations. An attacker-controlled website can modify the local MCP configuration file without user approval in Windsurf. Cursor, Claude Code, and Gemini-CLI require user interaction, but the UI may not make the execution consequences clear.

Did my vendor patch?

Some vendors have patched, some partially, and others have not confirmed. The table below outlines each affected product, the exploitation type, patch status, and remaining gaps. Notably, the “Protocol fix?” column remains “NO” for all.

Does the flaw survive the patch?

Yes. Each product-level patch addresses specific entry points but does not alter the MCP protocol’s STDIO behavior. A security director who patches LiteLLM today and configures a new MCP STDIO server tomorrow will face the same insecure default. While necessary, these patches are insufficient.

This was expected. When VentureBeat reported on MCP’s security issues in January, Merritt Baer, chief security officer at Enkrypt AI, noted: “MCP is shipping with the same mistake we’ve seen in every major protocol rollout: insecure defaults. If we don’t build authentication and least privilege in from day one, we’ll be cleaning up breaches for the next decade.” The Cloud Security Alliance confirmed OX’s findings, recommending that organizations consider MCP-connected infrastructure as an active threat. The defaults remain unchanged, expanding the attack surface.

Rees argued that Anthropic’s stance, while internally consistent, does not align with enterprise realities. “It stops being a developer mistake and starts being a distributed failure mode when the same class of failure reproduces across that many independent implementations,” Rees told VentureBeat. “Guidance is not an architectural control. Relying on thousands of downstream implementers to consistently interpret a trust boundary is a known anti-pattern in enterprise security.”

Anthropic updated its SECURITY.md file nine days after OX’s initial contact in January 2026, advising caution with STDIO adapters, but made no structural changes. Researchers assessed that this update did not resolve the issue.

Rees offered a balanced view, acknowledging Anthropic’s update to their security guidance as a step forward, though not a comprehensive fix.

What changed at the protocol level?

Nothing at an architectural level. Anthropic has not implemented manifest-only execution, a command allowlist in the official SDKs, or other protocol-level mitigations recommended by OX. The only change was the SECURITY.md guidance update. OX’s research, starting in November 2025, involved over 30 responsible disclosure processes across the ecosystem before publication on April 15.

The disagreement is substantial. Anthropic’s architectural rationale merits consideration. STDIO is intended as a local subprocess transport to run processes on the configuring machine. In Anthropic’s perspective, trust lies with the configuration file’s controller. Thus, perceived command injection is an intended feature. Restricting STDIO at the protocol level could disrupt its function or shift the attack surface to the launched process. The argument for an unopinionated standard is also valid: a universal protocol with built-in execution constraints loses its universality. OX counters that shifting responsibility to implementers does not mitigate risk but obscures its origin.

Do not await a protocol-level fix. Treat every MCP STDIO configuration as an untrusted input surface, regardless of the product it is integrated into.

Monday morning remediation sequence

Enumerate. Identify every MCP server deployment across development, staging, and production environments. Look for MCP configuration files (mcp.json, mcp_config.json) in developer directories and IDE config paths like ~/.cursor/, ~/.codeium/windsurf/, ~/.config/claude-code/. List processes matching MCP server binaries and flag those using STDIO transport with public IP access. OX found 7,000 on public IPs, suggesting unknown instances in your environment.

Patch. Secure all affected products to their patched versions. LiteLLM v1.83.7-stable offers a fix for CVE-2026-30623. DocsGPT, Flowise, and Bisheng have released fixes, while Windsurf and Langchain-Chatchat remain in reported states as of May 1, 2026. Cursor was patched for an earlier related issue (CVE-2025-54136) but retains the original protocol default. Verify each vendor’s advisory on the day of action.

Sandbox. Isolate all MCP-enabled services from the host OS. Avoid granting servers full disk access or shell execution privileges. The Flowise/Upsonic allowlist bypass demonstrates the inadequacy of restricting commands alone.

Audit registries. Review every MCP server sourced from third-party registries. Nine of 11 registries accepted OX’s proof-of-concept without a security check. Use registries with a documented review process. Remove any MCP server of uncertain origin.

Treat STDIO config as untrusted. This approach remains essential beyond future patches and products. The default has not changed. Every STDIO server definition is a command execution surface. Treat it like user input to a database query: assume hostility until validated.

Your exposure cannot wait for a protocol fix

Anthropic and OX Security dispute who should ensure MCP’s STDIO transport security. This debate won’t resolve soon. However, you can determine if your MCP deployments are inventoried, patched, sandboxed, and handled as the untrusted execution surfaces they are.

As Rees stated: “The core question here is architectural policy, not exploit payloads.” Baer warned earlier this year that insecure defaults would lead to this situation. OX identified 200,000 servers with a configuration field doubling as an execution surface. The protocol’s designer insists it functions as intended. Your immediate concern is not who is correct but which of your servers are vulnerable.