AI agent building tools enable users to configure Model Context Protocol (MCP) servers may be exposing systems to remote code execution due to an architectural decision in Anthropic’s reference implementation.

At issue are unsafe defaults in how MCP configuration works over the STDIO interface, with broad implications for the agent ecosystem, according to a new report.

“The blast radius is massive,” researchers from application security firm OX Security wrote in their report on the design issue. “This exploit allowed us to directly execute commands on six official services of real companies with real paying customers, and to take over thousands of public servers spanning over 200 popular open-source GitHub projects with hundreds of millions of downloads.”

According to Anthropic and other MCP adapter developers, the STDIO command execution behavior is by design and the responsibility of sanitizing MCP configurations falls with developers of client applications. While this might be true, in practice OX Security found that few developers have attempted to filter commands in MCP configs and even those who did failed to catch all potential bypasses.

The root of the issue

MCP provides a standardized method for applications to expose data sources and tools to LLMs, improving their context and effectiveness in completing automated workflows. Originally developed by Anthropic, MCP has become a widely adopted technology in the agentic AI space.

Anthropic provides reference MCP implementations in the form of SDKs for a variety of programming languages, including TypeScript, Python, Java, Kotlin, C#, Go, PHP, Ruby, Rust, and Swift. Furthermore, other frameworks and functionality providers — such as FastMCP, LangChain’s mcp-adapters, Microsoft’s agent-framework, mcp-agent, browser-use, Amazon’s run-model-context-protocol-servers-with-aws-lambda, and NVIDIA’s NeMo-Agent-Toolkit — have Anthropic’s modelcontextprotocol reference implementation as a dependency.

MCP supports two transport interfaces between servers and clients: Streamable HTTP with Server-Sent Events (SSE), which is typically used for remote MCP servers and web services, and Standard Input/Output (STDIO), for MCP servers and applications that run locally on the same machine.

With STDIO, client applications can start MCP servers on demand as a subprocess and pass parameters to them. These parameters can include custom commands that get executed on the system with the permissions of the parent process. While in theory these commands are meant to tell the SDK’s StdioServerParameters function how to start the MCP server, they can technically be anything if no filtering is in place.

The OX Security researchers consider this a design flaw that should be mitigated, but Anthropic disagrees, as do the creators of other frameworks that enable MCP functionality, such as LangChain and FastMCP. The argument is that the responsibility for making sure malicious user input doesn’t reach the SDK’s command execution function resides with the developers of the client applications that integrate these MCP frameworks.

“The pattern of allowing user-supplied strings to flow directly into a shell execution environment is an anti-pattern that should be deprecated,” the OX Security researchers said. Anthropic’s SDKs should implement a command allowlist by default that blocks sh, bash, powershell, curl, rm, and other high-risk binaries, they added.

The core issue is that there’s currently no check in place to verify that a STDIO command is intended to initialize an MCP server rather than perform a malicious task. Furthermore, the researchers observed that even if the sent command fails to start the server, the SDK returns an error after the command has already been executed.

All modern IDEs such as VS Code, Cursor, and Windsurf, as well as agentic coding CLIs like Claude Code, OpenAI Codex, and Gemini CLI, have built-in support for local MCP servers over STDIO. But so do countless other agentic AI frameworks and open-source tools and few of them implement STDIO command allow lists.

RCE in real-world applications

The OX Security researchers have spent the past few months testing MCP support in numerous tools, including live production services. They found and reported more than 30 RCE issues stemming from this STDIO design decision to multiple projects and 10 have received CVE IDs so far.

Depending on how a tool implements MCP support and how it accepts user input, there are multiple attack vectors that exploit the lack of STDIO command filtering.

For example, some services and tools have not disabled STDIO internally even though their user interfaces only allow configuring MCP servers with Streamable HTTP. This was the case for Letta AI and DocsGPT, two platforms that enable companies to create AI agents via both cloud services and local deployments.

“An attacker crafting a network request for an MCP server configuration, and changing the transport type in the configured JSON to contain an STDIO type instead of SSE or HTTP, also adding an arbitrary command to the request’s payload, can achieve remote command execution,” the researchers said.

Another attack vector is prompt injection leading to malicious MCP configurations. While all IDEs are technically vulnerable to this — websites may contain hidden instructions for LLM agents to modify local files — most IDEs prompt users before making modifications to MCP configuration files. The exception was Windsurf, which directly modified the MCP config by default, resulting in a zero-interaction command injection attack.

Many other tools don’t apply filtering to MCP STDIO parameters, meaning any user with access to configure an MCP server gains code execution on the underlying server, including production servers in the case of SaaS deployments. Tools found vulnerable to this include LangFlow, GPT Researcher, LiteLLM, Agent Zero, LangBot, Fay Digital Human Framework, Bisheng, Jaaz, Langchain-Chatchat, and several others the researchers are not yet able to disclose.

Some developers were aware of the issue and did attempt to harden their implementations with command whitelisting. However, the hardening was insufficient, and the OX Security researchers found simple bypasses.

For example, Upsonic, an open-source framework for building AI agents, implements an allowlist that includes npx, which supports -c (—call), a flag that allows custom commands and shell scripts to be passed for npx to execute. The same bypass was observed in Flowise, another UI-based AI agent building framework that also restricts MCP configuration commands but allows npx.

Anthropic (modelcontextprotocol), LangChain (langchain-mcp-adapters), FastMCP, the browser-use project, AWS (run-model-context-protocol-servers-with-aws-lambda), NVIDIA (NeMo-Agent-Toolkit), OpenHands, PromptFoo, Firebase Studio, Gemini CLI, Claude Code, GitHub Copilot, and Cursor technically include the MCP STDIO code that allows for arbitrary command execution.

Their maitainers consider the command execution intended behavior or have declined to fix it because it is mitigated by other controls such as modifications requiring user interaction or the command execution happening inside sandboxed environments like Docker containers.

See also: