TLDR: A new research paper by Xiaofan Li and Xing Gao reveals significant security vulnerabilities across the Model Context Protocol (MCP) ecosystem, which enables AI applications to interact with external tools. The study identifies weaknesses in MCP hosts (AI applications), MCP servers (tool providers), and MCP registries (server repositories). Key issues include hosts blindly executing LLM outputs without verification, leading to ‘tool confusion’ and ‘context dangling tool’ problems. Servers are vulnerable to ‘tool poisoning’ and ‘tool shadowing’ attacks through manipulated metadata. Registries lack vetting, resulting in invalid server information, credential leaks, and hijacking opportunities like ‘maintainer hijacking,’ ‘redirection hijacking,’ and ‘affix-squatting.’ The paper proposes defense strategies for all components and highlights the urgent need for better security practices in this rapidly growing AI landscape.
The world of AI-powered applications is rapidly expanding, with large language models (LLMs) now interacting with external tools to perform complex tasks like sending emails or editing files. This interaction is often facilitated by an emerging open standard called the Model Context Protocol (MCP), introduced by Anthropic. Major tech companies like OpenAI, Google, and Microsoft have already integrated MCP into their platforms, highlighting its potential as a universal standard for connecting AI systems with external tools. This widespread adoption has led to a burgeoning MCP ecosystem, comprising MCP hosts (applications that integrate LLMs), MCP registries (platforms for sharing servers), and thousands of community-contributed MCP servers (lightweight programs providing specific functionalities).
However, with this rapid growth comes new security challenges. A recent comprehensive security analysis, detailed in the paper “Toward Understanding Security Issues in the Model Context Protocol Ecosystem” by Xiaofan Li and Xing Gao from the University of Delaware, sheds light on the architectural vulnerabilities and associated security risks within this ecosystem. The study systematically breaks down the MCP ecosystem into its three core components – hosts, registries, and servers – and examines the interactions and trust relationships among them.
Vulnerabilities in MCP Hosts
The research reveals that MCP hosts, which are the LLM-integrated applications, often lack crucial output verification mechanisms. When an LLM generates an output, such as an instruction to invoke an external tool, the host blindly executes it without validation. This blind trust can lead to significant security threats. For instance, if two different MCP servers offer tools with the same name, a phenomenon the researchers call “tool confusion,” the host might mistakenly invoke a tool from an unintended server, potentially leading to incorrect or malicious operations. The Cursor host, for example, was found to consistently invoke the first-listed tool regardless of the LLM’s actual selection, making it vulnerable to this issue.
Another vulnerability identified is the “context dangling tool” issue. This occurs when a server or its tools are removed, but the LLM’s context history still references these now-unavailable tools. Without verification, the host might attempt to invoke a non-existent tool, leading to failed or unintended operations. The study found that none of the surveyed hosts (Cursor, Windsurf, Claude Desktop, and Cline) fully implement a mechanism to ensure tool availability before invocation, with Cline exhibiting the worst behavior in this regard.
Security Risks in MCP Servers
MCP servers provide the actual functionalities that LLMs can invoke. The metadata associated with these tools, such as their descriptions, is retrieved by the host. The study highlights that existing MCP designs treat this metadata as trustworthy and static, which is a problematic assumption. This lack of authenticity, integrity, or immutability enforcement opens the door for attackers to manipulate server metadata.
One significant threat is the “tool poisoning attack.” Attackers can embed harmful instructions into a tool’s description or craft deceptive error messages. When the LLM processes this manipulated information, it might be prompted to generate additional, abnormal operations, such as extracting sensitive user data, executing harmful commands, or abusing other server-provided tools. If the host’s “auto-run” mode is enabled, these malicious actions can proceed without any user awareness. The research found that models like Claude Sonnet 4 and Gemini 2.5 Pro were particularly susceptible to these attacks, often following malicious instructions even when identifying them as abnormal.
A more subtle attack is the “tool shadowing attack.” Here, an attacker manipulates the description of their own tool to indirectly influence the LLM’s interpretation of parameters for a benign, legitimate tool. For example, an attacker could craft a description that causes the LLM to replace an intended email recipient with an attacker-controlled address when a user tries to send an email. Most hosts, by default, collapse invocation results, meaning users might not notice that an email was sent to the wrong address, making this attack particularly stealthy.
Challenges in MCP Registries
MCP registries are open platforms where developers can publish and share their servers. The research points out a critical flaw: these registries often lack meaningful vetting mechanisms for submitted servers. This absence of review introduces several risks.
Many servers listed on decentralized registries suffer from “MCP server information missing” issues, including invalid server file links, empty server content, or missing README files, making them unusable or difficult to configure. More alarmingly, the study uncovered instances of “MCP server maintainer credential leakage” on registries like mcp.so, where server owners inadvertently exposed sensitive tokens (e.g., GitHub Personal Access Tokens) in configuration examples. These leaked credentials can be exploited by attackers to hijack servers or abuse the owner’s services.
Inconsistencies between decentralized registries and actual server hosting platforms (like GitHub) also create vulnerabilities. “MCP server maintainer hijacking” can occur when developers delete their GitHub accounts, and attackers reclaim these accounts to recreate previously removed repositories under the same name. Similarly, “MCP server redirection hijacking” exploits GitHub’s account change mechanism. When a developer changes their GitHub username, the old account becomes available for re-registration. If an attacker claims the old username and recreates the repository, the original redirection is terminated, and users accessing the old link are unknowingly directed to the attacker’s malicious server.
Finally, centralized registries like npm are susceptible to “MCP server affix-squatting attacks.” Due to informal naming conventions (e.g., appending “-mcp” or prepending “mcp-server”), attackers can publish malicious servers with names very similar to legitimate ones, but with misleading affixes, tricking users into downloading compromised versions.
Also Read:
- Unmasking a Hidden Threat: How LLM Memory Caches Can Be Corrupted
- Securing Large Language Models: A New Framework for Understanding and Evaluating Prompt Security
Defense Strategies
To mitigate these threats, the researchers propose practical defense strategies for all three components of the MCP ecosystem. For MCP hosts, implementing additional verification mechanisms is crucial. This includes checking for a tool’s existence and integrity before invocation and handling model-generated error messages with caution. MCP registries, especially decentralized ones, should perform periodic validation of server metadata, removing invalid or empty entries and encouraging server owners to sanitize configuration examples to prevent credential leaks. For users, it’s vital to review server configurations, verify server links, check for redirections, and avoid configuring untrusted or suspicious servers.
The findings of this research have been responsibly disclosed to the affected hosts and registries, including Cursor and mcp.so, with the hope that these insights will lead to a more secure and robust MCP ecosystem for the future of AI-powered applications.
