Anthropic's MCP SDKs Let Any Process Execute Code, and That's Not a Bug
On April 20, 2026, OX Security disclosed that Anthropic's official Model Context Protocol SDKs, the Python, TypeScript, Java, and Rust libraries that developers use to build MCP servers and clients, let any process pass a command straight to the STDIO interface and have it execute on the host. There is no sandbox step in between. OX Security's researchers reported the finding to Anthropic and got a clear answer back: this is how the SDK is designed to work, not a defect that needs patching.
The scale of the exposure
OX Security estimates roughly 200,000 vulnerable instances running across a supply chain built on top of these SDKs, which have been pulled down more than 150 million times combined. That number covers every project that imported the SDK without adding its own execution controls on top, which turns out to be most of them, because the SDK itself does not require you to.
The behavior has already been weaponized. Security researchers tracking exploitation documented an authenticated remote code execution path against Letta AI's agent memory platform, and a fully unauthenticated takeover of LangFlow, an open-source tool for building LLM workflows. Neither required a novel technique. Both used the STDIO command-execution path exactly as the SDK exposes it.
Why Anthropic isn't changing it
Anthropic's position, according to Authzed's timeline of MCP-related breaches, is that command execution over STDIO is a deliberate architectural choice, not an oversight up for reconsideration. MCP servers are meant to run local tools and scripts on a user's machine, and STDIO is the transport that makes that possible. Closing the hole at the SDK level would mean redesigning what MCP servers are for.
That leaves the responsibility for access control sitting entirely with whoever builds on top of the SDK. Most developers reaching for an MCP SDK are trying to wire an agent up to a tool quickly, not thinking about what happens if an untrusted process gets to supply the command string. CSA Labs' write-up on the disclosure treats this as the core problem: a security-relevant default that requires every downstream developer to independently understand and mitigate it, spread across 150 million-plus downloads.
What to check if you're running an MCP server
- Does anything untrusted, including a remote agent's output, ever get passed into the command string your MCP server executes over STDIO?
- Is your MCP server process running with more filesystem or network access than the specific tool integration needs?
- Have you checked whether the version of the SDK you're on matches the one in the disclosures for Letta AI and LangFlow, and whether either project's own patches apply to your setup?
Because Anthropic has confirmed this is intentional, there's no SDK update coming that closes it. The fix, for now, lives entirely on the application side: treat command input to any MCP server as if it were arbitrary shell access, because for practical purposes it is.