Anthropic Said It's 'Expected Behavior.' Here's the Security Layer That Fixes It Anyway.

Algis Dumbris • 2026/04/20

The Flaw That Isn’t a Bug

Four researchers at OX Security — Moshe Siman Tov Bustan, Mustafa Naamnih, Nir Zadok, and Roni Bar — spent six months methodically breaking MCP’s STDIO transport. Starting in November 2025 and continuing through April 2026, they filed over 30 responsible disclosure reports across the MCP ecosystem. What they found was not subtle: the standard mechanism by which MCP clients launch and communicate with MCP servers allows arbitrary operating system command execution. Any process that can write to the STDIO pipe can inject commands that the host operating system will execute without restriction.

They reported this to Anthropic. Anthropic declined to modify the protocol. The official response classified the behavior as “expected” — STDIO transport does what it is designed to do, which is spawn processes and communicate with them via standard input and output. Anthropic’s updated security guidance now recommends that STDIO adapters “should be used with caution.” The researchers deemed this response ineffective.

That gap between “expected behavior” and “secure behavior” is where the damage happens. Ten CVEs, 200,000 servers at risk, 150 million downloads across affected packages, and nine out of eleven MCP marketplaces accepting poisoned proof-of-concept submissions. Somebody has to provide the security defaults that the protocol specification will not. This post explains why, and what those defaults look like.

How STDIO Transport Becomes a Command Injection Surface

To understand the vulnerability, you need to understand how MCP’s STDIO transport works at the operating system level. When an MCP client — say, an IDE like Cursor or Windsurf — wants to use an MCP server, it spawns that server as a child process. Communication happens over the child process’s standard input and standard output streams. The client writes JSON-RPC messages to stdin. The server reads them, processes them, and writes responses to stdout.

The problem is not the JSON-RPC layer. The problem is the spawn. The STDIO transport requires the client to execute a command on the host operating system to start the server process. That command comes from configuration — an mcp_config.json file, an IDE settings page, a project-level dotfile. Wherever that configuration lives, it contains a shell command that the client will execute.

This is the attack surface. If an attacker can influence the configuration that specifies which command to run, they achieve arbitrary code execution on the host. There is no sandboxing. There is no privilege separation. The spawned process inherits the permissions of the client process, which in the case of a developer’s IDE means full user-level access to the filesystem, network, environment variables, SSH keys, cloud credentials, and anything else the developer’s account can touch.

The OX Security team identified four distinct attack classes that exploit this surface. The first is unauthenticated command injection: MCP servers that accept tool parameters and pass them, unsanitized, to shell commands. The second is command injection that bypasses developer hardening — cases where developers attempted input validation but the injection payload circumvented it. The third is zero-click prompt injection across IDEs, where a malicious MCP server manipulates the LLM’s context to trigger tool calls that execute attacker-controlled commands without any user interaction. The fourth is malicious marketplace poisoning, where attackers publish backdoored MCP servers to public registries and wait for developers to install them.

Each class is a different vector to the same outcome: attacker-controlled commands running with the developer’s full permissions on the host machine.

What “Expected Behavior” Actually Means

Anthropic’s position is not irrational. It is, in a narrow technical sense, correct. STDIO transport spawns a process and talks to it over pipes. Spawning a process means executing a command. Executing a command means the command runs. This is how UNIX process management works. Anthropic did not invent it, and they cannot patch it without replacing STDIO transport entirely — which would break the existing ecosystem of hundreds of MCP servers that depend on it.

The updated security guidance acknowledges the risk. The documentation now explicitly warns that STDIO-based servers carry inherent trust assumptions: the developer must trust the server binary, the configuration source, and the environment in which the server runs. The guidance recommends HTTP-based transports for higher-security deployments and suggests that STDIO adapters should be reserved for local development with trusted servers.

But guidance is not enforcement. The STDIO transport remains the default in every major MCP client. Claude Desktop uses it. Cursor uses it. Windsurf uses it. The MCP Inspector uses it. Every tutorial, quickstart, and getting-started guide in the MCP ecosystem demonstrates STDIO transport as the first — and often only — integration pattern. Developers who follow the official path end up with STDIO servers running on their machines, governed by nothing more than the assumption that the configuration file is trustworthy.

The OX Security team’s verdict was blunt: the security guidance is insufficient to address the systemic risk. When the default behavior is dangerous and the mitigation is a paragraph of documentation, the mitigation does not work. The CVE count proves it.

Ten CVEs and Nine Compromised Marketplaces

The downstream damage materialized exactly as the researchers predicted. Ten high or critical CVEs were assigned across tools built on MCP’s STDIO transport. Windsurf received CVE-2026-30615. GPT Researcher received CVE-2025-65720. Upsonic received CVE-2026-30625. Flowise received GHSA-c9gw-hvqq-f33r. LangFlow, despite being notified in January 2026, received no CVE assignment at all — the disclosure process simply stalled.

The pattern across these CVEs is monotonous in its consistency. A developer builds an MCP server. The server accepts tool parameters from the LLM. Those parameters are passed to a shell command, a subprocess call, or an eval statement. The developer either does not sanitize the input, or sanitizes it in a way that an attacker can bypass. The resulting vulnerability allows remote code execution on the host.

What makes this worse is the marketplace vector. The OX Security team submitted proof-of-concept malicious MCP servers to eleven public MCP marketplaces and registries. Nine of the eleven accepted the submissions without meaningful review. This echoes the ClawHavoc incident from January, where 341 malicious skills infiltrated OpenClaw’s official registry using the same playbook — professional packaging, plausible names, zero review gate. These marketplaces are the npm registries of the MCP ecosystem — the place developers go to find and install servers. When nine out of eleven accept poisoned packages, the supply chain is not compromised in theory. It is compromised in practice, right now.

The scale is not trivial. The researchers estimated 200,000 MCP servers are reachable or installable through public channels, with cumulative download counts exceeding 150 million across affected packages. This is not a niche risk in a niche ecosystem. This is a systemic vulnerability across the primary developer tooling integration protocol of 2026.

The Summit Signal: The Spec Is Catching Up

The AAIF MCP Dev Summit on April 2-3 in New York City provided the first institutional acknowledgment that the protocol’s security posture is insufficient. Twelve hundred attendees. MCP maintainers from Anthropic, AWS, Microsoft, and OpenAI on stage. The language was carefully hedged — “open challenges in security” — but the substance was unambiguous.

Gateway behavior is now a 2026 roadmap priority for the MCP specification. Several vendors demonstrated production gateway implementations during the summit, and the discussion around authentication, admission control, and transport-layer security was no longer theoretical. It was planning.

This is progress. It is also slow. The MCP specification process moves at the pace of multi-stakeholder consensus. SEPs are proposed, debated, revised, and eventually ratified — a process that takes months for non-controversial changes and longer for changes that affect backward compatibility. STDIO transport replacement or hardening is among the most backward-compatibility-breaking changes imaginable. Every existing MCP server, every IDE integration, every developer workflow built on STDIO would need to be updated.

The spec will get there eventually. The question is what happens to the developers running MCP servers today, between the “expected behavior” classification and the day the specification ships enforceable security defaults.

What MCPProxy Does About This Today

MCPProxy exists precisely in that gap. It is the security layer that does not wait for the specification to decide whether arbitrary command execution is a problem worth solving at the protocol level.

Quarantine-by-default. Every MCP server that appears in a developer’s configuration starts in quarantine. It is visible. It is auditable. It is inert. No tools are served to agents. No processes are spawned. Nothing executes until a human operator explicitly reviews the server’s configuration — including the exact command that STDIO transport would execute — and approves it. This is the single most effective mitigation for the marketplace poisoning vector. A developer can install a poisoned MCP server from a compromised marketplace, and it sits in quarantine doing nothing until a human looks at it and decides whether the command it wants to execute is legitimate.

Docker isolation. Approved servers do not run directly on the host. MCPProxy spawns each MCP server inside its own Docker container with minimal privileges, restricted filesystem access, limited network connectivity, and resource constraints. If a server is compromised — through command injection, prompt injection, or any other vector — the attacker is inside a container, not on the host. The developer’s SSH keys, cloud credentials, and filesystem are on the other side of a kernel-enforced boundary. This does not eliminate the risk of exploitation. It contains the blast radius to a disposable, auditable, resource-limited sandbox.

Rate limiting and audit trails. Every tool call that passes through MCPProxy is logged with the calling agent’s identity, the target server, the tool name, and the parameters. Rate limiting prevents an exploited server from making thousands of rapid-fire tool calls to exfiltrate data or probe internal networks. The audit trail provides the forensic record that STDIO transport’s direct process spawning never generates.

BM25 tool selection. MCPProxy does not expose every tool from every approved server to every agent. Its BM25-based tool search matches agent requests to relevant tools, reducing the set of tools visible in any given context. This is an attack surface reduction mechanism. An agent that cannot discover a tool cannot be manipulated into calling it. A prompt injection attack that targets a specific tool fails if that tool is not in the agent’s visible tool set.

None of these mechanisms require changes to the MCP specification. None of them require MCP server authors to rewrite their code. None of them require Anthropic to reclassify “expected behavior” as a vulnerability. They operate at the gateway layer, between the client and the server, enforcing security invariants that the protocol does not.

Security Defaults Should Not Require a Specification Change

The MCP specification will eventually address STDIO transport security. The AAIF summit made that direction clear. Gateway behavior, authentication, and admission control are on the roadmap. When those changes ship, the ecosystem will be measurably safer.

But “eventually” is not a security posture. The OX Security disclosure documented a six-month window between initial findings and public disclosure, during which the attack surface continued to grow. Every day that passes between now and the specification’s security update is another day that 200,000 servers operate without protocol-level protection, another day that nine out of eleven marketplaces accept unreviewed submissions, and another day that “expected behavior” means “your developer machine is one bad config file away from full compromise.”

MCPProxy does not wait for the spec. It ships the security defaults today — quarantine, isolation, audit, and surface reduction — because the alternative is trusting that every developer who uses MCP will independently discover, understand, and mitigate the STDIO transport risk on their own. The CVE count tells you how well that approach works.

The protocol says it is expected behavior. The ten CVEs say it is a systemic vulnerability. MCPProxy treats it as the latter and provides the enforcement layer the protocol will not.

Get started with MCPProxy and put the quarantine layer between your developers and the STDIO attack surface. The spec will catch up. Your security posture should not have to wait.