MCP Tool Poisoning: The SDK Design Flaw Anthropic Won't Fix

OX Security's research team (Moshe Siman Tov Bustan, Mustafa Naamnih, Nir Zadok, and Roni Bar) spent roughly five months examining how MCP's STDIO transport, the default mechanism an AI agent uses to launch and talk to a local tool process, handles the commands it is given. Their finding, published April 16, 2026 under the title "The Mother of All AI Supply Chains," was that the official MCP SDK lets a connecting client run any arbitrary OS command. If that command successfully starts an STDIO server, the SDK returns a working handle. If it does not, the SDK still executes the command before returning an error. In practice, that means a malicious or manipulated configuration value, something as simple as a poisoned tool description, a compromised marketplace listing, or a hijacked config file, can trigger real command execution on the host, not just influence what the model reads.

The researchers were explicit that this is not a coding mistake anyone patched over five months of disclosure. It is architecture: unsanitized command execution is the documented, intended path, and it sits underneath every project that inherited the reference SDK rather than writing its own transport layer from scratch.

Most MCP security stories to date have been about a single misconfigured or malicious server: a trivia-game tool that hides exfiltration instructions in its description, or a marketplace listing that swaps a legitimate tool for a hostile one after installation. Those are real, but they are contained. Fixing them means auditing or removing one bad actor from your environment.

A default baked into the SDK itself is structurally different. Every developer who pulled in the official Python, TypeScript, Java, or Rust MCP package and built a server or client on top of it inherited the same unsanitized command path, whether they knew it or not. That is what turned an individual finding into a supply chain story: the vulnerability does not live in one product's code, it lives upstream in the dependency graph that hundreds of thousands of downstream projects trusted by default. CSA Labs framed this as a systemic design flaw in AI agent infrastructure rather than a conventional CVE-and-patch event, precisely because there is no single patch that closes it across the ecosystem.

OX Security's estimates, corroborated across multiple outlets covering the disclosure, put the exposure at:

The flaw was confirmed in the official MCP SDK implementations for Python, TypeScript, Java, and Rust, meaning it is not limited to one language ecosystem or one vendor's packaging of MCP. OX Security's disclosure led to more than ten individual CVEs being issued against downstream tools and platforms that inherited the behavior, including CVE-2025-65720 (GPT Researcher), CVE-2026-30625 (Upsonic), CVE-2026-30615 (Windsurf), and a GitHub Security Advisory for Flowise, with additional CVEs affecting LangFlow, LiteLLM, and Langchain-Chatchat. Separately, CVE-2026-33032, a CVSS 9.8 flaw in nginx-ui's MCP integration where the message endpoint failed to authenticate command execution requests at all, illustrates how the same class of unsanitized-input problem shows up again once developers build their own integrations on top of the SDK.

AI-assisted development environments and IDEs that support MCP, including Cursor, VS Code, Claude Code, Gemini CLI, GitHub Copilot, and Windsurf, were all named as clients that can be exposed when they connect to a vulnerable or malicious MCP server, since the exploit path runs through the transport layer those clients rely on, not through any one vendor's application code.

Anthropic's response, as reported by OX Security and independently confirmed in coverage of the disclosure, was to decline modifying the protocol's architecture. The company characterized the unsanitized STDIO command execution as a "secure default" and "expected" behavior, and told researchers that sanitizing untrusted input is the responsibility of the developers building on top of the SDK, not something the protocol itself should enforce. Anthropic did publish updated security guidance following the disclosure, but that guidance does not change the SDK's default behavior; it shifts the burden to every downstream implementer to add sanitization the reference implementation does not provide.

CSA Labs, in its research note on the broader MCP security crisis, mapped this design default into its MAESTRO threat modeling framework for agentic AI systems, treating it alongside tool interface abuse (the category that includes classic tool poisoning) as part of a single systemic risk picture rather than isolated incidents. No CISA advisory specific to this MCP SDK default has been published; the CVEs issued to date target individual downstream products rather than the protocol default itself, which is consistent with Anthropic's position that the underlying behavior is not going to change.

This SDK-level default does not replace classic tool poisoning, it compounds it. Tool poisoning works because MCP tool descriptions are natural-language metadata that a model reads to decide what a tool does, and that metadata is rarely surfaced to the human operator at runtime, a gap our earlier post on MCP security risks covers in depth. What the OX Security disclosure adds is a second layer underneath that gap: if an attacker can get a poisoned description or a manipulated configuration value in front of the SDK's STDIO handler, the unsanitized command path means the resulting action is not limited to what the model chooses to do, it can extend to arbitrary command execution on the host running the agent.

Separately, the MCPTox benchmark, which tested 45 live MCP servers and 353 authentic tools against major LLM agents, found attack success rates exceeding 60% overall and as high as 72% on the weakest configurations, with even the most resistant model tested, Claude-3.7-Sonnet, refusing poisoned tool calls in fewer than 3% of cases when the poisoning was well constructed. That data point is about model behavior in the face of a poisoned tool description, a distinct mechanism from the STDIO command execution default, but the two problems sit in the same threat surface: a poisoned tool description gets the agent to act, and an unsanitized transport layer determines how far that action can reach. Teams evaluating MCP server security should be reading both stories together, and our post on MCP server security scanners covers tooling that targets the description-poisoning side specifically.

There is no single scan that confirms you are clear of this issue, because the flaw is a default rather than a discrete signature, but a few concrete checks will tell you how exposed you are today.

Since Anthropic has stated it will not change the SDK default, mitigation is entirely on the implementer side for now. The practical steps that map directly to this disclosure:

Anthropic's public position, that unsanitized STDIO command execution is a secure default and sanitization is a developer responsibility, has not moved since the April disclosure, and there is no indication in the record that a protocol-level fix is planned. That means the realistic trajectory is more individual CVEs against downstream tools that inherited the default, similar to the ten-plus already issued, rather than a single upstream patch that closes the issue for everyone at once. Expect continued growth in third-party MCP security tooling, scanners, gateways, and session-isolation products that sit between agents and MCP servers to enforce the sanitization the SDK does not, since that is the gap the market is already moving to fill. Expect CSA Labs and similar research bodies to keep publishing under threat-modeling frameworks like MAESTRO rather than waiting on a CISA advisory specific to this default, since the issue does not fit the single-product-single-patch model those advisories are built around. For security teams, the practical read is that this is not a wait-for-the-patch situation. The default is not changing, so the controls listed above are the actual fix available today.