The ecosystem that's grown up around the Model Context Protocol (MCP) AI connectivity standard is a poorly governed mess, with fundamental security flaws and sloppy governance issues that are not being fixed, a security researcher said in a presentation at the OWASP Global AppSec conference in San Francisco Nov. 5.
One issue is an unresolved vulnerability in the way MCP handles commands among MCP clients and servers on the same machine, explained Moshe Siman Tov Bustan, Security Research Team Leader at OX Security.
"A year ago, we found a new attack surface that almost nobody knew about," said Bustan, referring to the flaw. "You could swap in a malicious command without anyone noticing."
Another weakness is that there's no system to validate remote MCP servers, which can be run from anywhere, including from hostile countries or home proxy networks. A related one is that many MCP configuration marketplaces don't verify the security of what they distribute.
Tighter controls could fix these problems, said Bustan, but neither MCP creator Anthropic nor many of the entities distributing MCP configurations, skills and tools seem interested.
Ideally, he said, every user of the MCP standard should be aware of these flaws and mitigate against them. But with millions of "vibe coders" throwing together applications quickly, Bustan worries the inherent MCP flaws may be creating problems that will never be tamed.
"Developers are not security engineers," Bustan and his colleagues wrote in a white paper. "We cannot expect tens of thousands of implementers to independently discover and mitigate a flaw that is baked into the official SDKs [software development kits] they trust."
The universal connector
"MCP is everywhere," said Bustan. "Every AI agent you use now is going to connect to an MCP server. And it's naturally going to attract hackers."
The official MCP software development kit has been downloaded 150 million times, Bustan said. There are 100,000 MCP server configurations in online marketplaces. And, he added, MCP isn't just one project — instead, it's hundreds of specialized projects.
This is quite a triumph for a standard first released just two years ago. Anthropic made MCP free and public from the start, and even rivals like OpenAI and Microsoft soon adopted it to connect their LLMs and AI agents to other applications and resources.
The flexibility, openness and simplicity of MCP are key to its success. But that's led to some well-documented security flaws, such as "tool poisoning" resulting from a lack of verification of MCP tool manifests, remote code execution from malicious servers, and authentication flaws in MCP developer tools.
As the head of engineering and AI at 1Password said about MCP told SC World earlier this year, "it's the absence of security primitives in the protocol itself. There's no built-in identity, no least-privilege enforcement, no audit trail."
A deep-rooted problem
Some of the more well-publicized flaws have been fixed or mitigated. But Anthropic has chosen not to fix the major flaw that Bustan's team found in late 2025 and disclosed in April 2026. OX Security calls it "the mother of all AI supply chains."
MCP clients can connect to MCP servers in one of two ways. When the server is remote, they use HTTP or HTTPS, standard web protocols. When the client and server are on the same machine or the same local network, they use the standard input/output, or STDIO, protocol. So far, so good.
But Bustan's team stumbled across something scary: They found that they could paste any command, including one that had nothing to do with MCP, in a local MCP interface to create a new local STDIO MCP server.
A non-MCP command would not create a new server, and the interface would return an error message, but the command would execute anyway.
"When a command is received to start a process, there's no validation that that command is allowing an arbitrary command to be executed instead of a command that explicitly starts an MCP STDIO server," notes the OX Security white paper on the topic.
In other words, a malicious skill or tool imported from an online repository could, if run locally on a user's machine, could do pretty much anything within the limits of the logged-in user's permissions.
The team created a proof-of-concept MCP server configuration that included an arbitrary command that harmlessly exploits this flaw. They submitted it to 11 MPC marketplaces. Nine accepted it, another put the acceptance on hold, and only one rejected it.
"GitHub's managed environment was the only outlier, proving that security gating is possible," added the white paper.
As the OX security team wrote in a blog post, "this flaw enables Arbitrary Command Execution (RCE) on any system running a vulnerable MCP implementation, granting attackers direct access to sensitive user data, internal databases, API keys, and chat histories."
During his presentation, Bustan demonstrated how this flaw could be used to exploit third-party software, including an AI development platform, a software-development environment and a research automation framework owned by IBM. The OX team were able to achieve remote code execution on all three.
Trust us, this is a feature, not a bug
The OX team discovered this flaw in November 2025 and notified Anthropic of it in January 2026. Anthropic replied that this was expected behavior in accordance with the way MCP was designed and that there would be no mitigation. Several of the vendors in whose software OX found related issues responded the same way.
However, Bustan said, Anthropic quietly updated its security policy to state that users are responsible for securing MCP instances using STDIO.
No CVE (Common Vulnerability and Exposure) vulnerability listing was issued by the MITRE Corporation for the underlying flaw, but at least 10 associated CVEs have been created on other pieces of software that use MCP locally, says OX Security. Not all have been patched or mitigated.
To mitigate against this issue in your own instances of MCP, OX security recommends running all MCP services in a sandbox, using only MCP tools and skills that come from official repositories, blocking access to sensitive data, monitoring tool invocations and treating all external MCP configuration input as untrusted.
"If the vendors aren't going to take responsibility," said Bustan, "then you'll have to take responsibility as a user."
New MCP server, who dis?
In another bit of research, the OX Security team analyzed more than 15,000 internet-connected MCP servers publicly listed in repositories and found 5,095 unique hostnames among them.
Of those 5,095 hostnames, 796 were geographically located outside the U.S., with 19 in China and 18 in Russia. About 0.45% of the hostnames, or roughly 23, were connected via proxy services that rely on tunneling services or home networks. And more than 100 hostnames had been abandoned.
That's not a big deal if you know what you're connecting to -- but unlike the cloud ecosystem, there's nothing in the MCP standard telling you that.
"MCP has no protocol-level concept of geographic region," notes an OX Security blog post on the issue. "An enterprise can enforce strict residency controls on its own cloud workloads while its AI agents connect freely to servers sitting outside those same controls."
In other words, your in-house MCP instances could be reaching out to malicious servers anywhere in the world without you knowing it.
To demonstrate the dangers of this lack of MCP server verification, Bustan said his team found an abandoned hostname referenced in GitHub. They bought the associated internet domain name, installed an MCP server and found they could steal data from connecting servers, depending on which LLM was used.
"MCP marketplaces aren't really reviewing MCP servers," said Bustan. "Their scanners can't see what happens on the backend."
To mitigate the risk of being negatively affected by these loose security practices, Bustan recommended that MCP users map out the MCP servers they're connecting, understand the code they're running, and sandbox as much as possible. (OWASP offers a guide to securely using third-party MCP servers.)
Most importantly, Bustan said, realize that no one else is coming to help you secure your MCP instances.
"Own your own infrastructure," he said. "[Software] maintainers are not your on-call."
