The 'by design' security flaw of Model Context Protocol (MCP)

Security researchers have uncovered a massive architectural flaw in Anthropic's Model Context Protocol, exposing millions of AI applications to remote takeovers.

An architectural vulnerability baked into the core of Anthropic’s Model Context Protocol (MCP) exposes millions of AI applications to remote command execution. Security researchers at OX Security discovered a fundamental flaw in how the protocol handles local process execution, allowing attackers to hijack servers, exfiltrate private data, and infiltrate enterprise networks.

Because the vulnerability exists at the protocol layer, the blast radius is massive. It affects over 150 million downloads, leaves more than 200,000 public servers potentially exposed, and has resulted in over 10 Common Vulnerabilities and Exposures (CVEs). The research team successfully executed commands on six live production platforms with paying customers and bypassed security checks on 9 out of 11 major MCP marketplaces.

The vulnerability mostly remains in the wild as it is a “feature not a bug,” and requires vigilance by developers. But the report highlights the kind of care you need to put into your AI applications as you adopt new technologies.

How expected behavior turns into remote execution

To understand the scope of the threat, you have to understand the role of MCP. Released by Anthropic in November 2024, MCP acts as a universal plug adapter for AI agents. Large language models (LLMs) cannot inherently browse your local files or query a private SQL database. MCP bridges this gap. An MCP adapter translates the LLM’s requests into actions the external service such as a web search engine or a database can understand.

Because MCP sits at the junction between the AI model and external tools, it holds highly privileged access to source code, chat logs, and API keys.

The vulnerability stems from how MCP manages local connections through its Standard Input/Output (STDIO) interface. STDIO is a basic mechanism computers use to pass text between running programs. When you instruct an MCP adapter to start a local server, you pass it a command string. MCP executes this string on the host machine’s operating system to spin up the connection.

How the MCP STDIO vulnerability works (source: Ox Security)

If the command successfully starts an MCP connection, the system proceeds. However, if the command is malicious and fails to establish a valid MCP connection, the system simply returns an error to the user. The critical failure is that the underlying operating system command still runs. There are no sanitization warnings or roadblocks. An attacker can pass a malicious command, receive a connection error, and walk away with full control of the server.

The architecture makes it easy to distribute exploits. Developers frequently browse community marketplaces to download custom MCP configurations. OX Security uploaded a harmless proof-of-concept payload to 11 directories. Nine of them, including popular hubs like LobeHub and Cursor Directory, published the payload without any security review (GitHub was the only one that rejected the submission, and Cline did not respond). A single malicious listing could grant an attacker hidden access to thousands of developer machines.

Code repositories vulnerable to MCP attack (source: Ox Security)

In practice, this flaw manifests differently depending on the application environment.

LangFlow, an open-source framework owned by IBM, allows users to build AI workflows through a web interface. Researchers found over 915 publicly accessible LangFlow instances online. The platform exposes its MCP configuration panel without requiring authentication. Anyone on the internet can request a session token, send a crafted network request containing a malicious STDIO command, and take over the underlying server without ever logging in.

The threat also extends to local development environments through prompt injection. AI-powered Integrated Development Environments (IDEs) like Windsurf and Cursor read local files and browse the web to assist developers. If a developer visits an attacker-controlled website, the site can feed a hidden, malicious instruction to the AI assistant. The AI then proposes an edit to the local mcp.json file to include a dangerous STDIO command. In the case of Windsurf, the system applied the edit and executed the command immediately, requiring zero clicks or approvals from the developer.

MCP vulnerability in LangFlow (source: Ox Security)

The balance between flexibility and security

When OX Security reported these findings, the response from protocol maintainers and IDE vendors was uniform. Anthropic, LangChain, and Microsoft all stated that the behavior is expected and operates by design.

The core of their argument is flexibility. To maintain MCP as an unopinionated, universal standard, the protocol avoids putting strict limitations on what developers can execute. LangChain maintains that application authors are responsible for validating and sanitizing inputs. IDE vendors argue that users must actively trust their workspace environments.

This approach creates a structural failure. It shifts the burden of complex security sanitization onto tens of thousands of downstream developers building chat apps and internal tools. Many of these developers are not security engineers, guaranteeing that vulnerabilities will emerge at scale.

Moshe Siman Tov Bustan, security research team lead at OX Security, argues that safety does not require sacrificing functionality.

“The protocol can be redesigned in a way that doesn’t lose its utility,” Bustan told TechTalks. “By letting developers choose the available functionality, it could block arbitrary commands by default, but let developers enable them by passing a flag that clearly states the function enables arbitrary command execution and should not be exposed to user input.”

Securing the AI stack

Until the foundational protocols are hardened, engineering teams need to adopt strict architectural controls to protect their environments from MCP-based exploits.

Implement manifest-only execution: The pattern of passing raw, user-supplied strings directly into a shell execution environment must stop. Teams should transition to a manifest model, where applications only execute pre-defined server aliases locked within a static configuration file.

Enforce strict sandboxing: AI agents should operate in low-privilege environments. “If an MCP needs to communicate with a remote server, it should be allowed to contact only that specific server. The same applies to filesystem access and any other behavior,” advises Bustan.

Require explicit opt-ins: Developers should introduce a mandatory flag whenever dynamic STDIO arguments are active. This makes dangerous modes easily searchable for security linters and audit teams.

Adopt least-privilege secret management: API keys and OAuth tokens provided to MCP servers must be strictly scoped to their intended function. The presence of broad, full-permission keys should trigger automated warnings during the deployment process.

Establish marketplace verification: Registries need to mature beyond open uploads. Marketplaces should require developers to submit a standardized security manifest detailing exactly which network resources and file systems an MCP server will access before allowing users to download it.

Navigating the “Army of Juniors”

The vulnerabilities within MCP highlight a broader shift in how software is built today. The widespread use of AI coding assistants and vibe-coding tools allows individuals with limited security maturity to generate and deploy functional code at an unprecedented speed.

OX Security refers to this dynamic as the “Army of Juniors” effect. AI systems are highly effective at writing integration logic, but they rarely question the architectural safety of the underlying protocols they use.

“We consider this cascading vulnerability to align with this AI coding anti-pattern, because AI services are often written by AI-native developers,” Bustan said. “If the AI doesn’t question the underlying implementation, the developer behind the AI won’t either.”

This dynamic makes foundational security critical. Protocol maintainers must embed “secure by design” principles directly into SDKs and package dependencies, rather than shifting the burden of sanitizing inputs downstream. As autonomous systems gain more access to sensitive data and critical infrastructure, relying on traditional tools or even other AI systems to catch anomalies is no longer enough.

“While code is rapidly evolving and being written at scale, security expertise and manual reviews are now needed more than ever,” Bustan said. “Our analysis shows that we cannot blindly trust automated AI reviews to check code security. Especially in areas where the code handles sensitive information, human manual reviews can identify architectural flaws that are often introduced by AI agents.”