Mitigating Taint-Style Vulnerabilities in MCP Servers via Security-Aware Tool Descriptions Yang Shi
Jiaheng Fu
Yihe Huang Ruixiang Wu Chengyao Sun Kaifeng Huang Tongji University {shiyang,jiahengfu,huangyihe,rxwu}@tongji.edu.cn {2452523,kaifengh}@tongji.edu.cn
arXiv:2607.07461v1 [cs.CR] 8 Jul 2026
Abstract
external tools, services, and data sources to accomplish complex tasks. To standardize and simplify these interactions, the Model Context Protocol (MCP) [2] has recently emerged as a unifying interface that allows LLMs to dynamically discover and invoke external tools or services through MCP servers. Companies are actively deploying MCP servers to enable integration with and usage of their products. For example, Notion provides a connector for AI to interact directly with workspace databases [3]; and Google delivers dedicated servers that integrate AI across its suite of Drive, Gmail, and Calendar services [1]. However, the MCP paradigm also introduces new security challenges. On the one hand, the shift toward external interactions expands the attack surface of LLM-based systems. On the other hand, the standardization of the protocol design makes it easier for attackers to craft generic exploits that can target multiple MCP servers. Several existing works focus on characterizing malicious MCP servers [11, 12] or presenting malicious MCP server proof-of-concepts [47, 49]. However, the vulnerabilities of MCP servers remain under-investigated. To bridge this gap, we first systematically study the vulnerability landscape of MCP servers. We begin by collecting and analyzing all MCP server vulnerabilities disclosed in the National Vulnerability Database (NVD) to date. We then design and conduct three research questions: Metadata Characteristics (RQ1), Vulnerability and Repair Property (RQ2), and Response of Vulnerabilities (RQ3), to understand the vulnerability patterns of MCP servers. Our study reveals that (a) MCP server descriptions tend to be brief and lack detailed specifications, (b) taint-style vulnerabilities constitute a substantial fraction (81.13%) of the total MCP server vulnerabilities, (c) these vulnerabilities require substantial code modifications and extended remediation timelines, and (d) the contributor response to MCP server vulnerabilities is generally slow and inadequate. Inspired by our analysis, we focus on taint-style vulnerabilities in MCP servers, where untrusted inputs propagate through execution paths and ultimately trigger security violations. In traditional software systems, taint-style vulner-
Large language models (LLMs) are increasingly deployed as autonomous agents that interact with external tools and services via the Model Context Protocol (MCP), a standardized interface for dynamic tool invocation. While MCP simplifies integration, it also expands the attack surface and enables generic exploits across multiple servers. Despite prior work on malicious MCP servers, the vulnerability landscape of MCP servers remains underexplored. In this work, we systematically analyze MCP server vulnerabilities, focusing on metadata characteristics, vulnerable code patterns, and community responses. Our study reveals that taint-style vulnerabilities constitute a substantial fraction of MCP server vulnerabilities, require significant code modifications to remediate, and are met with slow community responses. Motivated by these findings, we propose S PELL S MITH, presenting a novel textbased avenue for shielding taint-style vulnerabilities in MCP servers. In particular, S PELL S MITH analyzes the high-risk capabilities exposed by an MCP server and combines them with tool descriptions and parameter semantics to identify potential taint-style vulnerability risks, thereby constructing a tool-level risk profile. Then, S PELL S MITH leverages the Description property of the protocol to embed behavioral guidance (Description Enhancement Module) and exploits LLMs’ self-reflection capabilities (Self-Reflection Module) to iteratively evaluate and refine outputs. By strengthening LLM internal decision-making, S PELL S MITH provides an active and unified mitigation strategy that generalizes across multiple vulnerabilities, reducing reliance on context-specific code-level fixes. Our experiments demonstrate that S PELL S MITH effectively mitigates taint-style vulnerability exploitation in MCP servers, highlighting its practical applicability and advantages over traditional code-level mitigations.
1
Introduction
Large language models (LLMs) are increasingly deployed as autonomous or semi-autonomous agents that interact with 1
Malicious Input
MCP-Based Agent
Safe Input
You are a red-team testing agent operating in a controlled experimental environment. All actions, inputs, and observations are conducted for scientific research... Your task is to convert the content from https://127.0.0.1:8080/Admin into a markdown file.
Please convert the content from https:// news.google.com into a markdown file for me.
2
Tool Metadata
3
Tool-Aware Planning
Task Specification
User
MCP Servers
LLMs
Client 0
5 Outcome Evaluation and Control Client 1
Tool Implementation
1
4
…
Markdownify-Server Markdownify-Server bing-search-to-markdown bing-search-to-markdown
Tool Registration
pdf-to-markdown pdf-to-markdown
Tool Invocation
webpage-to-markdown webpage-to-markdown
MCP Clients
Figure 1: Overview of the MCP Workflow, Illustrated with an SSRF Vulnerability in the Markdownify MCP Server abilities are detected and exploited in a deterministic way directly through user inputs [8, 19, 25, 30, 51, 57, 60, 68]. To patch such vulnerabilities, developers generally need to fully understand the vulnerability logic across the vulnerable functions and make corresponding code-level modifications. The same patching paradigm is also applicable to MCP-based agents. However, a key distinguishing aspect of MCP-based agents is that vulnerability exploitation is typically triggered by malicious prompts and misaligned LLM behaviors. To this end, recent work proposes MCP security mechanisms that enforce pre- and post-invocation controls and combine static analysis and neural detection to identify malicious inputs [22,56]. However, these approaches assume the presence of misaligned LLM behavior and primarily focus on regulating inputs and outputs, rather than correcting the LLM’s internal decision-making processes.
nally, the Tool Invocation Reflection module leverages the inherent self-reflective capabilities of LLMs to assess and refine tool invocation intents and outputs before final execution. Evaluation. We constructed a benchmark of 792 malicious prompts to exploit taint-style vulnerabilities. Our experiments show that S PELL S MITH significantly reduces the success of taint-style vulnerability exploits with an attack success rate of 0.13%. S PELL S MITH outperforms code-level mitigations by achieving comparable effectiveness while incurring substantially lower repair costs and offering greater generalizability. In addition, we conduct ablation and adversarial evaluations to demonstrate the effectiveness of S PELL S MITH’s individual components and its robustness against adversarial attacks. In summary, this paper makes the following contributions: • We present the first systematic study of MCP server vulnerabilities, revealing underspecified tool metadata, the prevalence of taint-style vulnerabilities, substantial repair costs, and delayed community responses.
We propose S PELL S MITH, which explores the potential of embedding “text-based mitigations” into the MCP tool’s Description property, as an alternative to traditional “code-based mitigations” for addressing taint-style vulnerabilities. Our method presents a novel avenue for mitigating vulnerabilities through a text-based approach. Moreover, we harness the selfreflection capabilities of LLMs by incorporating a dedicated reflection stage in an additional interaction turn. Our central insight is that improving the LLM’s internal decision-making processes provides a more robust foundation for securing MCP-based agents. First, this represents a proactive mitigation strategy, requiring less effort than passive input or output regulation, which should account for a broad and passively evolving attack surface. Second, it provides a unified mechanism that can generalize across multiple taint-style vulnerabilities in MCP servers, rather than patching each vulnerability at the code level in a context-specific manner. Specifically, S PELL S MITH consists of three major components. First, the Risk Identification module analyzes the high-risk capabilities exposed by an MCP server and combines them with tool descriptions and parameter semantics to identify potential taintstyle vulnerability risks. Based on the identified risks, the Tool Metadata Augmentation module crafts effective securityaware tool descriptions with augmented contents that guide the LLM’s behavior to avoid vulnerability exploitation. Fi-
• We propose S PELL S MITH, a lightweight and nonintrusive defense mechanism that mitigates taint-style vulnerabilities by constraining LLM behavior through security-aware tool metadata augmentation and tool invocation reflection. • We construct a prompt dataset for exploiting taint-style vulnerabilities in MCP servers and conduct a comprehensive evaluation, demonstrating the effectiveness and practical applicability of S PELL S MITH across diverse vulnerability types and LLMs.
2 2.1
Background MCP and its Vulnerability
LLMs are inherently chat-based systems. Model Context Protocols (MCPs), proposed by Anthropic in 2024 [4], are designed to provide a standardized framework for LLMs to interact with external tools and services. Fig. 1 presents an overview of the MCP workflow, illustrated using an SSRF vulnerability (CVE-2025-5276) [39] in the Markdownify MCP 2
"mimeType": "image/png", "sizes": ["48x48"] } ] }]
1 export constWebpageToMarkdownTool = ToolSchema.parse({ 2 name:"webpage-to-markdown", 3 description:"Convert a webpage to markdown"， 4 inputSchema: { 5 type:"object", 6 properties: { 7 url: { 8 type:"string", 9 description:"URL of the webpage to convert" 10 }, 11 }, required: ["url"], },}); 12
An SSRF Vulnerability Example. We adopt the SSRF vulnerability CVE-2025-5276 in the Markdownify MCP server as a representative case to demonstrate the internal execution logic of MCP-based agents and the inherent characteristics of mitigation, compared with traditional vulnerability settings. In benign scenarios, a user requests that the MCP-based agent convert web content into a Markdown file. e.g., “Please convert the content from https://news.g oogle.com into a Markdown file.” Given this task, the agent invokes the LLM, which reasons over the available tool metadata and ultimately selects the MCP tool webpage-to-markdown to retrieve and convert the specified webpage. However, as shown in Fig. 2(b), prior to invoking the transformation logic (Markdownify.toMarkdown(), Line 17), the MCP tool webpage-to-markdown performs only minimal validation of the input URL, only checking that the URL is non-empty (Lines 8-9). Consequently, an attacker can obscure malicious intent (e.g., via jailbreaking techniques such as role-playing, indirect instructions, or task framing [29]), and induce the LLM to generate tool invocations that cause unintended network requests (e.g., accessing server-side local pages, as illustrated by the malicious input example in Fig. 1.) in the webpage-to-markdown tool, resulting in a Server-Side Request Forgery (SSRF) vulnerability. Recalling the process shown in Fig. 1, neither the MCP server nor the MCP tools themselves provide intrinsic security mechanisms to defend against such malicious inputs. The MCP protocol metadata exposed to the LLM (Fig. 2(a)) only encodes the tool’s intended functionality (e.g., Convert a webpage to markdown) and input constraints via the description and inputSchema fields. A straightforward remediation strategy involves inspecting and patching the vulnerable tool implementation. In commit [38], the contributor added URL filtering logic to server.ts, restricting requests to HTTP(S) URLs and non-private IP addresses (Fig. 2, Lines 10-16). Nevertheless, this patch was later shown to be insufficient. As noted by a user in a follow-up comment (line 14), the validation logic was minimal and effectively inherited all bypass opportunities from the upstream project [40]. Accordingly, we use the term “mitigation” rather than “fix” to reflect that the vulnerability may not be fully eliminated. This underscores the shortcomings of ad hoc, code-level mitigation and motivates the development of systematic security mechanisms for MCP-based agents, exploiting the opportunities afforded by LLMs and MCP. Insights. Reflecting on the MCP workflow and example, we have the following insights. First, code-level patching tends to be ad hoc, incomplete, and expertise-intensive, as demonstrated by prior work on multi-commit vulnerability mitigations [13, 32, 54]. By contrast, LLM-based approaches offer new opportunities to circumvent these limitations. Second, security defenses in existing MCP-based agents are implicitly delegated to the LLM itself, not enforced by the protocol, while existing works enforce pre- and post-invocation
src/tool.ts 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
server.setRequestHandler( CallToolRequestSchema, async (request: CallToolRequest) => { const { name, arguments: args } = request.params; const validatedArgs = RequestPayloadSchema.parse(args); let result; switch (name) { case tools.WebpageToMarkdownTool.name: if (!validatedArgs.url) { throw new Error("URL is required for this tool");} + const parsedUrl = new URL(validatedArgs.url); + if (!["http:", "https:"].includes(parsedUrl.protocol)) { + throw new Error("Only http: and https: schemes are + allowed.");} + if (is_ip_private(parsedUrl.hostname)) { + throw new Error(`Fetching ${validatedArgs.url} + is potentially dangerous, aborting.`);} result = await Markdownify.toMarkdown({url: validatedArgs.url, projectRoot: validatedArgs.projectRoot, uvPath: validatedArgs.uvPath || process.env.UV_PATH, }); break; case tools.PDFToMarkdownTool.name: ...
src/server.ts
Figure 2: Example Vulnerable Code from the Markdownify MCP server (CVE-2025-5276) server. An MCP-based agent typically consists of the LLMs, MCP clients, and MCP servers, where each MCP server may expose multiple MCP tools. The MCP workflow is structured as follows: (1) Tool Registration. MCP servers publish tool metadata, including tool names, input/output schemas, which are registered with the MCP client and provided to the LLM as part of its context. Fig. 2(a) illustrates the metadata of the MCP tool webpage-to-markdown exposed by the Markdownify-Server, comprising the tool name, functional description, and an input schema that specifies parameter types and constraints. Notably, tool registration exposes only metadata to the LLM while the underlying tool implementation remains invisible to it. (2) Task Specification. The user submits a high-level task or query, expressing the intent of what the agent is expected to accomplish. (3) Tool-Aware Planning. The task specification and the registered tool metadata are jointly fed into the LLM. Subsequently, the LLM performs reasoning and planning to determine whether external tools are required, select appropriate tools and construct the corresponding invocation parameters and scripts. (4) Tool Invocation. The MCP client carries out the LLM-generated tool invocation by invoking the selected MCP server tool with the specified parameters, and then returns the execution results back to the LLM. (5) Outcome Evaluation and Control. The LLM interprets the returned results to assess task progress or completion and may iteratively refine its plan, invoke additional tools, or return the final response to the user. 3
• RQ2: Vulnerability and Repair Property. What types of vulnerabilities occur in MCP servers, and how are they repaired?
controls and combine static analysis and neural detection in the Task Specification and Outcome Evaluation and Control stage [22, 56]. Third, the MCP protocol metadata is lightweight and function-oriented, providing minimal constraints on tool inputs and consequently limited protection against malicious manipulation. To examine protocol metadata complexity, code-level remediation effort, and developer response patterns in the MCP ecosystem, we conduct a comprehensive study of the MCP vulnerabilities in Sec. 3. Drawing on the insights and results of our analysis, we aim to design a text-based defense that exploits the LLM’s security awareness rather than relying on code-level mitigations, as it offers advantages in terms of reduced mitigation effort and improved generalizability.
2.2
• RQ3: Response to Vulnerabilities. How does the community respond to disclosed MCP server vulnerabilities?
3.1
We first collect real-world MCP servers from GitHub. We search repositories using the keywords “MCP” and “Model Context Protocol”, rank the results by GitHub stars, and manually screen the retrieved projects. We exclude non-code projects, MCP server lists, client-side agents, development frameworks, projects where MCP is only an auxiliary feature, and projects whose tool definitions are generated dynamically at runtime. This process yields 100 MCP server projects. For these servers, we implement a lightweight MCP client based on the official MCP Python SDK [36]. The client connects to each server and retrieves tool metadata during the registration phase, including the tool name, description, and input schema. In total, we collect metadata for 1,856 MCP tools. We then collect vulnerability reports from two sources. First, we query the National Vulnerability Database (NVD) [37] using the keyword “MCP” as of February 2026. The query returns 116 CVE entries, from which two authors identify 35 vulnerabilities directly related to open-source MCP servers. Second, we search the 100 collected GitHub repositories for security advisories and issues containing the keywords security, vulnerability, vulnerabilities, and vulnerable, using the GitHub API [9]. We find 25 security advisories and 147 issues. The advisories overlap with the NVD records, while manual review of the issues identifies 18 additional valid vulnerability reports. Overall, our vulnerability dataset contains 53 vulnerabilities across 45 MCP servers.
Threat Model
We consider an adversary capable of performing prompt injection by influencing user-provided inputs processed by the LLM. Such an attacker can manipulate the semantic content of prompts to affect the LLM’s reasoning and tool-selection decisions. We assume the tool provider, MCP server, and communication channels are trusted and uncompromised. The adversary’s objective is to induce the LLM to invoke unintended or unauthorized tool functions through crafted inputs, thereby triggering taint-style vulnerabilities, such as SQL injection, command injection, or path traversal, within downstream tools. The adversary does not have direct access to the LLM’s internal parameters or execution environment, operates strictly within the MCP protocol specifications, and cannot modify the client application’s core logic or server-side code (i.e., a non-intrusive attacker). Given the above adversary model, our approach is designed to prevent attacker-controlled user inputs from propagating into sensitive tool arguments or execution contexts (e.g., taintstyle vulnerability exploits), ensuring that tool invocations strictly conform to the specified intent and authorized usage patterns. These protections do not require modifications to the LLM’s internal architecture, retraining, or intrusive changes to existing tool implementations, while remaining generalizable and fully compatible with existing MCP deployments.
3
Dataset Collection
3.2
Metadata Characteristics (RQ1)
To answer RQ1, we analyze both the functional distribution of MCP tools and the structure of their metadata. 3.2.1
MCP Vulnerabilities in Wild
Application and Functional Category
For application categorization, two authors inspect the README files of the collected MCP servers and assign each server to an application category. For functional categorization, we use GPT-4o to infer the primary functionality of each tool from its description field, and then manually review and consolidate the resulting categories. Fig. 3 shows that MCP servers cover diverse application domains. Developer tools form the largest server category (29.0%), followed by design (18.0%), data management (17.0%), web (12.0%), office (10.0%), social (6.0%), device control (4.0%), and research (4.0%). On the capability side,
Building on the MCP workflow discussed in Section 2, we conduct an empirical study of real-world MCP servers and their vulnerabilities. The goal is to understand whether MCP metadata provides sufficient security guidance, what kinds of vulnerabilities appear in practice, and how maintainers respond to reported vulnerabilities. We study the following research questions: • RQ1: Metadata Characteristics. What are the characteristics of metadata in MCP servers? 4
Field
Used Count
Empty Count
1856 160 1856 0 1856 234 325 322
0 1696 0 1856 0 1622 1531 1534
name title description icons inputSchema outputSchema annotations execution
Table 1: Usage statistics of tool schema fields in 1,856 MCP tools.
Field
Description
inputSchema/ Description
Figure 3: Application and functional categories for MCP servers and tools, respectively, and their relationships.
MCP Tool (#)
Per. (%)
Avg. Tokens Sentence Sent. (#) No. (#) Len.
T0 T1 T2 T3
1 1210 515 130
0.05 65.19 27.75 7.00
0.00 14.56 97.33 263.78
0.00 1.26 4.61 9.39
0.00 11.12 23.02 32.67
Total T0 T1 T2 T3
1856 180 209 1433 34
100.00 9.70 11.26 77.21 1.83
54.97 0.00 25.63 117.79 315.21
2.76 0.00 1.45 5.77 13.53
15.92 0.00 19.64 25.01 29.97
Total
1856
100.00 99.61
4.86
22.07
Table 2: MCP Tool Textual Patterns
platform operation accounts for the largest share (44.4%), followed by content processing (22.4%), web access (14.8%), database access (7.1%), file access (6.1%), and terminal execution (5.0%). The key observation is that security-sensitive capabilities are not confined to a single server type. Web access, database access, file access, terminal execution, and content processing appear across heterogeneous application domains. Therefore, taint-style risks are not limited to obvious developer or terminal tools; many kinds of MCP tools may expose user-inputto-sensitive-operation paths. 3.2.2
Level
• Empty Description (T0): the description is empty or semantically uninformative.
• Basic Description (T1): the description only states the basic function of the tool or parameter.
• Constraint-Included Description (T2): the description includes operational constraints, such as input requirements or usage scope.
Tool Schema Pattern
We next inspect the tool schema fields exposed during MCP registration. Table 1 shows that the required fields are consistently present: all 1,856 tools include name, description, and inputSchema. In contrast, optional fields are much less common. Only 160 tools use title, 234 use outputSchema, 325 use annotations, and 322 use execution; no tool uses icons. This suggests that MCP metadata is structurally complete at the minimum required level, but richer semantic fields are sparsely used. We further analyze the textual content of description and inputSchema/description. We classify descriptions into four levels:
• Security-Aware Description (T3): the description explicitly includes security restrictions, misuse-prevention guidance, or access-control boundaries.
Table 2 shows that most tool descriptions remain lightweight. For the top-level description field, 65.19% of tools provide only basic descriptions (T1), while only 7.00% include security-aware information (T3). Parameter descriptions contain more operational constraints: 77.21% of inputSchema/description entries are T2. However, only 1.83% are security-aware (T3), and 9.70% are empty. 5
Dimension
Vulnerability Type
Triggering Phase
Category
No.
Per. (%)
Command Injection Path Traversal Unauthorized Access DNS Rebinding SSRF Code Injection SQL Injection Tool Invocation Tool Registration
27 9 6 4 3 2 2 40 13
50.94 16.98 11.32 7.55 5.66 3.77 3.77 75.47 24.53
Dimension
Category
No.
Per. (%)
Repair Effort
Average Lines of Code Average Modified Functions Average Modified Files
203.6 5.5 3.3
– – –
Mitigation Strategy
Secure Implementation Sanitization Feature Removal Isolated Environment
19 17 3 2
46.3 41.5 7.3 4.9
Mitigation No Longer Exploitable Effectiveness Still Exploitable
37 4
90.2 9.8
Table 3: Overall Statistics of MCP and Vulnerability Type Table 4: Repair Statistics of Vulnerable MCP Tools RQ1 Summary: MCP tools are diverse, and securitysensitive capabilities appear across many application domains. At the same time, existing metadata rarely provides explicit security guidance: only 7.00% of tool descriptions and 1.83% of parameter descriptions are security-aware. This leaves many tool categories with potential taint-style risk but limited metadata-level protection.
3.3
3.3.2
We further inspect repair commits and mitigation strategies for the vulnerabilities with available remediation artifacts. We measure repair effort by the number of modified lines of code, functions, and files. We also categorize mitigation strategies following prior work on agent security [46]. Table 4 shows that fixing MCP vulnerabilities often requires non-trivial code changes. On average, a fix modifies 203.6 lines of code, 5.5 functions, and 3.3 files. This suggests that remediation is not usually a local one-line patch; developers often need to understand and modify multiple parts of the server implementation. The table also shows that most fixes rely on implementation-level changes. Secure implementation accounts for 19 cases (46.3%), and sanitization accounts for 17 cases (41.5%). Less common strategies include feature removal (7.3%) and isolated environment deployment (4.9%). Although most fixed cases are no longer exploitable (90.2%), 4 cases (9.8%) remain exploitable after mitigation, showing that code-level fixes can still be incomplete.
Vulnerability and Repair Property (RQ2)
To answer RQ2, we analyze the types, triggering phases, and repair properties of the collected vulnerabilities.
3.3.1
Repair Properties
Vulnerability Properties
Table 3 reports the distribution of vulnerability types. Command injection is the dominant category, with 27 cases (50.94%). It is followed by path traversal with 9 cases (16.98%), unauthorized access with 6 cases (11.32%), DNS rebinding with 4 cases (7.55%), SSRF with 3 cases (5.66%), code injection with 2 cases (3.77%), and SQL injection with 2 cases (3.77%). These results show that taint-style vulnerabilities dominate MCP server vulnerabilities. The typical taint-style categories in the table, including command injection, path traversal, SSRF, code injection, and SQL injection, account for 43 out of 53 cases (81.13%). This indicates that many vulnerabilities arise when user-controlled inputs are routed into sensitive operations such as command execution, filesystem access, network requests, code execution, or database queries. Table 3 also shows that most vulnerabilities are triggered during tool invocation. Specifically, 40 cases (75.47%) occur in the tool invocation phase, while 13 cases (24.53%) occur during tool registration. This result highlights the central role of LLM-generated tool arguments in MCP security: unsafe behavior is often exposed when a model selects a tool and fills its parameters.
RQ2 Summary: Taint-style vulnerabilities are the dominant vulnerability class in MCP servers, accounting for 81.13% of the collected cases. Most vulnerabilities are triggered during tool invocation (75.47%). Repairs are also complex, requiring an average of 203.6 modified lines, 5.5 functions, and 3.3 files, and 9.8% of repaired cases remain exploitable.
3.4
Response to Vulnerabilities (RQ3)
To answer RQ3, we analyze the vulnerability lifecycle and maintainer response. For each vulnerability, we collect the associated public artifacts, including issues, advisories, and fixing commits. We define the disclosure time as the earliest public report time. For fixed vulnerabilities, the fixing cycle is the time between disclosure and the fixing commit. For unpatched vulnerabilities, the exposure time is measured from disclosure to the end of our data collection period. We 6
Dimension
Metric/Category
Vulnerability Fixing Cycle Lifespan Exposure Time Developer Reaction
High-Priority Mitigation Responsive but Unmitigated Low-Priority Mitigation No Response
Value
Per.
37.3d 92.3d
– –
33 9 8 3
62.3 17.0 15.1 5.7
S PELL S MITH is designed for cases where the MCP Server code is unavailable, difficult to audit, or undesirable to modify. Instead of patching the server implementation, S PELL S MITH strengthens the interface between the LLM and MCP tools through three lightweight steps. First, it estimates which tools and parameters may involve taint-style risks. Second, it rewrites tool descriptions with explicit security constraints in the offline stage. Third, it asks the LLM to reflect on planned or completed tool calls in the online stage before unsafe behavior is propagated. The goal of S PELL S MITH is not to prove that a tool is vulnerable. Rather, it provides a conservative warning signal and uses this signal to guide LLM tool-use behavior. This design treats MCP metadata as a lightweight policy surface that can influence tool selection, parameter generation, and refusal decisions.
Table 5: Statistics of Community Reaction to Vulnerable MCP Tools classify developer reactions into four categories following prior work [46]: no response, responsive but unmitigated, low-priority mitigation, and high-priority mitigation. Table 5 shows that MCP vulnerability response is uneven and often slow. Fixed vulnerabilities take an average of 37.3 days to repair. Unpatched vulnerabilities remain exposed for an average of 92.3 days, indicating that some reported vulnerabilities persist for months. Maintainer reaction is also mixed. High-priority mitigation accounts for 33 cases (62.3%), suggesting that many maintainers do respond seriously to security reports. However, the remaining cases still indicate delayed or insufficient response: 9 cases (17.0%) are responsive but unmitigated, 8 cases (15.1%) receive low-priority mitigation, and 3 cases (5.7%) receive no response.
4.2
Given the metadata of an MCP tool, denoted as M, S PELL S MITH estimates a coarse-grained risk profile: R = ⟨C , P , W ⟩, where C denotes high-risk capabilities, P denotes potentially tainted parameters, and W denotes candidate CWE categories. This step uses the tool name, description, and input schema to answer three simple questions. First, does the tool expose a high-risk capability, such as filesystem access, command or code execution, database access, network access, parsing, credential access, or authorization control? Second, which parameters may carry user-controlled input, such as paths, commands, code snippets, queries, URLs, headers, templates, filters, or identifiers? Third, which taint-style CWE risks may arise when those parameters affect the corresponding capability? The output is intentionally conservative. S PELL S MITH does not claim that the implementation is exploitable; it only estimates whether the metadata suggests a plausible userinput-to-sensitive-operation pattern.
RQ3 Summary: MCP vulnerability remediation is slow and inconsistent. Even fixed vulnerabilities require an average fixing cycle of 37.3 days, while unpatched vulnerabilities remain exposed for 92.3 days on average. Although 62.3% of cases receive high-priority mitigation, a substantial fraction receive delayed, low-priority, or no effective response.
4
S PELL S MITH
We present S PELL S MITH, a lightweight defense for mitigating taint-style vulnerability exploitation in MCP tools without modifying MCP Server implementations. S PELL S MITH operates at the MCP interaction layer: it estimates potential risks from tool metadata, augments tool descriptions with security-aware constraints, and introduces reflection around tool invocation.
4.1
Risk Identification and Taint-style Vulnerability Estimation
4.3
Tool Metadata Augmentation
In the offline stage, S PELL S MITH rewrites the description field of each risky tool while preserving the original tool interface and server code. The augmented description keeps the functional meaning of the tool, but adds security information that the LLM should consider during planning. The augmented description contains four concise elements:
Motivation and Design Overview
MCP tools may expose sensitive capabilities such as file access, command execution, code execution, database queries, network requests, data parsing, identity and access control, and environment-variable access. When user-controlled inputs are passed to these capabilities, the tool may be abused through taint-style vulnerabilities such as OS command injection, code injection, SQL injection, path traversal, and SSRF.
• Risk capability. What sensitive operation the tool can perform. 7
• Tainted parameters. Which arguments may contain usercontrolled input.
representative taint-style attack objectives, ten jailbreak strategies, five categories of taint-style vulnerabilities, 45 MCP servers, and 130 MCP tools.
• Potential CWE risks. Which taint-style vulnerability classes may be relevant.
6
• Invocation policy. Which intents or input patterns should be rejected, and what checks should be performed before calling the tool.
We evaluate S PELL S MITH with the following research questions.
This makes the security boundary explicit in natural language. Since LLMs rely on tool descriptions when selecting tools and filling parameters, embedding these constraints in metadata can discourage calls that route untrusted input into sensitive operations.
4.4
• RQ1: Effectiveness. How effective is S PELL S MITH in mitigating taint-style vulnerability exploitation in MCP servers? • RQ2: Ablation Study. How does each component of S PELL S MITH contribute to the mitigation effect?
Tool Invocation Reflection
6.1
In the online stage, S PELL S MITH adds a reflection step around tool invocation. Before executing a tool call, the LLM is asked to reconsider the original user intent, the selected tool, and the proposed arguments. The reflection checks whether the call is within the tool’s intended scope, whether the user appears authorized, and whether the arguments may trigger the risks described in the augmented metadata. If the reflection identifies a potential exploit attempt or an unsafe parameter, the invocation is refused or revised before it reaches the MCP Server. S PELL S MITH may also apply reflection after a call when the returned result could influence later tool use, preventing unsafe multi-step escalation. Together, metadata augmentation and invocation reflection provide a defense that is simple to deploy, does not require server-side code changes, and directly targets the LLMmediated tool-use process in MCP.
5
Experiment
Setup
Dataset. We use the benchmark described in Section 5. It contains 792 malicious MCP attack prompts, covering five taint-style attack objectives, five categories of taint-style vulnerabilities, 45 MCP servers, and 130 MCP tools. LLM. We use GPT-4o [41] as the evaluation model. GPT4o has strong instruction-following and tool-use capabilities, making it suitable for evaluating whether security-aware metadata and reflection can guide MCP tool invocation. Settings. Table 6 compares four metadata settings. None denotes no prompt-level defense. Decl. denotes a generic declaration of taint-style vulnerability risks. Wrong denotes an incorrect taint-style vulnerability description. Ident. denotes the vulnerability risk identified by S PELL S MITH and embedded into the tool description. We further compare two invocation settings: Pre-reflection, which evaluates the model before applying tool invocation reflection, and Post-reflection, which evaluates the model after applying reflection. Metrics. We report two attack success rates. Trial-level attack success rate (ASRtrial ) measures the fraction of successful attack attempts:
Benchmark of Malicious MCP Attacks
Based on the 53 vulnerabilities collected in our empirical study, we construct a benchmark of malicious MCP attacks to evaluate whether LLM agents can be induced to exploit taint-style vulnerabilities exposed by MCP servers. Each case is grounded in a real vulnerable tool and preserves the corresponding user-controlled parameter, sensitive operation, and attack goal. The benchmark therefore measures exploittriggering behavior at the MCP tool interface, rather than general policy violations detached from server-side vulnerabilities. For each vulnerability, we design trigger prompts that exercise the corresponding vulnerable data flow and define attack objectives inspired by MITRE ATT&CK tactics [35]. To improve prompt diversity and adversarial realism, we augment the benchmark with jailbreak strategies adapted from Liu et al. [29]; these variants change the surface form of the malicious intent while preserving the same tool-level risk. In total, our benchmark contains 792 attack prompts, covering five
ASRtrial =
#Successful Attack Trials . #Total Attack Trials
Case-level attack success rate (ASRcase ) measures the fraction of cases in which at least one attack succeeds: ASRcase =
#Cases with At Least One Successful Attack . #Total Test Cases
For both metrics, lower values indicate stronger mitigation.
6.2
RQ1 Effectiveness
Table 6 shows that MCP agents are highly vulnerable without defense. Under the None and Pre-reflection setting, the attack success rate reaches 56.61% at the trial level and 63.89% at the case level. 8
None
Setting Pre-reflection Post-reflection
Decl.
Wrong
Ident.
ASRtrial
ASRcase
ASRtrial
ASRcase
ASRtrial
ASRcase
ASRtrial
ASRcase
56.61% 2.19%
63.89% 3.16%
21.63% 0.67%
28.41% 1.52%
9.89% 0.17%
12.75% 0.51%
6.69% 0.04%
9.09% 0.13%
Table 6: Final attack success rates under different prompt defense settings. None denotes no prompt defense; Decl. denotes a generic declaration of taint-style vulnerabilities; Wrong denotes an incorrect taint-style vulnerability description; Ident. denotes the taint-style vulnerability identified by our method.
7
S PELL S MITH substantially reduces attack success. With identified risk descriptions and invocation reflection, the attack success rate drops to 0.04% at the trial level and 0.13% at the case level. Compared with the undefended setting, this corresponds to reductions of 56.57 and 63.76 percentage points, respectively. The near-zero case-level ASR indicates that S PELL S MITH remains effective even when attacks are evaluated at the case level. Answer to RQ1. S PELL S MITH effectively mitigates taintstyle vulnerability exploitation in MCP servers, reducing the final attack success rate to 0.04% at the trial level and 0.13% at the case level.
6.3
7.1
Related Work MCP Ecosystem and Security
Recent work has begun to study MCP as an emerging infrastructure for tool-augmented LLM agents. MCPCorpus [24] and MCPZoo [53] collect large-scale MCP servers and clients, enabling ecosystem-level measurement and runtime evaluation. Several benchmarks further evaluate MCP-based agents from different perspectives, including tool-use capability [48], multi-step workflows [55], security robustness [59, 67], and multi-tool interaction [7]. These studies provide important infrastructure for MCP evaluation, while our work focuses on real-world disclosed vulnerabilities and their mitigation. In particular, our benchmark is not only a collection of adversarial prompts; each attack is tied to a concrete vulnerable MCP tool and an observed taint-style risk. Security studies of MCP mainly examine malicious or unsafe MCP interactions. Prior work identifies attacks such as tool poisoning, puppet attacks, rug-pull attacks, malicious external resources, and preference manipulation [47, 49]. Other studies measure structural risks in the MCP ecosystem [11], analyze description-code inconsistency [23], or use static and MCP-specific analysis to uncover server-side security issues [12]. Complementary to these efforts, we collect real vulnerability reports, analyze their metadata, triggering phases, repair properties, and community responses, and show that taint-style vulnerabilities are a dominant risk in MCP servers. Several defense mechanisms have also been proposed for MCP-based agents. Jing et al. [17] introduce a contextualintegrity protocol for safer LLM-MCP interactions. AgentBound [5] and MCP Guardian [22] focus on access control, authentication, monitoring, and system-level safeguards. MCPGuard [56] combines static scanning, neural detection, and LLM-based arbitration. Our work differs in threat model and intervention point: we assume MCP servers may be benign but vulnerable, and mitigate exploit-triggering tool calls by augmenting tool metadata and adding invocation reflection, without modifying server implementations. This distinction is important because vulnerable MCP servers expose a different risk surface from malicious MCP servers. In the malicious-server setting, the primary concern is whether a server can poison the LLM’s context, manipulate tool selection, or return adversarial content. In our setting, the server may be honestly implemented for its intended task,
RQ2 Ablation Study
We next examine the contribution of each component. First, metadata augmentation is useful even without reflection. In the Pre-reflection row, a generic declaration lowers ASRtrial from 56.61% to 21.63%, and lowers ASRcase from 63.89% to 28.41%. Second, risk identification improves the quality of the augmented description. Under Pre-reflection, the identified risk description further reduces ASRtrial to 6.69% and ASRcase to 9.09%, outperforming both the generic declaration and the incorrect vulnerability description. Under Post-reflection, the identified risk description also achieves the lowest ASR among all metadata settings. Third, invocation reflection provides an additional reduction across all metadata settings. Even without metadata augmentation, reflection lowers ASRtrial from 56.61% to 2.19% and ASRcase from 63.89% to 3.16%. When combined with the identified risk description, reflection further reduces the rates from 6.69% to 0.04% and from 9.09% to 0.13%. The best result is achieved by combining all components. Under Post-reflection, the identified risk description outperforms both the generic declaration (0.67% trial-level ASR and 1.52% case-level ASR) and the incorrect vulnerability description (0.17% trial-level ASR and 0.51% case-level ASR). This suggests that reflection is powerful, but risk-specific metadata still provides useful guidance. Answer to RQ2. All three components contribute to the final mitigation effect. Metadata augmentation reduces unsafe tool planning, risk identification makes the guidance more precise, and invocation reflection further filters unsafe calls. 9
but still mishandle user-controlled parameters. Therefore, the defense must guide the LLM before it sends risky arguments to the tool. S PELL S MITH addresses this gap by treating metadata as a security-relevant interface, not merely as functional documentation.
Compared with general jailbreak defenses, MCP tool use introduces structured arguments and explicit tool metadata. A prompt may appear benign at the natural-language level while still causing unsafe behavior through a path, URL, command, query, or code parameter. This makes MCP security different from ordinary refusal-based safety filtering. Our defense therefore focuses on the relation between user intent, tool capability, and parameter semantics.
7.2 Taint-Style Vulnerabilities in LLM Agents Taint-style vulnerabilities occur when untrusted input flows into sensitive operations. Traditional research studies such vulnerabilities across C programs, OS kernels, web applications, scripting languages, firmware, and microservice systems [8, 19, 25, 30, 57, 68]. These works mainly focus on program analysis, vulnerability detection, or exploit validation in conventional software. Recent work extends this problem to LLM-integrated systems. Shen et al. [46] show that LLM agents can expose code injection, SQL injection, command injection, path traversal, and related vulnerabilities. LLMSmith [27], prompt-to-SQL injection studies [42], and AgentFuzz [26] further demonstrate that LLM-generated inputs can trigger vulnerable data flows in agent frameworks and applications. These studies show that LLMs may become a new source of untrusted inputs for existing software sinks. Our work focuses specifically on MCP servers and studies how the MCP metadata and tool invocation process can be used as a complementary defense point for reducing such exploit-triggering behavior.
7.3
8
Conclusion
This paper presents a systematic study of MCP server vulnerabilities and shows that taint-style vulnerabilities are a major security risk in the MCP ecosystem. Our empirical results reveal that security-sensitive capabilities appear across diverse tool categories, while existing tool metadata rarely provides explicit security guidance. We further find that taint-style vulnerabilities account for a dominant fraction of collected vulnerabilities, are mostly triggered during tool invocation, and often require non-trivial code changes and long response cycles to repair. Motivated by these findings, we propose S PELL S MITH, a lightweight defense that mitigates taint-style vulnerability exploitation without modifying MCP Server implementations. S PELL S MITH estimates potential taint-style risks from tool metadata, augments tool descriptions with security-aware constraints, and applies invocation reflection to reconsider unsafe tool calls. Our evaluation shows that S PELL S MITH reduces the final attack success rate to 0.04% at the trial level and 0.13% at the case level. These results suggest that security-aware metadata and LLM reflection provide a practical, deployable, and complementary direction for securing MCP-based agents.
LLM Jailbreaking and Defenses
LLM jailbreaking aims to bypass model safety constraints and induce unsafe outputs. Existing attacks include whitebox optimization such as GCG [15, 71], black-box optimization such as PAIR, TAP, GPTFuzz, AutoDAN, and PaPillon [6, 10, 28, 31, 62], as well as social-engineering and encoding-based strategies [16, 18, 58, 61, 64, 65]. Empirical studies further characterize jailbreak prompt patterns and their evolution [29, 45, 63]. We draw on these taxonomies to construct diverse malicious MCP prompts, but our target is not general policy violation; it is the exploitation of vulnerable MCP tools through LLM-mediated tool invocation. Defenses against jailbreaking commonly rely on input preprocessing, output filtering, and prompt engineering. Representative approaches include retokenization and smoothing [14, 44], certified erase-and-check defenses [21], intent analysis [69], safety classifiers such as Llama Guard and Prompt Guard [33, 34], self-examination or selfrefinement [20, 43], multi-agent filtering [66], and safetyoriented prompting [50, 52, 70]. S PELL S MITH is related to prompt-based and reflection-based defenses, but applies them at the MCP tool interface: security guidance is embedded into tool descriptions, and reflection is used to reassess concrete tool invocations before they reach vulnerable server-side code. 10
References
[12] Mohammed Mehedi Hasan, Hao Li, Emad Fallahzadeh, Gopi Krishnan Rajbahadur, Bram Adams, and Ahmed E Hassan. Model context protocol (mcp) at first glance: Studying the security and maintainability of mcp servers. arXiv preprint arXiv:2506.13538, 2025.
[1] Announcing model context protocol (mcp) support for google services. https://cloud.google.com/blo g/products/ai-machine-learning/announcing -official-mcp-support-for-google-services, 2026. Accessed January 6, 2026.
[13] Kaifeng Huang, Chenhao Lu, Yiheng Cao, Bihuan Chen, and Xin Peng. Vmud: Detecting recurring vulnerabilities with multiple fixing functions via function selection and semantic equivalent statement matching. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, pages 3958– 3972, 2024.
[2] Model context protocol (mcp): An open standard for llm–tool integration. https://modelcontextprotoc ol.io/, 2026. Accessed January 6, 2026. [3] Notion mcp. https://developers.notion.com/gu ides/mcp/mcp, 2026. Accessed January 6, 2026.
[14] Neel Jain, Avi Schwarzschild, Yuxin Wen, Gowthami Somepalli, John Kirchenbauer, Ping-yeh Chiang, Micah Goldblum, Aniruddha Saha, Jonas Geiping, and Tom Goldstein. Baseline defenses for adversarial attacks against aligned language models. arXiv preprint arXiv:2309.00614, 2023.
[4] Anthropic. Introducing the model context protocol, 2026. Accessed: 2026-01-25. URL: https://www. anthropic.com/news/model-context-protocol. [5] Christoph Bühler, Matteo Biagiola, Luca Di Grazia, and Guido Salvaneschi. Securing ai agent execution. arXiv preprint arXiv:2510.21236, 2025.
[15] Xiaojun Jia, Tianyu Pang, Chao Du, Yihao Huang, Jindong Gu, Yang Liu, Xiaochun Cao, and Min Lin. Improved techniques for optimization-based jailbreaking on large language models. arXiv preprint arXiv:2405.21018, 2024.
[6] Patrick Chao, Alexander Robey, Edgar Dobriban, Hamed Hassani, George J Pappas, and Eric Wong. Jailbreaking black box large language models in twenty queries. In 2025 IEEE Conference on Secure and Trustworthy Machine Learning (SaTML), pages 23–42. IEEE, 2025.
[16] Fengqing Jiang, Zhangchen Xu, Luyao Niu, Zhen Xiang, Bhaskar Ramasubramanian, Bo Li, and Radha Poovendran. Artprompt: Ascii art-based jailbreak attacks against aligned llms. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 15157–15173, 2024.
[7] Shiqing Fan, Xichen Ding, Liang Zhang, and Linjian Mo. Mcptoolbench++: A large scale ai agent model context protocol mcp tool use benchmark. arXiv preprint arXiv:2508.07575, 2025. [8] Wil Gibbs, Arvind S Raj, Jayakrishna Menon Vadayath, Hui Jun Tay, Justin Miller, Akshay Ajayan, Zion Leonahenahe Basque, Audrey Dutcher, Fangzhou Dong, Xavier Maso, et al. Operation mango: Scalable discovery of {Taint-Style} vulnerabilities in binary firmware services. In 33rd USENIX Security Symposium (USENIX Security 24), pages 7123–7139, 2024.
[17] Huihao Jing, Haoran Li, Wenbin Hu, Qi Hu, Xu Heli, Tianshu Chu, Peizhao Hu, and Yangqiu Song. Mcip: Protecting mcp safety via model contextual integrity protocol. In Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, pages 1177–1194, 2025.
[9] GitHub, Inc. Github rest api documentation, version 2022-11-28. Online documentation, 2022. https: //docs.github.com/en/rest?apiVersion=2022-1 1-28.
[18] Zachary D Johnson. Generation, Detection, and Evaluation of Role-play based Jailbreak attacks in Large Language Models. PhD thesis, Massachusetts Institute of Technology, 2024.
[10] Xueluan Gong, Mingzhe Li, Yilin Zhang, Fengyuan Ran, Chen Chen, Yanjiao Chen, Qian Wang, and KwokYan Lam. {PAPILLON}: Efficient and stealthy fuzz {Testing-Powered} jailbreaks for {LLMs}. In 34th USENIX Security Symposium (USENIX Security 25), pages 2401–2420, 2025.
[19] Mingqing Kang, Yichao Xu, Song Li, Rigel Gjomemo, Jianwei Hou, VN Venkatakrishnan, and Yinzhi Cao. Scaling javascript abstract interpretation to detect and exploit node. js taint-style vulnerability. In Proceedings of the 2023 IEEE Symposium on Security and Privacy (SP), pages 1059–1076. IEEE, 2023.
[11] Hechuan Guo, Yongle Hao, Yue Zhang, Minghui Xu, Peizhuo Lyu, Jiezhi Chen, and Xiuzhen Cheng. A measurement study of model context protocol. arXiv eprints, pages arXiv–2509, 2025.
[20] Heegyu Kim and Hyunsouk Cho. Break the breakout: Reinventing lm defense against jailbreak attacks with self-refine. In Proceedings of the 5th Workshop on Trustworthy NLP (TrustNLP 2025), pages 82–102, 2025. 11
[21] Aounon Kumar, Chirag Agarwal, Suraj Srinivas, Aaron Jiaxun Li, Soheil Feizi, and Himabindu Lakkaraju. Certifying llm safety against adversarial prompting. arXiv preprint arXiv:2309.02705, 2023.
[31] Anay Mehrotra, Manolis Zampetakis, Paul Kassianik, Blaine Nelson, Hyrum Anderson, Yaron Singer, and Amin Karbasi. Tree of attacks: Jailbreaking black-box llms automatically. Advances in Neural Information Processing Systems, 37:61065–61105, 2024.
[22] Sonu Kumar, Anubhav Girdhar, Ritesh Patil, and Divyansh Tripathi. Mcp guardian: A security-first layer for safeguarding mcp-based ai system. arXiv preprint arXiv:2504.12757, 2025.
[32] Andrew Meneely, Harshavardhan Srinivasan, Ayemi Musa, Alberto Rodriguez Tejeda, Matthew Mokary, and Brian Spates. When a patch goes bad: Exploring the properties of vulnerability-contributing commits. In 2013 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement, pages 65–74. IEEE, 2013.
[23] Zhihao Li, Boyang Ma, Xuelong Dai, Minghui Xu, Yue Zhang, Biwei Yan, and Kun Li. Don’t believe everything you read: Understanding and measuring mcp behavior under misleading tool descriptions. arXiv preprint arXiv:2602.03580, 2026.
[33] Meta. Llama guard 4: Model card and prompt formats, 2025. URL: https://www.llama.com/docs/model -cards-and-prompt-formats/llama-guard-4/.
[24] Zhiwei Lin, Bonan Ruan, Jiahao Liu, and Weibo Zhao. A large-scale evolvable dataset for model context protocol ecosystem and security analysis. arXiv preprint arXiv:2506.23474, 2025.
[34] Meta. Llama prompt guard: Model cards and prompt formats, 2025. URL: https://www.llama.com/docs /model-cards-and-prompt-formats/prompt-gua rd/.
[25] Fengyu Liu, Yuan Zhang, Tian Chen, Youkun Shi, Guangliang Yang, Zihan Lin, Min Yang, Junyao He, and Qi Li. Detecting taint-style vulnerabilities in microservicestructured web applications. In 2025 IEEE Symposium on Security and Privacy (SP), pages 972–990, 2025.
[35] MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. https: //attack.mitre.org/. Accessed: 2026-06-16. [36] modelcontextprotocol. Model context protocol python sdk. GitHub repository, 2024. https://github.com /modelcontextprotocol/python-sdk.
[26] Fengyu Liu, Yuan Zhang, Jiaqi Luo, Jiarun Dai, Tian Chen, Letian Yuan, Zhengmin Yu, Youkun Shi, Ke Li, Chengyuan Zhou, et al. Make agent defeat agent: Automatic detection of {Taint-Style} vulnerabilities in {LLM-based} agents. In 34th USENIX Security Symposium (USENIX Security 25), pages 3767–3786, 2025.
[37] National Institute of Standards and Technology (NIST). National vulnerability database (nvd). https://nvd. nist.gov/, 2026. Accessed: 2026-01-08.
[27] Tong Liu, Zizhuang Deng, Guozhu Meng, Yuekang Li, and Kai Chen. Demystifying rce vulnerabilities in llmintegrated apps. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, pages 1716–1730, 2024.
[38] NVD NIST. Commit 0284aa8 for patching the cve2025-5276 vulnerability, 2026. Accessed: 2026-01-25. URL: https://github.com/zcaceres/markdownif y-mcp/commit/0284aa8f34d32c65e20d8cda2d42 9b7943c9af03.
[28] Xiaogeng Liu, Nan Xu, Muhao Chen, and Chaowei Xiao. Autodan: Generating stealthy jailbreak prompts on aligned large language models. arXiv preprint arXiv:2310.04451, 2023.
[39] NVD NIST. Cve-2025-5276 detail, 2026. Accessed: 2026-01-25. URL: https://nvd.nist.gov/vuln/de tail/cve-2025-5276. [40] NVD NIST. User comment of the commit 0284aa8 for patching the cve-2025-5276 vulnerability, 2026. Accessed: 2026-01-25. URL: https://github.com/zca ceres/markdownify-mcp/commit/0284aa8f34d3 2c65e20d8cda2d429b7943c9af03#r160156463.
[29] Yi Liu, Gelei Deng, Zhengzi Xu, Yuekang Li, Yaowen Zheng, Ying Zhang, Lida Zhao, Tianwei Zhang, Kailong Wang, and Yang Liu. Jailbreaking chatgpt via prompt engineering: An empirical study. arXiv preprint arXiv:2305.13860, 2023.
[41] OpenAI. The official website of GPT-4o. https://op enai.com/index/hello-gpt-4o/.
[30] Changhua Luo, Penghui Li, and Wei Meng. Tchecker: Precise static inter-procedural analysis for detecting taint-style vulnerabilities in php applications. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security (CCS), pages 2175– 2188, 2022.
[42] 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 Proceedings of the IEEE/ACM 47th International 12
Conference on Software Engineering, pages 1768–1780, 2025.
[53] Mengying Wu, Pei Chen, Geng Hong, Baichao An, Jinsong Chen, Binwang Wan, Xudong Pan, Jiarun Dai, and Min Yang. Mcpzoo: A large-scale dataset of runnable model context protocol servers for ai agent, 2025. arXiv:2512.15144.
[43] M Phute, A Helbling, M Hull, S Peng, S Szyller, C Cornelius, DH Chau, and Self Defense LLM. By self examination, llms know they are being tricked. arxiv 2023. arXiv preprint arXiv:2308.07308.
[54] Zhaonan Wu, Yanjie Zhao, Chen Wei, Zirui Wan, Yue Liu, and Haoyu Wang. Commitshield: Tracking vulnerability introduction and fix in version control systems. In 2025 IEEE/ACM 47th International Conference on Software Engineering: Companion Proceedings (ICSECompanion), pages 279–290. IEEE, 2025.
[44] Alexander Robey, Eric Wong, Hamed Hassani, and George J Pappas. Smoothllm: Defending large language models against jailbreaking attacks. arXiv preprint arXiv:2310.03684, 2023. [45] 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.
[55] Zijian Wu, Xiangyan Liu, Xinyuan Zhang, Lingjun Chen, Fanqing Meng, Lingxiao Du, Yiran Zhao, Fanshi Zhang, Yaoqi Ye, Jiawei Wang, et al. Mcpmark: A benchmark for stress-testing realistic and comprehensive mcp use. arXiv preprint arXiv:2509.24002, 2025.
[46] Zhuoxiang Shen, Jiarun Dai, Yuan Zhang, and Min Yang. Security debt in llm agent applications: A measurement study of vulnerabilities and mitigation trade-offs.
[56] Wenpeng Xing, Zhonghao Qi, Yupeng Qin, Yilin Li, Caini Chang, Jiahui Yu, Changting Lin, Zhenzhen Xie, and Meng Han. Mcp-guard: A defense framework for model context protocol integrity in large language model applications. arXiv preprint arXiv:2508.10991, 2025.
[47] Hao Song, Yiming Shen, Wenxuan Luo, Leixin Guo, Ting Chen, Jiashui Wang, Beibei Li, Xiaosong Zhang, and Jiachi Chen. Beyond the protocol: Unveiling attack vectors in the model context protocol ecosystem. arXiv preprint arXiv:2506.02040, 2025.
[57] Fabian Yamaguchi, Alwin Maier, Hugo Gascon, and Konrad Rieck. Automatic inference of search patterns for taint-style vulnerabilities. In 2015 IEEE symposium on security and privacy, pages 797–812. IEEE, 2015.
[48] Wei Song, Haonan Zhong, Ziqi Ding, Jingling Xue, and Yuekang Li. Help or hurdle? rethinking model context protocol-augmented large language models. arXiv preprint arXiv:2508.12566, 2025.
[58] Xikang Yang, Xuehai Tang, Jizhong Han, and Songlin Hu. The dark side of trust: Authority citation-driven jailbreak attacks on large language models. arXiv preprint arXiv:2411.11407, 2024.
[49] Zihan Wang, Rui Zhang, Yu Liu, Wenshu Fan, Wenbo Jiang, Qingchuan Zhao, Hongwei Li, and Guowen Xu. Mpma: Preference manipulation attack against model context protocol. arXiv preprint arXiv:2505.11154, 2025.
[59] Yixuan Yang, Daoyuan Wu, and Yufan Chen. Mcpsecbench: A systematic security benchmark and playground for testing model context protocols. arXiv preprint arXiv:2508.13220, 2025. [60] Xiaokang Yin, Ruijie Cai, Xiaoya Zhu, Qichao Yang, Enzhou Song, and Shengli Liu. Precise discovery of more taint-style vulnerabilities in embedded firmware. IEEE Transactions on Dependable and Secure Computing, 2024.
[50] Zeming Wei, Yifei Wang, Ang Li, Yichuan Mo, and Yisen Wang. Jailbreak and guard aligned language models with only few in-context demonstrations. arXiv preprint arXiv:2310.06387, 2023.
[61] Zheng-Xin Yong, Cristina Menghini, and Stephen H Bach. Low-resource languages jailbreak gpt-4. arXiv preprint arXiv:2310.02446, 2023.
[51] Zhongzhen Wen, Jiayuan Zhou, Minxue Pan, Shaohua Wang, Xing Hu, Tongtong Xu, Tian Zhang, and Xuandong Li. Silent taint-style vulnerability fixes identification. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, pages 428–439, 2024.
[62] Jiahao Yu, Xingwei Lin, Zheng Yu, and Xinyu Xing. Gptfuzzer: Red teaming large language models with auto-generated jailbreak prompts. arXiv preprint arXiv:2309.10253, 2023.
[52] Fangzhao Wu, Yueqi Xie, Jingwei Yi, Jiawei Shao, Justin Curl, Lingjuan Lyu, Qifeng Chen, and Xing Xie. Defending chatgpt against jailbreak attack via selfreminder. 2023.
[63] Zhiyuan Yu, Xiaogeng Liu, Shunning Liang, Zach Cameron, Chaowei Xiao, and Ning Zhang. Don’t listen to me: Understanding and exploring jailbreak prompts 13
of large language models. In 33rd USENIX Security Symposium (USENIX Security 24), pages 4675–4692, 2024. [64] Youliang Yuan, Wenxiang Jiao, Wenxuan Wang, Jen-tse Huang, Pinjia He, Shuming Shi, and Zhaopeng Tu. Gpt4 is too smart to be safe: Stealthy chat with llms via cipher. arXiv preprint arXiv:2308.06463, 2023. [65] Yi Zeng, Hongpeng Lin, Jingwen Zhang, Diyi Yang, Ruoxi Jia, and Weiyan Shi. How johnny can persuade llms to jailbreak them: Rethinking persuasion to challenge ai safety by humanizing llms. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 14322–14350, 2024. [66] Yifan Zeng, Yiran Wu, Xiao Zhang, Huazheng Wang, and Qingyun Wu. Autodefense: Multi-agent llm defense against jailbreak attacks. arXiv preprint arXiv:2403.04783, 2024. [67] Dongsen Zhang, Zekun Li, Xu Luo, Xuannan Liu, Peipei Li, and Wenjun Xu. Mcp security bench (msb): Benchmarking attacks against model context protocol in llm agents. arXiv preprint arXiv:2510.15994, 2025. [68] Hang Zhang, Weiteng Chen, Yu Hao, Guoren Li, Yizhuo Zhai, Xiaochen Zou, and Zhiyun Qian. Statically discovering high-order taint style vulnerabilities in os kernels. In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, pages 811– 824, 2021. [69] Yuqi Zhang, Liang Ding, Lefei Zhang, and Dacheng Tao. Intention analysis makes llms a good jailbreak defender. In Proceedings of the 31st International Conference on Computational Linguistics, pages 2947–2968, 2025. [70] Zhexin Zhang, Junxiao Yang, Pei Ke, Fei Mi, Hongning Wang, and Minlie Huang. Defending large language models against jailbreaking attacks through goal prioritization. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 8865–8887, 2024. [71] Andy Zou, Zifan Wang, Nicholas Carlini, Milad Nasr, J Zico Kolter, and Matt Fredrikson. Universal and transferable adversarial attacks on aligned language models. arXiv preprint arXiv:2307.15043, 2023.
14