MCP Security Flaws: Anthropic's Git Server Joins OpenAI Worries

A vulnerability in Anthropic's own MCP server

When OpenAI added Model Context Protocol (MCP) support to ChatGPT's developer mode, security concerns focused on OpenAI's implementation. A newer disclosure shows the risk is broader than one vendor. Researchers have found that Anthropic, which created MCP, shipped vulnerable code in one of its own official reference servers.

Cybersecurity firm Cyata identified three vulnerabilities in mcp-server-git, the official Git server for MCP 2. The flaws affect every version released before December 8, 2025, and they work against default installations 2. Exploitation does not require credentials or system access. An attacker only needs to control something the AI assistant reads, such as a malicious README, a poisoned issue description, or a compromised webpage 2.

The impact is serious. When mcp-server-git runs alongside a filesystem MCP server, the flaws can lead to code execution. They can also allow deletion of arbitrary files and loading of arbitrary files into a model's context window 2. The bugs do not directly exfiltrate data. However, once sensitive files have been pulled into an AI's context, they can create further exposure 2.

The OpenAI debate looks different now

Earlier criticism of MCP centered on ChatGPT. When OpenAI introduced MCP support in developer mode, some coverage presented it as a win for developer tooling. Security researchers warned that malicious or compromised MCP servers could use prompt injection to exfiltrate enterprise data 4. OpenAI's own documentation acknowledges that trusting an MCP developer does not make a connection safe 4.

Practitioners online were blunt. Hacker News commenters called the feature dangerous and said most users don't understand prompt injection risk. One Reddit user declared that MCP is not enterprise-ready 4. Those reactions cut against OpenAI's DevDay message that ChatGPT is a mature enterprise app platform 4.

The Cyata findings change the picture. Anthropic designed the protocol and published mcp-server-git as a reference implementation, the code other developers are likely to treat as a model to follow. If that server was exploitable in its default setup, the problem is not one company's rushed rollout. It points to something structural about how MCP-connected agents handle untrusted input.

Academic research says the problem is in the design

Two recent papers support the view that the risk is systemic.

The first, by Narek Maloyan and Dmitry Namiot, describes itself as the first formal security analysis of the MCP specification 3. It identifies three weaknesses at the protocol level:

• No capability attestation. Servers can claim arbitrary permissions.
• Unauthenticated bidirectional sampling. Requests flow in both directions without origin authentication, which opens a path for server-side prompt injection.
• Implicit trust propagation. In setups with multiple servers, trust passes between them without explicit checks 3.

The authors also built MCPBench, a framework that connects existing agent security benchmarks to MCP-compliant infrastructure, so protocol-specific attacks can be measured directly 3.

The third weakness maps closely onto the Cyata findings. The worst outcome, code execution, appeared only when the Git server was combined with a filesystem server 2. That is the kind of cross-server trust chain the paper warns about.

The second paper applied the STRIDE and DREAD threat-modeling frameworks to five MCP components: the host and client, the LLM, the MCP server, external data stores, and the authorization server 1. It found tool poisoning to be the most common and damaging client-side vulnerability. Tool poisoning means hiding malicious instructions inside a tool's metadata. The researchers tested how seven major MCP clients defend against this attack and found significant weaknesses in most of them. They attributed the failures to weak static validation and poor visibility into tool parameters 1.

What it means for developers

The sources differ in focus. One is a vendor disclosure about specific bugs 2. One is a critique of an enterprise product 4. Two are academic analyses of architecture and client behavior 13. All four reach the same conclusion: MCP's convenience depends on trusting tool descriptions, server responses, and fetched content that language models cannot reliably separate from instructions.

The most reasonable reading is that MCP risk belongs to the whole ecosystem, not to any one vendor. Patching mcp-server-git was necessary, but it does not fix the underlying issue, which is that agents act on whatever text they read. The defenses researchers propose include:

• static analysis of tool metadata
• tracking how the model reaches its decisions
• detection of anomalous behavior
• greater transparency for users about what tools are doing 1

These measures point toward layered safeguards rather than a single fix. Until protocol-level changes such as capability attestation are adopted, teams running MCP servers, especially several at once, should treat every connected tool and every document an agent reads as potentially hostile input.