Paper deep dive
Toward Understanding Security Issues in the Model Context Protocol Ecosystem
Xiaofan Li, Xing Gao
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 97%
Last extracted: 3/12/2026, 6:04:30 PM
Summary
This paper presents a comprehensive security analysis of the Model Context Protocol (MCP) ecosystem, identifying vulnerabilities across its three core components: hosts, registries, and servers. The study reveals that MCP hosts lack output verification, allowing malicious servers to manipulate LLM behavior, while registries suffer from a lack of vetting, enabling server hijacking and impersonation attacks. The authors provide a quantitative analysis of 67,057 servers and propose defense strategies to mitigate these risks.
Entities (6)
Relation Signals (4)
MCP Registry â distributes â MCP Server
confidence 100% ¡ MCP servers can be stored and shared in MCP registries.
MCP Host â manages â MCP Server
confidence 100% ¡ The host serves as the central coordinator to manage execution flows between the LLM and MCP servers.
Attacker â hijacks â MCP Server
confidence 95% ¡ Attackers can hijack benign servers or trick users into downloading malicious ones due to the lack of a vetted server submission process.
MCP Host â lacks â Output Verification
confidence 90% ¡ Our qualitative analysis reveals that hosts lack output verification mechanisms for LLM-generated outputs.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:The Model Context Protocol (MCP) is an emerging open standard that enables AI-powered applications to interact with external tools through structured metadata. A rapidly growing ecosystem has formed around MCP, including a wide range of MCP hosts (i.e., Cursor, Windsurf, Claude Desktop, and Cline), MCP registries (i.e., this http URL, MCP Market, MCP Store, Pulse MCP, Smithery, and npm), and thousands of community-contributed MCP servers. Although the MCP ecosystem is gaining traction, there has been little systematic study of its architecture and associated security risks. In this paper, we present the first comprehensive security analysis of the MCP ecosystem. We decompose MCP ecosystem into three core components: hosts, registries, and servers, and study the interactions and trust relationships among them. Users search for servers on registries and configure them in the host, which translates LLM-generated output into external tool invocations provided by the servers and executes them. Our qualitative analysis reveals that hosts lack output verification mechanisms for LLM-generated outputs, enabling malicious servers to manipulate model behavior and induce a variety of security threats, including but not limited to sensitive data exfiltration. We uncover a wide range of vulnerabilities that enable attackers to hijack servers, due to the lack of a vetted server submission process in registries. To support our analysis, we collect and analyze a dataset of 67,057 servers from six public registries. Our quantitative analysis demonstrates that a substantial number of servers can be hijacked by attackers. Finally, we propose practical defense strategies for MCP hosts, registries, and users. We responsibly disclosed our findings to affected hosts and registries.
Tags
Links
- Source: https://arxiv.org/abs/2510.16558
- Canonical: https://arxiv.org/abs/2510.16558
Trouble viewing inline? Open PDF directly â
Full Text
77,084 characters extracted from source content.
Expand or collapse full text
Toward Understanding Security Issues in the Model Context Protocol Ecosystem Xiaofan Li University of Delaware xiaofanli@udel.edu Xing Gao University of Delaware xgao@udel.edu Abstract The Model Context Protocol (MCP) is an emerging open standard that enables AI-powered applications to interact with external tools through structured metadata. A rapidly grow- ing ecosystem has formed around MCP, including a wide range of MCP hosts (i.e., Cursor, Windsurf, Claude Desk- top, and Cline), MCP registries (i.e., mcp.so, MCP Market, MCP Store, Pulse MCP, Smithery, and npm), and thousands of community-contributed MCP servers. Although the MCP ecosystem is gaining traction, there has been little systematic study of its architecture and associated security risks. In this paper, we present the first comprehensive security analysis of the MCP ecosystem. We decompose MCP ecosystem into three core components: hosts, registries, and servers, and study the interactions and trust relationships among them. Users search for servers on registries and configure them in the host, which translates LLM-generated output into external tool in- vocations provided by the servers and executes them. Our qualitative analysis reveals that hosts lack output verification mechanisms for LLM-generated outputs, enabling malicious servers to manipulate model behavior and induce a variety of security threats, including but not limited to sensitive data exfiltration. We uncover a wide range of vulnerabilities that enable attackers to hijack servers, due to the lack of a vetted server submission process in registries. To support our analy- sis, we collect and analyze a dataset of 67,057 servers from six public registries. Our quantitative analysis demonstrates that a substantial number of servers can be hijacked by at- tackers. Finally, we propose practical defense strategies for MCP hosts, registries, and users. We responsibly disclosed our findings to affected hosts and registries. 1 Introduction Large language models (LLMs) have become a central com- ponent in modern AI-powered applications. To extend their utility beyond language processing, a growing class of appli- cations has emerged where LLMs interact with external tools to perform specialized operations, such as querying APIs, sending emails, or editing files. To support this interaction in a standardized manner, the Model Context Protocol (MCP) has recently been introduced by Anthropic [4] as an open protocol that enables LLMs to discover, describe, and invoke external services via structured metadata. Major AI compa- nies, such as OpenAI [45], have started integrating MCP into their platforms. For example, Google has supported MCP in its Gemini models [44], and Microsoft has integrated MCP across its ecosystem, including GitHub and Azure [32]. This widespread adoption demonstrates MCPâs potential to serve as a universal standard for connecting AI systems with exter- nal tools. As a result, an MCP ecosystem has rapidly formed around this protocol, including diverse MCP hosts (e.g., Cur- sor, Windsurf, Claude Desktop), public MCP registries (e.g., mcp.so, Smithery), and thousands of community-contributed MCP servers. Unfortunately, this newly emerged MCP ecosystem also in- troduces new attack surfaces. For example, researchers have found that attackers can exploit vulnerabilities in MCP to extract sensitive data or invoke unauthorized actions [16]. Moreover, subsequent research has shown that an untrusted MCP server can launch attacks and exfiltrate data from ap- plications that are simultaneously connected to trusted MCP servers [17]. However, these studies focus primarily on the security vulnerabilities arising from malicious MCP servers, we still lack a systematic understanding of the security issues in the MCP ecosystem. For example, how malicious servers are introduced into MCP hosts and what security implications they can trigger. In this paper, we present the first comprehensive security study of the MCP ecosystem. We begin by decomposing the ecosystem into three primary components, MCP hosts, MCP registries, and MCP servers, and analyze the interactions and workflow among them. For example, a user searches for MCP servers on MCP registries, and configures them in the MCP host through a JSON file (e.g., mcp.json). The MCP host then retrieves the tool names, parameters, and descriptions from the configured servers and maintains them in a unified tool list. 1 arXiv:2510.16558v1 [cs.CR] 18 Oct 2025 The host sends the user query (including the system prompt, the tool list, and the context history) to the LLM, translates the model output into a tool invocation, and subsequently executes the invocation. We then investigate the security issues present in these three components. We adopt a qualitative approach to analyze the security issues in the MCP hosts. Our analysis reveals that hosts per- form no verification of model outputs. Instead, they blindly invoke the tool and parameters returned by the model. This lack of verification leads to two major risks in the host. First, if two tools share the same name across different servers, the host might mistakenly invoke a tool from an unintended server, leading to inconsistent or potentially malicious behav- ior (i.e., tool confusion). Second, the host might attempt to invoke a tool that exists in the context history but has since been removed, resulting in failed or unintended operations (i.e., context dangling tool). Since MCP hosts do not implement any verification mech- anism, a configured malicious server can introduce severe security risks. In particular, a malicious server can embed harmful instructions into the description of one of its pro- vided tools. These descriptions are retrieved and stored by the host without validation. The model relies on these tool descriptions to interpret user queries and generate correspond- ing operations, which are then translated and invoked blindly by the host. A tool description can influence the modelâs behavior in two distinct ways: (i) it can directly prompt the model to generate additional abnormal operations, such as extracting private user data or invoking unauthorized actions (i.e., direct effects). (i) it can implicitly affect the behavior of benign tools co-configured in the same host, resulting in unintended or harmful consequences (i.e., indirect effects). Due to the lack of vetting mechanisms on MCP registries, attackers can hijack benign servers or trick users into down- loading malicious ones through various means, resulting in the introduction of a malicious server into the userâs host. For example, the registry mcp.so may inadvertently leak server ownersâ tokens, allowing attackers to inject malicious content into benign servers. In addition, inconsistencies between de- centralized MCP registries and the actual hosting locations (i.e., GitHub repositories) of servers introduce further risks. When the GitHub account hosting an MCP server is deleted or redirected (i.e., change the account), attackers can reclaim the vacated accounts and create the same server, effectively hijacking the server (e.g., redirection hijacking). Finally, on centralized registries, attackers can submit servers with names that closely resemble those of legitimate ones. As a result, users may be unable to distinguish between them and unknow- ingly download malicious servers. To quantitatively analyze the security issues in MCP reg- istries and servers, we collect data from four decentralized registries (i.e., mcp.so, MCP Market, MCP Store, and Pulse MCP) and two centralized registries (i.e., Smithery and npm). In total, we collected 67,057 MCP servers, covering a di- verse range of functionalities and programming languages. By analyzing these servers and their actual hosting GitHub repositories, we find that a substantial number are vulnerable to the proposed attacks. For example, 304 servers are suscep- tible to the redirection hijacking. We also extract 44,499 tools from the collected Python-based servers and identify a subset of tools exhibiting malicious behaviors or intentions. We then propose a set of practical defense strategies from three perspectives: MCP hosts, MCP registries, and end users. Finally, we responsibly disclosed our findings to the affected hosts and registries. In summary, the major contributions of this work include: ⢠We systematize the MCP ecosystem into three core com- ponents: MCP hosts, MCP servers, and MCP registries. We analyze the interactions and workflows among them, and identify the security issues existing in these three components. ⢠We show that, due to the lack of vetting mechanisms in MCP registries, attackers can hijack benign MCP servers. These compromised servers can then be used to launch various attacks on MCP hosts, which lack proper verifi- cation mechanisms. â˘We collect large-scale MCP server data from six MCP registries to support our quantitative analysis. â˘We disclose our findings to the impacted MCP hosts and MCP registries. We will open-source our code and collected data. 2 Model Context Protocol and Ecosystem Large language models (LLMs) have recently been integrated into a desktop assistant (LDA) as a permissioned tool to di- rectly operate on the userâs system. The LDA can translate the text output of LLMs into tool invocations (e.g., file system access and shell commands) and stream the results back to the users. LDAs inherit the privileges of the installing user, who typically has broader capabilities (and a larger attack surface) than browser-based chat interfaces. For example, they can access local files, networks, and operating system services. To enable developers to establish secure, bidirectional links between data sources and AI assistants, Anthropic introduced the Model Context Protocol (MCP), which is a standard for connecting LDAs to systems where relevant data resides, such as content repositories, business tools, and development envi- ronments. Below we briefly introduce the MCP ecosystem. 2.1 MCP Ecosystem The MCP architecture typically contains three core compo- nents. MCP Server is a lightweight program that can provide actions (e.g., a specific service or functionality). MCP Host 2 AI PaneMCP Clients Context history MCP Tools List MCP Server 1 install Code Hosting Platforms configure Users MCP registries LLMs MCP HostsMCP Servers MCP Server 1 add MCP Server 2 add 1_add 2_add ... ... ... ... MCP Server 2 MCP Server 1 Host Host MCP Registries MCP Client 1 MCP Client 2 stdio http+sse Figure 1: The overview of the MCP ecosystem. 1 2 "mcpServers": 3 # Local MCP server 4 "github": 5 "command": "docker", 6 "args": ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"], 7 "env": 8 "GITHUB_PERSONAL_ACCESS_TOKEN": "token" 9 10 11 # Remote MCP server 12 "semgrep": 13 "url": "https://mcp.semgrep.ai/sse" 14 15 16 Listing 1: MCP server configuration examples. is an LLM-integrated application (e.g., an LDA like Claude Desktop), which serves as the central coordinator to manage execution flows between the LLM and MCP servers. It sub- mits user requests to the model, translates the modelâs outputs into actions, and finally invokes them. MCP Client acts as a bridge between the host and an MCP server. The host uses the client to retrieve and invoke available actions, whose results will be returned to the host through the same client. Specifically, MCP servers define three types of actions: (i) prompts: provide instruction templates that guide the modelâs behaviors. (i) resources: offer structured context that helps ground the modelâs reasoning. (i) tools: executable functions that perform server-implemented functions based on inputs. Each tool includes a description that informs the model of its functionality, and can be invoked by the host through the corresponding client. MCP server configuration. The configuration of MCP servers is typically specified through a JSON file (e.g., mcp.json in Cursor), as shown in Listing 1. In addition, the server can be either a local server (line 4) or a remote server (line 12). Local servers run on the userâs system and are de- fined by acommandand itsargs(line 5 and 6), which specify how to start the server. The connection is established over a standard input/output (Stdio). Instead, remote servers are hosted on external infrastructure and only require aurlpa- rameter pointing to the serverâs endpoint (line 13). Some servers might require additional environment variables (env) to enable server functionality (line 7). Figure 1 shows the overview of the MCP ecosystem. Users can configure multiple MCP servers on the MCP host (step âś), which in turn creates multiple clients (stepâˇ) to con- nect to the corresponding servers and retrieve their primitives, including tool names, required parameters, and descriptions (stepâ¸). To use the system, the user first initiates the opera- tion through the MCP host (stepâš). The host then constructs a request and sends it to the LLM model (e.g., GPT-4o) (step âş). The request includes three types of information: (i) the system prompt, which is predefined by the host; (i) the tool list, including both server-provided tools and built-in tools offered by the host; and (i) the context, including the userâs query history (e.g., the initiated operation). The LLM processes the request by analyzing each tool description to identify the most suitable tool and extract the required parameters from the context. It then returns the se- lected tool and its parameters to the host (stepâť). The host invokes the selected tool through the corresponding client (stepâź) and updates the interface to indicate that a tool call has been initiated. Once the tool call completes, the host sends the result back to the LLM (stepâ˝). Finally, the LLM ana- lyzes the result to complete the reasoning process and returns the final output to the host (step âž). 3 2.2 Features in MCP Host The MCP host typically provides an AI pane that displays the userâs conversation history (context history) and a tool interface for managing configured servers and tools. It also maintains a set of MCP clients, with each tool invocation executed through the corresponding client. We next describe the hostâs features for managing configured servers and tools. Displaying Servers. The MCP host displays a list of config- ured MCP servers for users. There are two common display styles. The first one is simple display, which shows only the basic information, such as the server name, the connection sta- tus, and a toggle button to enable or disable the server. Some hosts provide a complete display, showcasing all available tools on each server along with their descriptions, parameters, and corresponding toggle buttons. MCP servers are displayed either in alphabetical order or in configuration order (based on the order in the configuration file). Updating Servers. To synchronize MCP server modifications, the MCP host needs to reboot existing clients and retrieve the latest server metadata (e.g., tool names and descriptions). This synchronization can be triggered each time the host is restarted (re-start) or the host detects changes in the configu- ration file (re-configure). The users can also actively disable and re-enable a server via its toggle button (re-enable). Tool Invocation Control. By default, the MCP host prompts users to confirm each tool invocation. To reduce manual over- head, it also supports an auto-run mode for automated execu- tion. We further find that this mode includes two variants: (i) basic auto-run, which permits all tools from all configured servers to execute automatically; (i) detailed auto-run, which restricts auto-execution to user-specified tools and servers. Invocation Results Displaying. For each invocation, the host displays the tool name, parameters, and result. MCP hosts also offer two display options: (i) collapse, which hides all these details; and (i) expand, which shows the full information. We have surveyed four popular MCP hosts (i.e., Cursor, Windsurf, Claude Desktop, and Cline) and summarized the supported features in Table 1. 2.3 MCP Registries Similar to software packages, MCP servers can be stored and shared in MCP registries. There are two types of registries, as introduced below. Centralized Registries. Centralized registries typically main- tain a website to showcase servers and host their files. They fall into two categories: (i) general-purpose registries, which build on existing registries (e.g., npm); (i) MCP-specific reg- istries, such as Smithery [42]. Accessing a server on Smithery requires a valid API key for authentication. Decentralized Registries. This type of registry does not main- tain a centralized website for managing MCP servers. Instead, it provides an index that lists MCP servers. The server files Table 1: Overview of supported features on each four hosts. The â means support. FeatureCursorWindsurf Claude Desktop Cline Displaying servers Simple displyâ Complete displayâ Alphabetical orderâ Configuration orderâ Updating servers Re-startâ Re-enable â Re-configureâ Invocation control Basic auto-runâ Detailed auto-runâ Results displaying Collapseâ Expandâ are hosted on external platforms (e.g., GitHub repositories or personal websites). These registries generally present server metadata to help users discover servers, including server name, server description, and server files link. Notable de- centralized registries include mcp.so [31], MCP Market [29], MCP Store [30], and Pulse MCP [38]. Among them, mcp.so provides additional metadata (i.e., server config), displaying setup examples to help users configure the server. Other reg- istries typically redirect users to the server file links to view configuration examples. Some registries also support server hosting. In such cases, users can configure servers using the URLs assigned by the registries. We find that both MCP Store and mcp.so provide this functionality. 3 Threat Model and Analysis Approach This paper investigates security issues in the MCP ecosystem. We attempt to analyze potential risks and address a series of research questions across the three entities introduced in the previous section, including MCP hosts, MCP servers, and MCP distribution. For example, are there weaknesses in the MCP distribution process that could allow attackers to eas- ily hijack existing MCP servers? If an attacker were able to compromise an MCP server, what types of malicious activi- ties could it perform against MCP hosts and users? Finally, given that MCP hosts may run multiple servers from different sources, do they provide sufficient isolation and verification mechanisms to ensure security? We use a hybrid (both qualitative and quantitative) ap- proach to analyze the MCP ecosystem. In particular, we con- duct a qualitative analysis of security risks in MCP hosts and a quantitative study of vulnerabilities in MCP servers and 4 registries. The rest of this section first presents a brief intro- duction of the threat model, and then discusses the method- ologies. 3.1 Threat Model In general, our threat model is constructed within the context of the MCP ecosystem, where users search for MCP servers in public MCP registries and configure them for use in MCP hosts. We assume that the connections between the host and servers, as well as between the host and models, are secure and not vulnerable to tampering. Under the above assumptions, our threat model focuses on two stages of the attack surface. (i) Registry-level attacks: due to the lack of vetting in MCP registries, attackers might exploit this weakness to hijack benign MCP servers or pub- lish benign ones that appear legitimate. Once users configure these attacker-controlled servers, the malicious content can be introduced into their MCP hosts. To hijack an existing benign server, attackers can obtain leaked credentials (e.g., GitHub tokens) that allow them to inject malicious content into the server. Alternatively, they can take over deleted or redirected third-party accounts (e.g., GitHub accounts hosting the server content) and re-register them, thereby gaining control over the associated servers. This form of hijacking poses a severe risk: users unknowingly upgrade from a once-benign server to a compromised one, continuing to trust its integrity. In addition, attackers can adopt techniques similar to typosquat- ting [14, 24]. For example, publishing a server with a name nearly identical to a benign service (e.g.,github-mcpinstead ofgithub) to impersonate an MCP-compatible version and trick users into downloading it. (i) Post-integration attacks: Once a malicious server is integrated into the host, the attacker can manipulate its tool and associated metadata (e.g., tool description) to exploit the host. Also, the attacker can abuse host-provided features to stealthily inject malicious commands or achieve different attack objectives. For example, attackers can leverage the up- dating servers feature to inject malicious instructions into the tool descriptions or to craft deceptive return error messages. 3.2 Qualitative Analysis We begin by installing four MCP hosts (i.e., Cursor, Windsurf, Claude Desktop, and Cline) and developing local servers to investigate security issues in both hosts and servers. To fa- cilitate this analysis, we leverage a logging feature provided by the model provider, OpenAI, which records both input requests and corresponding outputs. We enable this feature by configuring an OpenAI API key within the MCP host Cur- sor, allowing us to capture detailed traces of tool invocations. From the logs recorded by OpenAI, we analyze the requests issued by the host and the corresponding outputs generated by the model (e.g., GPT-4o), which are returned to the host. The Figure 2: Number of MCP servers across registries. host then translates the model outputs into concrete opera- tions, such as invoking a tool provided by a configured server. By examining both the model outputs and the resulting host behaviors, we are able to identify security issues present in both the host and servers. We then repeat our experiments on all four MCP hosts. For each host, we select three commonly used LLMs (i.e., GPT-4o, Claude Sonnet 4, and Gemini 2.5 Pro) to verify the presence and consistency of identified issues, except for Claude Desk- top, which only supports Claude Sonnet 4. Each experiment is conducted five times for every hostâmodel pair to ensure reliability and account for potential variability in model out- puts. 3.3 Quantitative Analysis Next, we collect data from MCP registries (e.g., server meta- data) to quantitatively examine the security risks present in the registry. Finally, we extract tools from the collected servers to evaluate whether the identified MCP server security issues manifest in real-world deployments. MCP Registries Selection. We use mastra [28], a registry of MCP registries, to select the most relevant ones for our study. Our selection is based on three criteria: (i) The registry hosts a large number of MCP servers. (i) It provides a feature to list all MCP servers, which enables us to collect the data. (i) It allows users to submit their own MCP servers. Based on these criteria, we select 5 out of the 27 registries listed on mastra, which are four decentralized registries mcp.so, MCP Market, MCP Store, Pulse MCP, and a centralized registry Smithery. In addition, we include npm as a representative centralized registry, given its widespread adoption in practice. 3.3.1 Data Collection Decentralized Registries Each decentralized registry pro- vides an index page listing all servers. This page displays metadata about each server, such as its name and description. More detailed information, including server file links and, in 5 the case of mcp.so, the optional server config, is only available on the serverâs detail page. Therefore, we first crawl the index page of each registry to retrieve the list of MCP servers. Then, we visit the detail page of each server to obtain its server file link. For mcp.so, we also collect the server config when it is provided by the server owner. Next, we visit each server file link and record its status (i.e., valid or invalid). If the link is valid, we proceed to download the corresponding server content for further analysis. Centralized Registries. Centralized registries typically pro- vide APIs for retrieving servers. For example, Smithery of- fers one API to list all available servers and another to re- trieve detailed information for each server (e.g., tools it pro- vides). Both APIs require a valid Smithery API key. Accord- ingly, we use these two APIs to collect server data hosted on Smithery. In contrast, npm does not provide a dedicated cate- gory to distinguish package servers (i.e., MCP servers) from regular packages. To address this, we use the npm package all-the-package-namesto retrieve all packages containing the keywordmcp, and then collect metadata for each candi- date package, including its dependencies and maintainers. However, not all keyword-matching packages are necessar- ily MCP servers. Since every MCP server is built upon the MCP protocol, it must depend on at least one MCP SDK, such asmodelcontextprotocol/sdkorfastmcp. Therefore, we examine the dependencies of each collected package and ex- clude those that do not rely on known MCP SDKs. We collect data between late June and early July 2025, re- sulting in a total of 67,057 MCP servers from all registries. The distribution of collected servers across registries is shown in Figure 2. We then analyze the server file links from de- centralized registries and identify that 52,102 (99.16%) out of 52,539 are provided as GitHub repositories (i.e., using the formatuser/repo), indicating that MCP ecosystem is highly dependent on GitHub as the primary hosting platform. Furthermore, only 2,626 server file links appear in all four de- centralized registries at the same time, showing the diversity and flexibility of the ecosystem. 3.3.2 Tool Extraction We first analyze the programming languages used to de- velop the MCP servers, followed by static code analysis on the downloaded server content to extract tools implemented within the servers. To identify the programming languages, we query the GitHub API, as 99.16% of the servers are hosted on GitHub repositories. Figure 3 shows the distribution of pro- gramming languages used across decentralized registries. We focus on extracting tools from servers developed in Python for two reasons. First, Python is the most commonly used lan- guage for implementing MCP servers. Second, Python-based servers typically define tools using decorators (e.g., functions annotated with@mcp.tool()), which makes tool extraction more straightforward. Therefore, we parse the abstract syntax Figure 3: Distribution of programming languages used in MCP server implementations. tree (AST) of each Python file to identify function definitions annotated with the decorator (e.g.,@mcp.tool()). For each matched function, we further extract its name, descriptions, and return values. In total, we extracted 44,499 tools from Python-based MCP servers collected across the four decen- tralized registries. 3.4 Ethical Considerations In this paper, we collect all data either by crawling registry websites or by accessing official platform APIs (e.g., Smith- ery). For web crawling, we set an interval of 30-60 seconds between requests, as our goal is to collect data in an auto- mated yet respectful manner. When using APIs, we strictly follow the usage guidelines and rate limits specified by the platforms. For credential verification, we issue a single API request, following the methodology outlined in [23]. In all experiments, we only created MCP servers and configured them locally; none were submitted to public registries. We do not launch any actual attacks against the MCP hosts and the models. All experiments were conducted as proof-of-concept demonstrations, with no real-world impact or interaction with external users. The details of our disclosure can be found in Section 7.2. 4 Security Issues in MCP Hosts MCP hosts invoke tools returned by the model without per- forming any form of verification or validation. Once the model outputs a tool name and its associated parameters, the host di- rectly invokes the corresponding tool on the server, implicitly assuming that the modelâs decision is both correct and safe. However, this assumption is problematic, especially given that model behavior can be influenced by untrusted inputs, such as crafted tool descriptions. The lack of verification introduces a critical surface. If the model is misled, whether intentionally or unintentionally, the host might invoke the wrong tool, pass 6 Figure 4: Prevalence of identical tool names across different servers. incorrect parameters, or trigger harmful operations. When the host sends a user operation to the model, it builds a request that includes three parts: the system prompt, the tool list, and the context history of user operations. The model then processes this request based on all of this information. This raises two significant issues. 4.1 Identical Tool Names Issue The first issue is that multiple MCP servers can have tools with the same name. Without verification, the host might invoke a tool from an unintended server, potentially causing incorrect or malicious operations (e.g., invoke the one controlled by the attacker). 4.1.1 Tool Confusion Although the host spawns a separate process for each client to isolate individual servers and their hosted tools, it main- tains a unified list of tools aggregated from all configured servers. This tool list is then sent to the model for decision- making. However, when two tools share the same name but originate from different servers, we observe that the host might invoke the incorrect tool, even if the model selects the one from the intended server. For example, the host main- tains a tool list containing two tools,mcp_A.send_email, andmcp_B.send_email, wheremcp_is the common prefix, andAandBrefer to different MCP server names. In this case, even if the model returns the tool from serverB, the host mis- takenly invokes the tool from serverA. We refer to this issue as tool confusion. Result. We find that the Cursor host is vulnerable to tool confusion: regardless of whether the model selects the tool from serverAorB, Cursor consistently invokes the tool that appears first in the tool list. This behavior is unexpected, given that the Cursor prefixes tool names with a combination Figure 5: Context dangling tool issue success rate per hostâmodel pair. of mcp_ and server names to distinguish tools across servers. However, these prefixes are disregarded at invocation time, causing the host to invoke the first-listed tool regardless of the modelâs actual selection. In Cursor, the tool list is ordered according to the sequence in which servers appear in the configuration file, introducing a fixed bias toward tools from earlier-listed servers. In contrast, the other three hosts do not exhibit this confusion behavior. To identify tools with the same names, we group together all tools that share the same name but come from different servers. Figure 4 displays the prevalence of identical tool names across different servers. The tool name add is the most common, appearing 379 times. These results indicate that identical tool names are widespread, which can lead to tool confusion. Therefore, when configuring servers, users must pay close attention to tool names to avoid potential tool confusion attacks. 4.2 Inconsistent Information in Request The second issue stems from inconsistent information within the request sent to the model. Although the server has been removed, the context history embedded in the request can still contain the history of previously available tools. As a re- sult, the model might still reference the tool from the context. Without a verification mechanism, the host will blindly exe- cute the invocation, potentially leading to failed or unintended operations. 4.2.1 Context Dangling Tool Issue Suppose the context history within a request includes a pre- viously successful tool invocation, and the user subsequently removes the server that hosted that tool. In that case, an in- consistency arises: the tool remains in the context history but no longer exists in the current tool list. When the user reuses the same context and attempts to invoke the tool again, the model might reference the now-removed tool based on 7 prior interactions, despite its absence from the current tool list. Due to the hostâs lack of a verification mechanism, it does not validate whether the referenced tool is still available before executing the invocation. As a result, the host blindly proceeds with the invocation, leading to failed or undefined behavior. We refer to this issue as the context dangling tool issue. This scenario is not uncommon. For example, when a user closes and reopens Cursor, the host reinitializes clients to the configured servers while restoring the prior context. Additionally, all four hosts store previous context histories to support session continuity. As a result, each time a user reopens the host and selects a prior conversation, this issue might occur if the restored context references tools that are no longer available. Result. We find that none of the hosts implements a verifica- tion mechanism to ensure that the tools returned by the model still exist in the current tool list. As a result, hosts blindly rely on model outputs without validating tool availability, which can lead to failed invocations when the referenced tool is no longer accessible. Figure 5 presents the success rate across hostâmodel pairs. This success rate reflects cases where the model failed to find the tool in the current tool list but was able to retrieve it from the context history and return it. Since the tool list and context history remained the same, the observed differences in success rates are likely caused by variations in the system prompts. Among all hosts, Windsurf handles this issue most robustly; in contrast, Cline exhibits the worst behavior, returning a tool that no longer exists in the current tool list every time. 5 Security Issues in MCP Servers Once the host creates clients to connect to the configured MCP servers, it retrieves the metadata from the servers, in- cluding the tool names, descriptions, and required parameters. However, existing MCP designs treat these metadata as trust- worthy and static, without enforcing authenticity, integrity, or immutability. In particular, the host feature of updating servers enables it to fetch the latest metadata from the con- figured servers, but this process lacks any validation of the received metadata. This further weakens the reliability of the metadata, as the servers themselves are not inherently trust- worthy and might be compromised or hijacked by attackers. The MCP servers can be configured locally or remotely. For remote servers (e.g., those hosted on registries), once hijacked, the server metadata can be arbitrarily modified by an attacker at any time. Even for locally downloaded servers, attackers can still exploit the update mechanism by releasing a malicious new version that deceives users into replacing their existing installation. This risk is exacerbated by the fact that updates can occur automatically. For example, the npxcommand, commonly used to start local MCP servers, automatically fetches the latest version from the npm registry. The host aggregates the metadata of the retrieved tool and sends it to the model for analysis. If a tool description con- tains misleading information, the model might rely on it and generate a corresponding, potentially harmful operation. The description of the tool can influence the behavior of the model in two distinct ways. 5.1 Direct Effect of Tool Metadata The first issue of tool metadata is its direct effect. We find that the description can directly prompt the model to perform additional actions beyond the toolâs intended scope. 5.1.1 Tool Poisoning Attack The tool metadata retrieved from configured MCP servers is mutable and untrusted. When a user invokes a tool con- trolled by an attacker, the attacker can modify the metadata (i.e., the tool description) to mislead the model into gener- ating unintended operations, which are then returned to the host. Since the MCP host lacks a verification mechanism, it blindly executes any output returned by the model, potentially leading to harmful actions such as file access or arbitrary tool invocation. When the auto-run mode is enabled, this entire sequence proceeds without user awareness or intervention. However, the tool metadata is also visible to users, and hosts such as Cursor, Windsurf, and Cline support detailed display of this information. With careful inspection, users might notice suspicious or malicious descriptions. Beyond metadata manipulation, we find that attackers can also tam- per with a toolâs return values to further mislead the model. For example, an attacker can deliberately cause a tool to fail and return a crafted error message. This manipulated mes- sage is then forwarded to the model for analysis, prompting the model to infer that the failure resulted from a missing preparatory step. As a result, the model generates additional operations, causing the host to unknowingly execute the at- tackerâs intended behavior and re-invoke the tool. We identify three types of poisoning attacks that can be posed. (i) abuse of built-in tools. By misleading the model, attackers can induce it to invoke host-provided built-in tools for malicious purposes, including reading sensitive files, ex- ecuting harmful commands, or accessing phishing websites. (i) extraction of request information. Each request sent to the model includes the system prompt, tool list, and user in- teraction history. By crafting misleading metadata or a return error message, the attacker can manipulate the model into extracting this information and embedding it into tool parame- ters. As a result, sensitive data is leaked to attacker-controlled tools. (i) abuse of server-provided tools. Attackers can exploit tools hosted on other configured servers, including those that require user credentials (e.g., tools interfacing with GitHub). By misleading the model, they can induce the host to invoke these tools in ways that execute unauthorized actions on behalf of the user. 8 Table 2: Tool poisoning attacks in the target models on each host. ASR: Attack Success Rate. Crafted Tool Descriptions | (ASR %)Crafted Returned Error Messages | (ASR %) Host & Model built-inrequest informationserver-providedbuilt-inrequest informationserver-provided Cursor & GPT-4o800.0601001000.0 Cursor & Claude Sonnet 41001006010010080 Cursor & Gemini 2.5 Pro 1001001008010080 Windsurf & GPT-4o202040804040 Windsurf & Claude Sonnet 4 10010060100100100 Windsurf & Gemini 2.5 Pro 10010080100100100 Claude Desktop & Claude Sonnet 41001002010010080 Cline & GPT-4o 401000.010010060 Cline & Claude Sonnet 410010080100100100 Cline & Gemini 2.5 Pro100100100100100100 Result. As shown in Table 2, the success rate of tool poison- ing attacks is primarily determined by the modelâs behavior, as hosts do not implement any verification and directly invoke the modelâs output. Across the three target models, Claude Sonnet 4 and Gemini 2.5 Pro consistently interpret the crafted tool descriptions and returned error messages, and accordingly generate operations that are returned to the hosts. In contrast, GPT-4o exhibits more conservative behavior and often ignores or fails to act on the crafted tool descriptions and returned error messages. Specifically, based on the thinking process displayed by the hosts, we observe that Gemini 2.5 Pro can identify abnormal instructions embedded in the tool descrip- tions and return error messages. However, it still chooses to follow the instructions, stating that it is better to proceed with them regardless. Therefore, it returns the malicious operations to the hosts, which, due to the lack of verification mechanisms, invoke them without validation. When invoking tools, the success rate is consistently higher for built-in tools compared to server-provided ones. This in- dicates that the model is more sensitive to server-provided tools when processing tool descriptions and returned error messages. In other words, the model is more likely to refuse to generate operations when it detects that the embedded tool originates from a server. Notably, Claude Desktop exhibits insufficient verification. While it sometimes blocks tool in- vocation and displays an âunable to respond to this requestâ message, it still occasionally invokes abused tools, indicating inadequate response handling. The success rate of using crafted returned error messages is higher than that of using crafted tool descriptions. This is because the former divides the attack into two stages: the first tool invocation fails intentionally, and the second is re-invoked with additional malicious actions (e.g., reading a file). This two-step process mimics reasoning, thereby improving the attackâs reliability. Moreover, the crafted return error message is more covert, as it only alters the toolâs return value without being visibly displayed in the host. To detect potentially malicious descriptions, we focus on those containing the<IMPORTANT>section, which is often Figure 6: Tool shadowing attack success rate per hostâmodel pair. used to attract the modelâs attention. We then manually review the filtered descriptions to verify the presence of malicious instructions. To detect potential malicious return values, we first filter those resembling prompts using keywords such as read, execute, and extract. We then manually examine these return values to confirm whether they contain malicious or unintended instructions. We identify 14 tools with malicious tool descriptions, most of which appear to be designed for proof-of-concept purposes. Additionally, we observe 2 abnormal returned error messages that attempt to influence the modelâs behavior. 5.2 Indirect Effect of Tool Metadata The second issue is the indirect effect, where a tool description can manipulate the modelâs interpretation of input parameters of the actual selected tool, leading to the extraction of twisted parameters. 5.2.1 Tool Shadowing Attack The tool poisoning attack succeeds only when the host in- vokes a tool controlled by the attacker. However, the attacker can also manipulate the metadata (e.g., descriptions) of their own tool to mislead the model even when the model ultimately selects a benign tool. This indirect influence can cause the 9 model to extract incorrect parameters based on the attackerâs crafted metadata. For example, when a user intends to invoke a target tool (e.g., send_email), the model analyzes tool descriptions to select it and extract relevant parameters. An attacker exploits this process by injecting misleading descriptions into their own tool, aiming to distort the modelâs interpretation of the in- tended parameters (e.g., the recipient). As a result, the model replaces the user-specified email recipient with an attacker- controlled address (e.g., attacker@email.com), causing the tool to send the email to the attacker instead. All hosts, except Cline, collapse the tool parameters and invocation results by default, displaying only summaries gen- erated by the models. As a result, a user only sees a confirma- tion that an email is sent successfully, without realizing that it is actually delivered to an attacker-controlled address. Result. As shown in Figure 6, this attack consistently suc- ceeds on Cursor, Windsurf, and Cline, except for GPT-4o on Windsurf, where one failure case was observed. These models follow attacker-crafted descriptions, allowing the attacker to influence target tools (e.g., by replacing the intended recip- ient). The hosts then invoke the tool using the parameters returned by the model without additional verification. Claude Desktop is the only host that implements a verification mecha- nism. In some cases, it refuses to invoke the tool and responds with the message: "unable to respond to this request, which appears to violate our usage policy." However, we also ob- serve two cases where the host displays this error message but still proceeds to invoke the tool. This indicates that while Claude Desktop performs parameter validation, it does not enforce it consistently. We detect 2 malicious tool descriptions, both of which serve as proof-of-concept examples to demonstrate the tool shadowing attack. The relatively low number of detected malicious tools can be attributed to two factors: our scope is limited to Python- based servers, and the detection methods are conservative, such as requiring the presence of a<IMPORTANT>section. Nevertheless, these proof-of-concept tools demonstrate the feasibility of such attacks. 6 Security Issues in the MCP Registries MCP registries are open platforms where anyone can publish their own MCP servers. However, these registries lack any meaningful vetting mechanism, which introduces significant security risks. These risks manifest in three primary ways. 6.1 MCP Server Information Unvetted Issue The first issue lies in the lack of review for submitted servers, which are often either entirely unvetted or inadequately ex- amined. On decentralized MCP registries, each server must include a link to its actual server files, as the registry only Table 3: Invalid links, empty server content, and missing README files in decentralized registries. Registries Invalid Server File Links | % Empty Server Content | % Missing README | % mcp.so6.750.071.04 MCP Market 3.3000.29 MCP Store0.184.2510.11 Pulse MCP 0.140.041.73 serves as an index and does not host any content. Without a proper vetting mechanism, these submitted servers might become completely unusable. On centralized MCP registries, the submitted server might be empty with no provided tools. In addition, the registry mcp.so provides server configura- tion examples (i.e., server configs) to help users set up servers. However, due to the carelessness of server owners, these con- figurations might include sensitive credentials required for servers. In the absence of a proper vetting mechanism, such exposures can lead to credential leakage (e.g., GitHub tokens), resulting in server hijacking or compromise. 6.1.1 MCP Server Information Missing. Due to the lack of review for submitted servers, the MCP server information provided for users to configure these servers might be incomplete or invalid. The most common issues include: (i) invalid server file links, where users are unable to locate the actual server content; (i) empty server content, where the links are valid but the server files contain no functional components; (i) missing README files, where the server content exists but lacks important files, making it unclear how to properly configure or use the server. Result. We verify server file links by requesting their URLs and recording the response codes:200indicates validity, whereas404denotes invalid links. For valid links, we query the GitHub API to check the repository content; if the re- sponse states "This repository is empty," we label the server as empty. For non-empty servers, we further examine the pres- ence of a README file through the GitHub API to detect missing files. Table 3 summarizes the results of three common issues ob- served in decentralized MCP registries. Among all registries, mcp.so shows the highest proportion of invalid server file links (6.75%), while MCP Store suffers the most from empty content (4.25%) and missing README files (10.11%). In contrast, Pulse MCP and MCP Market show relatively low error rates across all three categories. These results highlight the lack of a vetting mechanism across decentralized reg- istries, which may prevent users from correctly configuring or utilizing the servers. In the centralized registry, Smithery, among 7,682 servers, 5405 (70.35%) do not provide any tools, indicating that a large portion of registered servers are incomplete. In the npm, 10 Figure 7: A leaked GitHub token discovered on the registry mcp.so. The token is blurred in the figure, as it was still valid at the time of disclosure. among 6,836 servers, 377 (5.51%) have released at least 20 versions, indicating potentially suspicious behavior, such as concealing malicious changes across versions. 6.1.2 MCP Server Maintainer Credential Leakage Some MCP servers require users to configure tokens or keys before use. To help with this, owners often provide config- uration examples, as supported by mcp.so. However, some owners forget to remove their own tokens from these exam- ples, leading to credential leaks. If obtained by attackers, these leaked tokens can be used to hijack the server or abuse the ownerâs services. Among the exposed credentials, GitHub personal access tokens (PATs) are particularly critical, as they are used to au- thenticate users and authorize access to GitHub resources [11] This poses a significant risk, given that 99.16% of servers are hosted as GitHub repositories. GitHub supports two types of PATs: (i) fine-grained tokens, which have narrowly scoped permissions and can only access resources owned by the user; and (i) class tokens, which grant broader access, in- cluding write permissions to public repositories not owned by the user and to all repositories within accessible organiza- tions [11]. When exposed, especially classic tokens, attackers can use them to inject malicious content into repository host- ing servers, resulting in server hijacking. mcp.so enables developers to submit configuration exam- ples that appear on server detail pages. It offers a GitHub- specific configuration template for guidance, but some owners misunderstand it and insert their own PATs, even when the server is unrelated to GitHub, leading to unintended exposure. Result. To identify publicly exposed tokens, we use gitleaks, a tool designed to detect secrets (e.g., tokens, API keys) on the server configs collected from mcp.so. Since gitleaks might produce false positives (e.g., flagging placeholders like your- token), we manually review all detections to filter out false detections. Among 5,659 server configs collected, we identify 9 PATs, 3 Smithery keys, one each of firecrawl-api-key, jwt, and aws- access-token. Because PATs can expire, we conduct a simple test to verify their validity. For each token, we send a request to the GitHub user API, targeting our own account. A response with status code200indicates a valid token, while a response with the message Bad credentials confirms that the token is invalid. As of early July 2025, 5 PATs remain valid, including 3 classic tokens. Figure 7 presents a valid real-world example of a leaked token found in the registry mcp.so. 6.2MCP Server Information Inconsistency Is- sue The second is the inconsistency between the decentralized MCP registries and the actual server hosting platforms. Server owners may delete or migrate their servers over time, resulting in inconsistencies between the registry servers and the actual hosting platforms. For example, the server has migrated to a new address. Such discrepancies open the door for attackers to hijack these servers by reclaiming their abandoned addresses. In this case, users who visit the original server address are unknowingly redirected to a malicious server controlled by the attacker. 6.2.1 MCP Server Maintainer Hijacking Attack As shown in Table 3, we detected 0.14% to 6.84% invalid server file links across the four registries, totaling 1,379. This indicates that the corresponding repositories have been deleted by the developers, yet the registries continue to list these servers as active due to a lack of update mechanisms. According to GitHub documentation, when an account is deleted, it becomes available for registration after 90 days [10]. This opens the door for attackers to register the deleted ac- counts and recreate previously removed repositories. As a result, users accessing server file links that once pointed to legitimate repositories might unknowingly connect to attacker- controlled ones that have been recreated under the same name. Result. To identify GitHub accounts that can be re-registered, we extract accounts from the invalid server file links and query the GitHub User API. A response with status code 200indicates that the account still exists and cannot be re- registered, while a404response means the account has been deleted and is available for registration. As shown in Table 4, out of 1,379 invalid links, we find 212 cases (15.37%) where the associated GitHub accounts are re-registrable, creating opportunities for attackers to hijack the corresponding MCP servers. Among the registries, mcp.so has the highest number of such accounts (111), while Pulse MCP has the fewest (1). Users who later visit or configure these hijacked servers may unknowingly introduce security threats into their LDAs and underlying systems. 11 Table 4: Detected hijackable MCP servers across decentral- ized registries. RegistriesMaintainer HijackingRedirection Hijacking mcp.so11198 MCP Market9550 MCP Store 5155 Pulse MCP11 Total212304 6.2.2 MCP Server Redirection Hijacking Attack GitHub allows developers to change their accounts to new, unused ones. After such changes, the old accounts become available for anyone (e.g., attackers) to claim, while links to repositories under the old accounts automatically redirect to the new ones. This creates an opportunity for attackers to re-register the old accounts and recreate the repositories (i.e., MCP servers) under them. Once this occurs, GitHub terminates the redirection. This type of attack is known as redirection hijacking, with package redirection hijacking at- tack [14] and plugin redirection hijacking attack [22] being two well-known examples. In this work, we present a third form of redirection hi- jacking: the MCP server redirection hijacking attack. De- centralized MCP registries are unaware of GitHub account changes and do not update their records accordingly. As a result, users accessing GitHub repositories through server file links in the registries, whose accounts have been changed, might end up accessing attacker-controlled repositories, as attackers re-register the old usernames and redirections are cut off. Unlike server file links pointing to deleted accounts, which become invalid, links under redirected accounts remain valid, as GitHub automatically redirects them. This makes such attacks more stealthy and harder to detect. Result. To detect redirected GitHub accounts that can be re- registered, we extracted them from valid server file links and then queried the GitHub user API. A200status code means the account is in use and cannot be re-registered, while a404 indicates it is available. Table 4 shows our detected results, we find 304 in total GitHub redirected accounts that attackers could reclaim to hijack the corresponding MCP servers. To check if developers continued maintaining these servers, we examined whether new servers with the same name are submitted using the links under updated accounts. We find 139 such cases. For example, on MCP Market, the server Share still points to the server file link to the old account amesoraqwq, while a new Share server is submitted under the new account ArcStellar2025. This can confuse users, who might mistakenly choose the hijacked version under the old account. Figure 8: MCP server maintainer comparison on npm registry. 6.3 MCP Server Informal Naming Issue The final issue lies in the informal naming practices used in centralized MCP registries. Such practices can mislead users into interacting with malicious MCP servers that appear legitimate. 6.3.1 MCP Server Affix-squatting Attack To distinguish MCP packages (i.e., servers) from regular ones, developers often adopt informal naming practices, such as appending a suffix like -mcp (e.g., firecrawl-mcp, an MCP server built on Firecrawl for web scraping) or prepending a prefix like mcp-server (e.g., mcp-server-code-runner, which executes code snippets). However, these conventions are nei- ther standardized nor enforced. This lack of formal naming creates opportunities for abuse. For example, an attacker might release a malicious MCP server with a name nearly identical to a legitimate one (e.g., package-mcp), but with an additional suffix (i.e., package- mcp-server) to deceive users. We refer to this as the MCP server affix-squatting attack, which differs from traditional typosquatting. While typosquatting exploits common mis- spellings, affix-squatting leverages the legitimate package name with a misleading affix to mislead users into config- uring a malicious server. This attack affects only the npm registry. Result. To detect affix-squatting MCP packages, we use regu- lar expressions to group packages that share the same package name but differ in affixes. For each group, we examine the maintainer information, as some developers might intention- ally publish multiple affixed packages themselves. We ex- clude groups where all packages are maintained by the same developer. As shown in Figure 8, out of 408 identified groups of MCP packages with identical names but different affixes, 80.6% are maintained by different developers, highlighting the potential risk of affix-squatting attacks. In addition to -mcp (166) and - mcp-server (138), developers frequently use prefixes like mcp- (88) and composite affixes such as mcp-package-server (33) (e.g., mcp-image-server). 12 7 Countermeasures and Disclosure 7.1 Defense Practices We propose several defense practices to mitigate the uncov- ered threats from three perspectives: MCP hosts, MCP reg- istries, and users. For MCP hosts, an additional verification mechanism could be implemented to prevent the execution of potentially harm- ful operations returned by the model. For example, before the invocation of a tool, a verification of its existence and integrity can avoid executing dangling ones. Also, model-generated error messages should be handled with extra caution to avoid blindly following misleading instructions. For MCP registries, particularly decentralized ones, peri- odic validation of server metadata (e.g., server file links) is essential. Registries should routinely check the availability of server links (e.g., GitHub repositories) and remove entries that are invalid, empty, or point to deleted accounts. Moreover, reg- istries can encourage best practices by requiring server owners to sanitize configuration examples, especially to ensure that no sensitive tokens are exposed before submission. For users, it is important to review the configuration of loaded servers each time an MCP host is launched, as unautho- rized modifications may be silently introduced. When brows- ing or integrating servers from registries, users should verify the validity of server links, check for redirections, and avoid configuring untrusted or suspicious servers. 7.2 Disclosure We have promptly disclosed our findings to both the host and the relevant MCP registry. Specifically, we have reported the tool confusion issue to Cursor. According to Cursorâs security policy [5], vulnerabilities can be reported either through its public GitHub security page or via a designated private email channel. To preserve anonymity, we opted for the private dis- closure channel and submitted our report via the designated email address. Specifically, we provided the MCP server code used in our experiments, the corresponding server configu- rations, and supporting screenshots. We are still waiting for their response, and will update it once we receive it. Given the absence of publicly available contact information for several affected MCP server owners, we have disclosed the findings to mcp.so, along with a list of MCP servers containing leaked credentials. We hope that the registry can notify the affected owners or take appropriate actions to address the exposed credentials. We submitted our findings on August 24 th . 8 Related Work General LLM Security. Prior research has extensively studied the security of LLMs, including data poisoning at- tacks [2, 39, 53], jailbreak attacks [6, 41, 49], backdoor at- tacks [18, 52, 55], prompt injection attacks [12, 26, 27, 50], and adversarial attacks [40, 48, 56]. In contrast, our work does not aim to compromise the LLMs themselves. Instead, we investigate the security implications that emerge when LLMs are integrated into real-world applications, focusing on the consequences of misleading outputs and how these outputs can lead to harmful operations when executed by applications lacking verification mechanisms. LLM Application Security. Extensive research has explored the security of LLM-based applications [1, 7, 15, 21, 36, 51, 58, 60]. Pedro et al. [37] examined prompt-to-SQL injection attacks against LLM-integrated web applications and pro- posed four effective defense strategies. Liu et al, [25] devel- oped LLMSMITH to detect and validate RCE vulnerabilities in LLM-integrated frameworks and applications. Zhang et al. [57] uncovered content poisoning attacks, in which at- tackers craft inputs that appear benign to humans but cause LLM-powered applications to produce malicious outputs. In contrast, our work is the first to systematically investigate the security of LLM desktop assistants in the context of malicious MCP servers. Registry Ecosystem Exploit. The software registry ecosys- tem faces various security threats, including account hijack- ing [8, 13] and typosquatting [46]. Duan et al. [9] proposed a comparative framework to assess security risks in PyPI, npm, and RubyGems, identifying account hijacking as the second most prevalent threat. Zimmermann et al. [59] inves- tigated account hijacking via conventional techniques, such as weak passwords and social engineering. Zahan et al. [54] further highlighted this issue in npm, linking it to expired email domain names. Gu et al. [14] extended the analysis to six registries, including the decentralized Go registry, which stores package code on GitHub, and revealed that account hijacking can be carried out by reclaiming deleted third-party accounts (e.g., GitHub). In contrast, our work is the first to investigate this threat within MCP registries. Notably, this risk is amplified by MCP-specific features, such as the leakage of GitHub account credentials through server configs provided by mcp.so. Many research studies have been conducted on typosquat- ting [3, 19, 34, 43]. Prior works mainly focus on domain names [20, 33, 35] or package names [47, 59]. In contrast, our study is the first to identify the affix-squatting attack, in which attackers append prefixes, suffixes, or both to legitimate pack- age names, producing variants that appear legitimate, such as an MCP-branded version of the original package. 9 Conclusion In this paper, we present the first comprehensive security analysis of the Model Context Protocol (MCP) ecosystem. We systematically decompose the ecosystem into three core components: MCP hosts, MCP registries, and MCP servers, 13 and then we analyze the interactions among them. Our study reveals that the lack of a verification mechanism in MCP hosts and the unvetted submission process in MCP registries introduce a broad range of attack surfaces. To support our analysis, we collect and analyze a large-scale dataset com- prising 67,057 MCP servers from six public registries, and extract 44,499 tools from Python-based servers. Our empiri- cal findings highlight systemic issues across MCP registries and servers. We propose practical defense strategies and have reported our findings to the corresponding MCP hosts and registries. References [1]Sara Abdali, Richard Anarfi, CJ Barberan, Jia He, and Er- fan Shayegani. Securing large language models: Threats, vulnerabilities and responsible practices. arXiv preprint arXiv:2403.12503, 2024. [2]Hojjat Aghakhani, Wei Dai, Andre Manoel, Xavier Fer- nandes, Anant Kharkar, Christopher Kruegel, Giovanni Vigna, David Evans, Ben Zorn, and Robert Sim. Tro- janpuzzle: Covertly poisoning code-suggestion models. In 2024 IEEE Symposium on Security and Privacy (SP), pages 1122â1140. IEEE, 2024. [3]Pieter Agten, Wouter Joosen, Frank Piessens, and Nick Nikiforakis. Seven monthsâ worth of mistakes: A lon- gitudinal study of typosquatting abuse. In Proceedings of the 22nd Network and Distributed System Security Symposium (NDSS 2015). Internet Society, 2015. [4]Anthropic.Introducing the model context pro- tocol.https://w.anthropic.com/news/ model-context-protocol, 2025. [5]Cursor Security. Cursor security.https://cursor. com/security, 2025. [6] Gelei Deng, Yi Liu, Yuekang Li, Kailong Wang, Ying Zhang, Zefeng Li, Haoyu Wang, Tianwei Zhang, and Yang Liu. Jailbreaker: Automated jailbreak across mul- tiple large language model chatbots. arXiv preprint arXiv:2307.08715, 2023. [7]Z Deng, Y Guo, C Han, W Ma, J Xiong, S Wen, and Y Xiang. Ai agents under threat: A survey of key secu- rity challenges and future pathways. arxiv, 2024. [8]Periwinkle Doerfler, Kurt Thomas, Maija Marincenko, Juri Ranieri, Yu Jiang, Angelika Moscicki, and Damon McCoy. Evaluating login challenges as adefense against account takeover. In The World Wide Web Conference, pages 372â382, 2019. [9]Ruian Duan, Omar Alrawi, Ranjita Pai Kasturi, Ryan Elder, Brendan Saltaformaggio, and Wenke Lee. To- wards measuring supply chain attacks on package managers for interpreted languages. arXiv preprint arXiv:2002.01139, 2020. [10]GitHub Docs. Deleting your personal account.https: //docs.github.com/en/account-and-profile/ setting-up-and-managing-your-personal-account-on-github/ managing-your-personal-account/ deleting-your-personal-account, 2025. [11] GitHub Docs. Managing your personal access tokens. https://docs.github.com/en/authentication/ keeping-your-account-and-data-secure/ managing-your-personal-access-tokens, 2025. [12] Kai Greshake, Sahar Abdelnabi, Shailesh Mishra, Christoph Endres, Thorsten Holz, and Mario Fritz. Not what youâve signed up for: Compromising real-world llm-integrated applications with indirect prompt injec- tion. In Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security, pages 79â90, 2023. [13]Daniel Gruss, Michael Schwarz, Matthias WĂźbbeling, Simon Guggi, Timo Malderle, Stefan More, and Moritz Lipp. Use-after-freemail: Generalizing the use-after-free problem and applying it to email services. In Proceed- ings of the 2018 on Asia Conference on Computer and Communications Security, pages 297â311, 2018. [14]Yacong Gu, Lingyun Ying, Yingyuan Pu, Xiao Hu, Hua- jun Chai, Ruimin Wang, Xing Gao, and Haixin Duan. Investigating package related security threats in soft- ware registries. In 2023 IEEE Symposium on Security and Privacy (SP), pages 1578â1595. IEEE, 2023. [15] Yangsibo Huang, Samyak Gupta, Mengzhou Xia, Kai Li, and Danqi Chen. Catastrophic jailbreak of open- source llms via exploiting generation. arXiv preprint arXiv:2310.06987, 2023. [16]Invariantlabs.Mcp security notification: Tool poi- soning attacks.https://invariantlabs.ai/blog/ mcp-security-notification-tool-poisoning-attacks , 2025. [17]Invariantlabs.Whatsappmcpexploited: Exfiltratingyourmessagehistoryvia mcp.https://invariantlabs.ai/blog/ whatsapp-mcp-exploited, 2025. [18] Nikhil Kandpal, Matthew Jagielski, Florian Tramèr, and Nicholas Carlini. Backdoor attacks for in-context learning with language models.arXiv preprint arXiv:2307.14692, 2023. 14 [19]Mohammad Taha Khan, Xiang Huo, Zhou Li, and Chris Kanich. Every second counts: Quantifying the negative externalities of cybercrime via typosquatting. In 2015 IEEE Symposium on Security and Privacy, pages 135â 150. IEEE, 2015. [20] Panagiotis Kintis, Najmeh Miramirkhani, Charles Lever, Yizheng Chen, Rosa Romero-GĂłmez, Nikolaos Pitropakis, Nick Nikiforakis, and Manos Antonakakis. Hiding in plain sight: A longitudinal study of com- bosquatting abuse. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, pages 569â586, 2017. [21]Haoran Li, Dadi Guo, Wei Fan, Mingshi Xu, Jie Huang, Fanpu Meng, and Yangqiu Song.Multi-step jail- breaking privacy attacks on chatgpt. arXiv preprint arXiv:2304.05197, 2023. [22]Xiaofan Li, Yacong Gu, Chu Qiao, Zhenkai Zhang, Daip- ing Liu, Lingyun Ying, Haixin Duan, and Xing Gao. To- ward understanding the security of plugins in continuous integration services. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, pages 482â496, 2024. [23] Song Liao, Long Cheng, Xiapu Luo, Zheng Song, Haipeng Cai, Danfeng Yao, and Hongxin Hu. A first look at security and privacy risks in the rapidapi ecosys- tem. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, pages 1626â1640, 2024. [24]Guannan Liu, Xing Gao, Haining Wang, and Kun Sun. Exploring the unchartered space of container registry typosquatting. In 31st USENIX Security Symposium (USENIX Security 22), pages 35â51, 2022. [25]Tong Liu, Zizhuang Deng, Guozhu Meng, Yuekang Li, and Kai Chen. Demystifying rce vulnerabilities in llm-integrated apps. arxiv 2023.arXiv preprint arXiv:2309.02926, 2023. [26]Yi Liu, Gelei Deng, Yuekang Li, Kailong Wang, Zihao Wang, Xiaofeng Wang, Tianwei Zhang, Yepang Liu, Haoyu Wang, Yan Zheng, et al. Prompt injection at- tack against llm-integrated applications. arXiv preprint arXiv:2306.05499, 2023. [27] Yupei Liu, Yuqi Jia, Runpeng Geng, Jinyuan Jia, and Neil Zhenqiang Gong. Formalizing and benchmarking prompt injection attacks and defenses. In 33rd USENIX Security Symposium (USENIX Security 24), pages 1831â 1847, 2024. [28]mastra. The mcp registry registry.https://mastra. ai/mcp-registry-registry, 2025. [29]MCP Market. Discover top mcp servers | mcp market. https://mcpmarket.com/, 2025. [30] MCP Store. Mcp store - find and connect to 20,000+ mcp servers. https://mcpstore.co/, 2025. [31] mcp.so. Mcp servers. https://mcp.so/, 2025. [32]Microsoft.Model context protocol (mcp) is nowgenerallyavailableinmicrosoft copilot studio.https://w.microsoft.com/en-us/ microsoft-copilot/blog/copilot-studio/ model-context-protocol-mcp-is-now-generally-available-in-microsoft-copilot-studio/ , 2025. [33] Tyler Moore and Benjamin Edelman. Measuring the perpetrators and funders of typosquatting. In Interna- tional Conference on Financial Cryptography and Data Security, pages 175â191. Springer, 2010. [34]Nick Nikiforakis, Marco Balduzzi, Lieven Desmet, Frank Piessens, and Wouter Joosen. Soundsquatting: Uncovering the use of homophones in domain squatting. In International Conference on Information Security, pages 291â308. Springer, 2014. [35]Nick Nikiforakis, Steven Van Acker, Wannes Meert, Lieven Desmet, Frank Piessens, and Wouter Joosen. Bit- squatting: Exploiting bit-flips for fun, or profit? In Pro- ceedings of the 22nd international conference on World Wide Web, pages 989â998, 2013. [36]Liang-bo Ning, Shijie Wang, Wenqi Fan, Qing Li, Xin Xu, Hao Chen, and Feiran Huang. Cheatagent: Attack- ing llm-empowered recommender systems via llm agent. In Proceedings of the 30th ACM SIGKDD Conference on Knowledge Discovery and Data Mining, pages 2284â 2295, 2024. [37]Rodrigo Pedro, Miguel E Coimbra, Daniel Castro, Paulo Carreira, and Nuno Santos. Prompt-to-sql injections in llm-integrated web applications: Risks and defenses. In 2025 IEEE/ACM 47th International Conference on Soft- ware Engineering (ICSE), pages 76â88. IEEE Computer Society, 2024. [38]Pulse MCP. Pulsemcp | keep up-to-date with mcp. https://w.pulsemcp.com/, 2025. [39]Roei Schuster, Congzheng Song, Eran Tromer, and Vi- taly Shmatikov. You autocomplete me: Poisoning vul- nerabilities in neural code completion. In 30th USENIX Security Symposium (USENIX Security 21), pages 1559â 1575, 2021. [40]Erfan Shayegani, Md Abdullah Al Mamun, Yu Fu, Pe- dram Zaree, Yue Dong, and Nael Abu-Ghazaleh. Survey of vulnerabilities in large language models revealed by 15 adversarial attacks. arXiv preprint arXiv:2310.10844, 2023. [41] Xinyue Shen, Zeyuan Chen, Michael Backes, Yun Shen, and Yang Zhang. " do anything now": Characterizing and evaluating in-the-wild jailbreak prompts on large language models. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, pages 1671â1685, 2024. [42] Smithery. Smithery - model context protocol registry. https://smithery.ai/, 2025. [43] Janos Szurdi, Balazs Kocso, Gabor Cseh, Jonathan Spring, Mark Felegyhazi, and Chris Kanich. The long âTaileâof typosquatting domain names. In 23rd USENIX Security Symposium (USENIX Security 14), pages 191â206, 2014. [44] TechCrunch.Google to embrace anthropicâs standard for connectingaimodelstodata. https://techcrunch.com/2025/04/09/ google-says-itll-embrace-anthropics-standard-for-connecting-ai-models-to-data/, 2025. [45]TechCrunch.Openai adopts rival anthropicâs standard for connectingaimodelstodata. https://techcrunch.com/2025/03/26/ openai-adopts-rival-anthropics-standard-for-connecting-ai-models-to-data/, 2025. [46]Nikolai Philipp Tschacher. Typosquatting in program- ming language package managers. PhD thesis, Univer- sität Hamburg, Fachbereich Informatik, 2016. [47]Duc-Ly Vu, Ivan Pashchenko, Fabio Massacci, Henrik Plate, and Antonino Sabetta. Typosquatting and com- bosquatting attacks on the python ecosystem. In 2020 ieee european symposium on security and privacy work- shops (euros&pw), pages 509â514. IEEE, 2020. [48]Jiongxiao Wang, Zichen Liu, Keun Hee Park, Zhuo- jun Jiang, Zhaoheng Zheng, Zhuofeng Wu, Muhao Chen, and Chaowei Xiao. Adversarial demonstration attacks on large language models.arXiv preprint arXiv:2305.14950, 2023. [49]Alexander Wei, Nika Haghtalab, and Jacob Steinhardt. Jailbroken: How does llm safety training fail? Advances in Neural Information Processing Systems, 36, 2024. [50]Fangzhou Wu, Xiaogeng Liu, and Chaowei Xiao. De- ceptprompt: Exploiting llm-driven code generation via adversarial natural language instructions. arXiv preprint arXiv:2312.04730, 2023. [51]Guanlong Wu, Zheng Zhang, Yao Zhang, Weili Wang, Jianyu Niu, Ye Wu, and Yinqian Zhang. I know what you asked: Prompt leakage via kv-cache sharing in multi- tenant llm serving. In Proceedings of the 2025 Network and Distributed System Security (NDSS) Symposium. San Diego, CA, USA, 2025. [52] Jun Yan, Vikas Yadav, Shiyang Li, Lichang Chen, Zheng Tang, Hai Wang, Vijay Srinivasan, Xiang Ren, and Hongxia Jin. Backdooring instruction-tuned large lan- guage models with virtual prompt injection. arXiv preprint arXiv:2307.16888, 2023. [53] Shenao Yan, Shen Wang, Yue Duan, Hanbin Hong, Kiho Lee, Doowon Kim, and Yuan Hong. An llm- assisted easy-to-trigger backdoor attack on code comple- tion models: Injecting disguised vulnerabilities against strong detection. arXiv preprint arXiv:2406.06822, 2024. [54]Nusrat Zahan, Thomas Zimmermann, Patrice Gode- froid, Brendan Murphy, Chandra Maddila, and Laurie Williams. What are weak links in the npm supply chain? In Proceedings of the 44th International Conference on Software Engineering: Software Engineering in Prac- tice, pages 331â340, 2022. [55]Quan Zhang, Yifeng Ding, Yongqiang Tian, Jianmin Guo, Min Yuan, and Yu Jiang. Advdoor: adversarial backdoor attack of deep learning system. In Proceedings of the 30th ACM SIGSOFT International Symposium on Software Testing and Analysis, pages 127â138, 2021. [56]Quan Zhang, Binqi Zeng, Chijin Zhou, Gwihwan Go, Heyuan Shi, and Yu Jiang. Human-imperceptible re- trieval poisoning attacks in llm-powered applications. In Companion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering, pages 502â506, 2024. [57]Quan Zhang, Chijin Zhou, Gwihwan Go, Binqi Zeng, Heyuan Shi, Zichen Xu, and Yu Jiang. Imperceptible content poisoning in llm-powered applications. In Pro- ceedings of the 39th IEEE/ACM International Confer- ence on Automated Software Engineering, pages 242â 254, 2024. [58]Xinyu Zhang, Huiyu Xu, Zhongjie Ba, Zhibo Wang, Yuan Hong, Jian Liu, Zhan Qin, and Kui Ren. Priva- cyasst: Safeguarding user privacy in tool-using large language model agents. IEEE Transactions on Depend- able and Secure Computing, 21(6):5242â5258, 2024. [59] Markus Zimmermann, Cristian-Alexandru Staicu, Cam Tenny, and Michael Pradel. Small world with high risks: A study of security threats in the npm ecosystem. In 28th USENIX Security symposium (USENIX security 19), pages 995â1010, 2019. 16 [60]Andy Zou, Zifan Wang, Nicholas Carlini, Milad Nasr, J Zico Kolter, and Matt Fredrikson. Universal and trans- ferable adversarial attacks on aligned language models. arXiv preprint arXiv:2307.15043, 2023. 17