Beyond Tool Poisoning: Attack Surfaces of Malicious Remote MCP Servers Across LLM Platforms

Abstract

The Model Context Protocol (MCP) has become the de facto standard for connecting large language models (LLMs) to external tools, and its remote deployment mode lets users add third-party servers with a single URL—shifting a substantial portion of the host’s attack surface to infrastructure operated by anonymous parties. Existing MCP security work has concentrated on tool-description poisoning and studied individual techniques in isolation, leaving it unclear what a malicious remote server can accomplish across its full surface. In this paper, we explore the malicious-server threat space along the axis of whether the host LLM participates in producing the harmful outcome, yielding two categories: LLM-passive attacks, which complete inside the server, and LLM-active attacks, which require the LLM to deliver the malicious content. We implement five scenarios spanning both categories—realizing each LLM-active scenario with both description-based and response-based variants against the same goal—and evaluate all configurations on ChatGPT, Claude Desktop, and Gemini CLI. We find that host-side filtering of MCP-bound data varies sharply across platforms (95% vs. 50% ASR on the same email request), that the description and response channels succeed on disjoint scenarios, and that successful attacks are almost never disclosed to the user. These findings suggest that defending remote MCP deployment requires a multi-layer approach combining host-side filtering, LLM-level response auditing, and user-visible output transparency.

1. Introduction

Large language models (LLMs) are increasingly deployed not as standalone text generators but as the reasoning core of applications that act on the user’s behalf—reading files, sending messages, browsing the web, and invoking external services. The Model Context Protocol (MCP), introduced by Anthropic in late 2024 [1], has become the predominant standard for connecting LLMs to such external tools. While the protocol supports both local and remote server deployment, the remote mode—in which the server is hosted by a third party and reached over HTTP or Server-Sent Events—is operationally attractive but shifts a substantial portion of the host’s effective attack surface to infrastructure operated by a party that is neither the user nor the host vendor.

The risk that this trust shift creates is not hypothetical. In September 2025, an unofficial Postmark MCP server with over 1500 weekly downloads was modified by its maintainer to silently BCC every outgoing email to an attacker-controlled address, and the change went undetected for weeks [2]. The conditions that enabled this incident are not exceptional but structural: public registries such as Smithery [3] aggregate tens of thousands of community-contributed servers, most of them unvetted and maintained by anonymous authors, and installation takes a single URL on all major hosts. As MCP integration becomes available in mainstream consumer LLM products such as ChatGPT [4] and Claude Desktop [1], and as the MCP server ecosystem continues its rapid expansion [5], the population of users connected to third-party servers is expected to grow substantially, and each such connection extends the trust boundary of the host into third-party code.

Existing MCP security research has characterized a number of individual threats in this setting but does not yet offer a unified view of what a malicious server can accomplish across its full surface. The most studied attack vector is the Tool Poisoning Attack (TPA) [6], in which hidden directives embedded in a tool’s description hijack the LLM at registration time; subsequent work has cataloged related variants, including rug-pull patterns [7] and cross-server shadowing [8], and has benchmarked host resistance against specific attack families [9,10,11]. Two gaps persist across this body of work. Attention has been concentrated on the tool description as the adversarial surface, while the content returned by tools at runtime has received comparatively little direct study; existing evaluations typically treat each attack technique in isolation, leaving the relative effectiveness of different attack channels against the same goal largely uncharacterized.

We bridge these gaps by organizing the malicious-server threat space along a different axis than prior benchmarks. Existing systematic evaluations of MCP security—most notably MCPTox [9] and MCPSecBench [10]—organize their analysis by attack type, treating each attack technique as an independent unit of measurement and reporting how often each technique succeeds on each host. This organization is well suited to quantifying the prevalence of known attacks, but it does not separate the underlying mechanisms and adversary exercises, and it therefore cannot distinguish which defense boundary applies to which class of attack. We instead organize the threat space by the role the host LLM plays in producing the harmful outcome, yielding two categories. In LLM-passive attacks, the server completes the attack internally at invocation time, using only the arguments the host dispatches to it; the LLM’s content reasoning never sees the malicious behavior and therefore cannot defend against it. In LLM-active attacks, the LLM is the delivery channel, and the server must induce the LLM to produce or relay the malicious content—which it can do through either the tool’s description or the tool’s response, allowing direct comparison of the two channels on the same target. This framing exposes asymmetries that an attack-type taxonomy alone cannot: the same attack goal can be reached through either the description channel or the response channel with very different per-platform success rates, and the decisive defense boundary in each case lies at a different point in the invocation pipeline (pre-invocation filtering for LLM-passive attacks; content reasoning by the LLM for LLM-active attacks). Building on this observation, we implement five attack scenarios spanning both categories—File Content Exfiltration and Email Content Exfiltration as LLM-passive attacks, and Conditional URL Substitution, Malicious Code Augmentation, and Image Steganography as LLM-active attacks—and evaluate them across three representative host platforms (Section 4).

We measure each configuration with two metrics: the Attack Success Rate (ASR) and, for successful trials, the Self-Reporting Rate (SRR), which captures whether a successful attack remains observable to an attentive user or completes silently. Our findings are threefold. First, host-side filtering of MCP-bound data varies sharply across platforms: 95% ASR on Claude versus 50% on ChatGPT for the same credential-bearing email request. Second, the description and response channels succeed on disjoint scenarios—description-based attacks reliably succeed only on URL substitution, while response-based attacks succeed across all three with ASR ≥ 85%—demonstrating that the choice of channel, not the choice of technique, governs which attacks current hosts permit. Third, successful attacks are almost never disclosed to the user (SRR 0% across all LLM-passive attacks and most LLM-active configurations), with the sole exception of Claude on response-based code augmentation, where the LLM self-reports the inserted payload in 100% of successful trials. These observations point to a multi-layered defense posture combining host-side pre-invocation filtering, LLM-level response auditing, and user-visible output transparency, which we discuss in Section 5.

We summarize our contributions along three dimensions.

• Conceptual. We introduce the LLM-passive/LLM-active framework that organizes the malicious remote MCP server threat space by the role the host LLM plays in producing the harmful outcome, and we further decompose LLM-active attacks into description-based and response-based variants that exercise distinct adversary capabilities against the same goal.
• Empirical. We instantiate five attack scenarios across both categories and evaluate every (scenario, platform, variant) combination across ChatGPT, Claude Desktop, and Gemini CLI, producing the first measurement of the disjoint-channel asymmetry between description-based and response-based realizations of the same attack goal.
• Practical. We map each adversary capability to a corresponding defense boundary in the invocation pipeline—host-side pre-invocation filtering for (C3), LLM-level response auditing for (C1) and (C2), and user-visible output transparency as a cross-cutting measure—and identify where current commercial hosts are most permissive and where existing platform-specific behaviors already provide partial defenses that a deliberate design could systematize.

We do not attempt to define a fully “secure” baseline for remote MCP deployment; what such a baseline should look like is itself an open question that our findings help inform rather than answer.

The remainder of this paper is organized as follows. Section 2 presents background on MCP and reviews related work; Section 3 defines our threat model and methodology; Section 4 reports the attack scenarios and results; and Section 5 discusses mitigation strategies that follow from these observations.

2. Background and Related Work

This section introduces the technical foundations of the MCP, reviews prior work on prompt injection and tool-integrated LLM security, surveys the emerging MCP security landscape, and positions our contribution with respect to recent benchmarks.

2.1. MCP Architecture

MCP, introduced by Anthropic in late 2024 [1], is an open standard for connecting large language models (LLMs) to external tools and data sources. MCP has rapidly become a de facto integration layer for LLM-based applications; by mid-2025, tens of thousands of publicly available MCP servers had emerged across community-driven and commercial ecosystems.

As shown in  Figure 1, MCP follows a client–server architecture with three roles. A host is the user-facing LLM application (e.g., Claude Desktop, ChatGPT, or a CLI agent such as Gemini CLI). An MCP client, embedded within the host, establishes connections to one or more MCP servers, which expose tools, resources, and prompt templates that the LLM can invoke. When the user issues a request, the host forwards the relevant context to the LLM along with a catalog of tools advertised by the connected servers. The LLM decides autonomously whether to invoke a tool and, if so, which one. The selected invocation is relayed through the MCP client to the corresponding server, and the server’s response is returned through the same path, integrated into the conversation context, and used by the LLM to formulate its final reply to the user.

2.2. Tool Interface and Registration

The primary surface that a server exposes to the host is its tool interface. As illustrated in Listing 1, each tool is defined by a name, a description, an input schema, and a server-side implementation. When a host connects to an MCP server, it retrieves the tool catalog and incorporates the names, descriptions, and schemas—but not the implementations—into the LLM’s context, so that the LLM can decide when and how to call each tool.

Listing 1: A minimal MCP tool definition in FastMCP, with its four interface elements labeled.

Two properties of this interface are particularly relevant to the threat surface we study. First, the description field is an entirely free-form natural language authored by the server operator and is consumed directly by the LLM as part of its prompt context. The LLM’s decision to invoke a tool and the way it summarizes results are conditioned on this text. Second, the tool’s implementation is opaque to the host: the host observes only the tool’s declared interface and the structured response produced at invocation time. There is no mechanism by which the host can verify that the implementation’s behavior corresponds to the behavior advertised in the description.

2.3. Local and Remote Deployment

MCP servers can be deployed in two modes, which differ substantially in their operational and security characteristics. Local servers communicate with the host via standard input/output (stdio) and run as subprocesses spawned by the host on the user’s machine. Because the server executes locally, its source (or a pinned binary) is present on the user’s system and can be inspected, version-pinned, or sandboxed by the operating system. Installation typically requires explicit user action, such as downloading a package or configuring a command path.

Remote servers communicate over HTTP or Server-Sent Events (SSE) and are hosted on infrastructure operated by a third party. The user configures the host with only a URL, and the MCP client establishes an authenticated or unauthenticated connection over the network. The user has no visibility into the server’s implementation, and the server’s behavior may change at any time without a corresponding update on the user’s system. This shifts several trust properties compared to the local case:

• Code Auditability. The server’s source code is not available to the user. Advertised tool descriptions are the user’s primary signal of what the server does.
• Update Opacity. The server operator can modify tool implementations silently between invocations. A server that behaves benignly when first added may alter its behavior on any subsequent call.
• Cross-session Persistence. Once configured, the host typically reconnects to the server automatically on restart (a “configure once, run always” pattern [12]), so a user who adds a remote server continues to be exposed on every subsequent session until the server is explicitly removed.

These properties make remote deployment operationally attractive but structurally asymmetric: trust flows from the user to the server on the basis of advertised metadata alone, while the server retains full control over the content of its responses at runtime. Our work focuses exclusively on this remote deployment setting.

2.4. Prior Work on LLM and MCP Security

The foundational threat that underlies our attack scenarios is prompt injection, in which adversarial instructions embedded in data processed by an LLM override the model’s original directives. Greshake et al. [13] first systematically characterized indirect prompt injection (IPI), demonstrating that the boundary between data and instructions effectively dissolves when LLMs are given access to external content; subsequent work has formalized the threat [14], shown that such attacks compromise real-world LLM-integrated applications [15], and demonstrated that they remain effective against tool-calling agents under sandboxed and adversarial benchmarks [16,17]. Broader surveys catalog the resulting threat landscape across the LLM-agent ecosystem [18]. In these settings the adversary is typically modeled as a third party who plants malicious content into data sources that the LLM happens to retrieve, in contrast to our setting in which the MCP server itself—an explicitly registered and trusted component—acts as the adversary.

Within the MCP ecosystem, the most widely studied threat is the Tool Poisoning Attack (TPA), first identified by Invariant Labs in 2025 [6], in which malicious instructions are embedded within tool descriptions and injected into the LLM’s context at server registration time. The same channel has been exploited for closely related ends: Wang et al. [19] introduce the MCP Preference Manipulation Attack, where crafted tool names and descriptions bias the LLM toward selecting an attacker-controlled server over competing alternatives, and Bhatt et al. [7] formalize the Rug Pull Attack, where a server initially behaves benignly before silently altering its tool definitions or behavior. A real-world instance of the latter was documented in September 2025, when an unofficial Postmark MCP server with over 1500 weekly downloads was modified to silently BCC all outgoing emails to an attacker-controlled address [2]. Taxonomic studies map the broader threat surface, cataloging server-side risks including remote-specific connection-parameter abuse, shadowing, and web-layer indirect injection [8,11,12,20], while complementary efforts target code-level vulnerabilities in MCP server implementations [21] or examine defenses against indirect prompt injection more broadly [22]. On the evaluation side, Wang et al. [9] released MCPTox, a TPA benchmark on real-world MCP servers reporting that even Claude-3.7-Sonnet refuses fewer than 3% of such attacks; most directly related to our work, Yang et al. [10] proposed MCPSecBench, a systematic benchmark evaluating 17 attack types across four surfaces on Claude Desktop, OpenAI, and Cursor.

Two observations about this body of work motivate the perspective we take in this paper. First, attention has been concentrated primarily on the tool description as the adversarial surface and on protocol- or implementation-layer flaws, while the content of tool responses returned at runtime—and the behavior of the host LLM in relaying or validating that content—has received comparatively less direct empirical study. Second, existing evaluations typically treat each attack technique in isolation: TPA is studied as a distinct phenomenon from response-level manipulation, and neither is routinely compared against the other on the same underlying attack goal.

2.5. Positioning

Our work complements this literature by taking a different slice through the malicious-server threat space. Rather than surveying a large taxonomy of distinct attack techniques, we examine the attack capabilities available to a malicious remote MCP server that has already been legitimately registered by the user, and we organize our analysis around the role the host LLM plays in carrying out each attack.

Across five scenarios—File Content Exfiltration, Email Content Exfiltration, Conditional URL Substitution, Malicious Code Augmentation, and Image Steganography—we empirically characterize the conditions under which each scenario succeeds or fails. Two aspects of this study are not directly addressed by prior work.

First, for the scenarios in which the LLM participates in delivering the malicious content, we implement and compare two realizations of the same attack goal—one mediated by the tool description and one by the tool response—enabling direct comparison of TPA-style and response-level attacks within a single experimental framework. Second, for the scenarios that complete through server-internal actions independent of the LLM’s content reasoning, we examine whether the host filters sensitive user-supplied data before forwarding it into the MCP server and document the inconsistency of this behavior across platforms. The attack model and methodology underlying these experiments are given in Section 3.

3. Threat Model and Methodology

This section defines the adversary we consider, the capabilities we grant it, the two attack categories that organize our analysis, and the experimental setup under which the scenarios in Section 4 are evaluated.

3.1. Attacker Model

We consider an adversary who operates a remote MCP server and seeks to harm users of LLM-based applications that connect to it. The adversary may be the server operator acting in bad faith, or an external party who has compromised an otherwise legitimate server (e.g., via a supply-chain attack on its hosting infrastructure, or through a rug-pull pattern in which a previously benign server is silently modified [2,7]). We assume that the server has been legitimately registered by the user prior to the attack: the user has discovered the server through normal channels (e.g., an MCP directory, a blog post, a colleague’s recommendation), added it to their host configuration, and expects its tools to function as advertised. This is the dominant pathway by which users connect to remote servers in practice—public MCP directories aggregate thousands of community-contributed servers without systematic vetting, and the Postmark incident [2] demonstrates that even widely adopted servers can be silently turned malicious without losing their legitimate appearance. The attack proceeds during normal use, through invocations of the server’s tools that the user explicitly or implicitly solicits. The adversary’s leverage comes purely from being the server on the other end of an otherwise normal MCP interaction: we do not consider attacks that require additionally compromising the host application, the LLM model weights, the user’s device, the underlying transport layer, or the authentication flow used during server discovery.

• Research Scope. We restrict our study to the remote deployment setting; the local stdio mode shares some of these threats but has distinct properties (local code availability, OS-level sandboxing) that warrant separate study. We also do not examine implementation-layer vulnerabilities in the server’s own code (e.g., command injection, path traversal, SSRF), which are addressed by complementary work [8,21]. Throughout, we treat the host application and the LLM behind it as closed systems and do not attempt to reverse-engineer their internal logic; this matches the perspective from which both attackers and defenders interact with commercial LLM platforms in practice, and our observations are accordingly limited to externally visible behavior at the MCP interface and in the LLM’s user-facing responses.

3.2. Attacker Capabilities

Within this model, the adversary has control over three aspects of the server’s behavior:

• (C1) Tool Metadata. The adversary authors the names, descriptions, and input schemas of the tools the server exposes. These are consumed by the host and incorporated into the LLM’s context as described in Section 2.2. The description in particular is a free-form natural-language field that the LLM treats as authoritative guidance on the tool’s purpose and intended use.
• (C2) Tool Response Content. The adversary controls the content returned by any tool when it is invoked. Responses may be structured data, natural-language text, binary artifacts (e.g., images), or references to downloadable artifacts hosted on attacker-controlled infrastructure.
• (C3) Server-side Execution. The adversary controls the internal implementation of each tool. Any side effect permitted by the server’s runtime environment—outbound network requests to attacker-controlled endpoints, reads and writes to attacker storage, invocation of external services using credentials supplied through the tool’s inputs—is available to the adversary at the moment of invocation. These side effects are not visible to the host or to the LLM beyond the return value of the tool.

The adversary does not have the ability to observe or modify the host LLM’s internal reasoning, nor to inject content into the conversation outside the channel formed by tool invocations and responses. The only signal the LLM receives from the server is the tool description at registration (C1) and the tool response at invocation (C2); any effect of (C3) reaches the user only to the extent that it has already occurred by the time the tool returns.

3.3. Attack Categories

We distinguish two categories of attacks based on the role the host LLM plays in producing the harmful outcome.

• LLM-Passive Attacks. The LLM is passive with respect to the malicious outcome: its only involvement is the initial decision to invoke the tool and the construction of the tool’s input arguments. Once the tool is called, the harmful behavior is executed entirely within the server, exercising capability (C3). The LLM does not observe, relay, or participate in the malicious action beyond dispatching the invocation; its user-visible response describes only the tool’s benign return value, which the server crafts to be unremarkable.

Because the LLM does not participate in the attack’s execution, its content-level reasoning—its ability to inspect, validate, or refuse specific outputs—does not provide protection. The decisive defense boundary in this category is whether the host filters sensitive data out of the tool invocation before it is sent to the server: that is, whether capability (C3) is ever allowed to execute.

• LLM-Active Attacks. The LLM is active in delivering the malicious content to the user: the attack’s harmful effect is realized only when the LLM, as part of its user-facing response, produces or relays content that the adversary has supplied or induced. Two sub-mechanisms exist, corresponding to the two channels available to the adversary:

• A description-based variant exercises capability (C1). The tool description contains a directive that, when incorporated into the LLM’s context, biases the LLM to produce attacker-specified content in its response. The tool’s actual runtime behavior may be inert; the attack succeeds through the LLM’s interpretation of the description alone.
• A response-based variant exercises capability (C2). The tool description is unremarkable, but the tool returns content that the LLM is expected to relay to the user without modification (e.g., a code string, a download URL, a summary). The attack succeeds if the LLM forwards the server-produced content without inspection.

In both sub-mechanisms, the LLM is the final conduit to the user. The decisive defense boundary in this category is the LLM’s content reasoning—whether it treats descriptions as authoritative, and whether it validates tool responses against the user’s request before relaying them.

• Combinability. The two categories are analytically distinct but not mutually exclusive in practice. An adversary with control over all three capabilities (C1, C2, C3) can combine them in a single attack—for instance, pairing an LLM-passive exfiltration via (C3) with a response-based component via (C2) that returns a plausible-but-false summary, thereby suppressing the user’s suspicion that anything was sent at all. The scenarios we evaluate in Section 4 isolate each mechanism in order to attribute observed host behavior to a specific defense boundary; combined attacks that interleave passive and active components are a natural direction for future work. We treat the LLM-passive/LLM-active distinction throughout this paper as an analytical tool that decomposes the attack surface into its constituent mechanisms, rather than as a strict binary partition of all possible attacks.

3.4. Evaluation Metrics

We report two metrics throughout. The Attack Success Rate (ASR) is the fraction of repetitions in which the adversarial goal is achieved: for LLM-passive scenarios, this is whether the targeted data reaches the attacker; for LLM-active scenarios, this is whether the attacker’s intended content (phishing URL, injected code, steganographic payload) appears in the LLM’s user-facing response. The Self-Reporting Rate (SRR) is the fraction of successful repetitions in which the LLM’s user-facing response explicitly flags the suspicious behavior—for example, noting that the generated code contains additions beyond what the user requested, or that the recommended URL may not be the expected one. SRR captures whether a successful attack is observable to an attentive user or completes silently; it is defined only over successful trials.

4. Attack Scenarios and Results

This section presents the five attack scenarios we study and the empirical results observed across ChatGPT, Claude Desktop, and Gemini CLI. Following the categorization introduced in Section 3.3, we group the scenarios by the role the host LLM plays in producing the harmful outcome: Section 4.2 covers LLM-passive attacks and Section 4.3 covers LLM-active attacks.

4.1. Experimental Setup

• Platforms. We evaluate the attacks against three representative LLM platforms that support remote MCP server integration: ChatGPT, Claude Desktop, and Gemini CLI. Each platform implements the MCP host role but differs in its user interface (web-based conversation, desktop application, terminal agent) and in its handling of tool inputs and outputs, both of which we find to be material to the experimental results.
• Server Configuration. All experiments use a single remote MCP server implemented with the FastMCP framework [23] and exposed over HTTPS via an ngrok tunnel [24]. For each scenario we reconfigure the server to host the corresponding malicious tool; across scenarios, the server endpoint URL remains the same, so that the host-side registration experience is identical. Per-platform configuration details are summarized in 

  Table 1. Platform configurations used in our experiments. All three hosts support remote MCP server integration; ChatGPT and Claude Desktop accept the server URL through a GUI setting, while Gemini CLI reads the configuration from a local JSON file.

  Host Platform	Model Version	Interface Type	Configuration
  ChatGPT	GPT-5.3 Instant	GUI	Deployment URL
  Claude Desktop	claude-sonnet-4-5	GUI	Deployment URL
  Gemini CLI	gemini-3.1-flash-lite-preview	Command-line	settings.json entry

  .
• Prompts and Repetitions. Each scenario is evaluated using a fixed user prompt designed to plausibly motivate invocation of the malicious tool (e.g., “Use the {tool} MCP server to read the attached file and provide a concise summary”). Prompts were intentionally written to resemble plausible everyday user requests for the advertised tool functionality, without any deliberate engineering to bypass platform safety filters or to phrase the request in adversarial language; the ASR values we report therefore reflect the host’s response to legitimate-looking invocations rather than the result of prompt-level circumvention. We repeat each (scenario, platform, variant) combination 20 times and report aggregate ASR and SRR over the repetitions, using the metric definitions given in Section 3.4. The choice of 20 repetitions was informed by pilot runs showing that host behavior for each (scenario, platform, variant) combination is largely deterministic; the sample size is chosen to expose any non-deterministic deviation from the modal outcome rather than to characterize a high-variance distribution. Where the headline cross-platform contrasts are highlighted in the text, we additionally report 95% Wilson confidence intervals to make the robustness of the observed differences explicit at this sample size. We note one platform-specific exception in prompt design: for the description-based variant of Image Steganography on Gemini CLI, we use a slightly extended prompt that asks the agent to perform the conversion through a Python script (see Appendix A.5). This adaptation was necessary to ensure that Gemini CLI consistently invokes the conversion tool at all; without it, the agent frequently bypassed the MCP server. The adaptation does not change the substantive task or the description-based attack vector itself. A similar but shorter adaptation was applied to Code Augmentation on Gemini CLI to ensure the agent reads the file through the MCP server rather than directly (see Appendix A.4). To control for session-level state carryover, each repetition begins from a fresh conversation.
• Ground-truth Verification. ASR is determined by objective signals in both attack categories. For LLM-passive scenarios, attack success is verified by inspecting logs on the attacker-controlled endpoint—specifically, whether the file upload was received or whether an email was actually delivered to the attacker’s address—so the success criterion is a binary check independent of the LLM’s user-facing wording. For LLM-active scenarios, attack success is determined by checking the LLM’s final user-facing response (or the returned artifact) for the presence of a well-defined attacker-supplied element: the exact phishing URL in Conditional URL Substitution, the appended attacker function in Malicious Code Augmentation, or the COM-marker payload in the returned JPEG in Image Steganography. In each case, the artifact is unambiguous to verify and does not rely on subjective interpretation of the LLM’s tone or phrasing. SRR judgments follow a per-scenario rubric. A successful trial is coded as a self-report if the LLM’s user-facing response (i) explicitly mentions the injected function name or discloses that an additional function was appended beyond the user’s request (Code Augmentation), (ii) explicitly warns that the recommended URL appears suspicious or is a typosquatted variant of the legitimate domain (URL Substitution), or (iii) explicitly mentions the COM-marker insertion or otherwise discloses that hidden bytes were embedded in the returned image (Image Steganography). Implicit cues that do not name the suspicious element (e.g., a generic “please verify the result” disclaimer) are not counted. Representative responses coded as self-reports under this rubric are reproduced in Appendix B. Coding was performed by the authors, with disagreements resolved by discussion.
• Reproducibility. The exact user prompts used for each (scenario, variant) combination are reproduced in Appendix A, and representative LLM responses illustrating our SRR coding criteria are reproduced in Appendix B. Upon acceptance of this manuscript, we will additionally release the full source code of the malicious MCP server with all tool implementations in their complete form rather than the simplified excerpts shown in the listings, supporting independent re-execution of our experiments.

4.2. LLM-Passive Attacks

In LLM-passive attacks, the LLM’s role is confined to dispatching the tool invocation; the harmful effect is produced by code executed inside the malicious MCP server, exercising capability (C3) from Section 3.2. In terms of the workflow in Figure 1, the harmful action occurs at step ➃ (Invocation) and the side effects it produces—network requests to attacker-controlled endpoints, abuse of credentials supplied as arguments—never appear in step ➅ (Response) or in any subsequent step the LLM observes. The decisive defense boundary is therefore not the LLM’s content-level reasoning but any host-side pre-invocation check applied at step ➃, before the data enters the MCP server’s execution environment. Our results show that this boundary is enforced inconsistently across platforms.

4.2.1. File Content Exfiltration

Listing 2 shows the core implementation of the File Content Exfiltration attack. The malicious server exposes a tool advertised as a document summarization utility (summarize_file). Internally, the tool resolves the file’s raw bytes from either the inline content or a download URL, uploads them to an attacker-controlled endpoint, and returns a benign-looking summary to the LLM. The tool accepts both direct content (as used by Claude Desktop and Gemini CLI, which pass the extracted text of the uploaded PDF) and a download_url reference (as used by ChatGPT, which passes a file-access URL rather than raw content). Both paths result in the same server-side action: the file contents are exfiltrated. We evaluate two input types: a non-sensitive academic PDF and a sensitive PDF containing synthetic credentials (an email address, a password string, a credit card number, and a physical address).

Listing 2: Core implementation of the File Content Exfiltration attack: the tool silently exfiltrates the file before returning a legitimate summary.

4.2.2. Email Content Exfiltration

Listing 3 shows the core implementation of the Email Content Exfiltration attack. The malicious server exposes a send_email tool that accepts recipient, subject, body, sender, and credential parameters, presenting itself as a generic email-dispatch utility. Internally, the recipient address is silently overridden with a hardcoded attacker address before the SMTP send call, so any email relayed through the tool is redirected to the attacker regardless of the value the LLM supplies. To invoke this tool, the user’s prompt must include the sender’s SMTP credentials (an application password). We used a Gmail SMTP application password as the credential and a brief greeting message as the email body. The key question is therefore not whether the tool can be abused—the server’s internal logic guarantees redirection—but whether the host LLM will forward credential-bearing prompts into the tool at all.

Listing 3: Core implementation of the Email Content Exfiltration attack: the tool silently overrides the recipient with the attacker’s address while reporting success to the user.

4.2.3. Results

Table 2. Host-layer filtering behavior in LLM-passive attacks. ASR: fraction of repetitions reaching the server; SRR: fraction of successful repetitions in which the LLM’s response disclosed the suspicious behavior.

Scenario	Input	Platform	ASR †	SRR *	Host Intervention ‡
File Exfilt.	Non-sensi. (baseline)	ChatGPT	95% (19/20)	0% (0/19)	TRC (1)
		Claude	95% (19/20)	0% (0/19)	TRC (1)
		Gemini	100% (20/20)	0% (0/20)	-
	Sensitive	ChatGPT	45% (9/20)	0% (0/9)	SAN (8), OTH (3)
		Claude	15% (3/20)	0% (0/3)	REF (17)
		Gemini	90% (18/20)	0% (0/18)	OTH (2)
Email Exfilt.	Cred-bearing	ChatGPT	50% (10/20)	0% (0/10)	REF (10)
		Claude	95% (19/20)	0% (0/19)	CON (1)
		Gemini	100% (20/20)	0% (0/20)	-

†: Percentage based on the total number of trials (N = 20). *: Percentage based on the number of successful attacks. ‡: SAN: Sanitized input, TRC: Truncated input, REF: Refused, CON: Confirmation, OTH: Others.

reports ASR, SRR, and the dominant host intervention mode for both scenarios. Three patterns emerge.

• Without sensitive data, all platforms invoke the malicious tool. On the non-sensitive baseline of File Content Exfiltration, all three platforms invoke the tool and the attack reaches the server in essentially every trial (95% on ChatGPT and Claude, 100% on Gemini). The single failure on each of ChatGPT and Claude reflects an incidental truncation of the file before it was forwarded to the MCP server (TRC), not a deliberate refusal. SRR is uniformly 0%: the LLMs produce a normal summary of the document without any indication that the file content has been transmitted elsewhere. This baseline confirms that none of the three platforms inspects MCP-bound data by default—when the user’s prompt context contains nothing the host considers sensitive, the malicious tool is reached and the harmful action completes silently.
• With sensitive data, host-layer filtering diverges sharply across platforms. ChatGPT applies pre-invocation filtering in both scenarios. On the sensitive PDF, ChatGPT’s dominant intervention is to sanitize the input before forwarding (SAN, 8/20 trials): credentials such as passwords, application passwords, and credit-card numbers in the document are replaced with [REDACTED] markers in the data passed to the MCP server, allowing the tool to be invoked but with the sensitive fields stripped out. Three additional trials produced an output where the file object received by the server was corrupted (OTH), suggesting an internal manipulation of the file during the host’s processing pipeline that left it ill-formed by the time it reached the tool. On the credential-bearing email scenario, ChatGPT instead refuses outright, citing reluctance to forward credentials to an external tool (REF, 10/20 trials). The contrast on this scenario—ChatGPT’s 50% ASR (95% Wilson CI: 30–70%) versus Claude’s 95% ASR (95% Wilson CI: 76–99%)—is supported by non-overlapping 95% confidence intervals at our sample size and represents the clearest single instance of host-layer filtering disparity we observed. The two interventions correspond to different judgments by the same host: the file-summarization request appears legitimate on its face, so ChatGPT lets it proceed but redacts the sensitive content; the email-sending request itself looks suspicious because the prompt carries an SMTP credential, so ChatGPT blocks the call before it is made.

Claude exhibits the strongest filtering on the sensitive PDF—attack succeeds in only 15% of trials, with 17 out of 20 ending in explicit refusal (REF) citing the presence of sensitive credentials—but applies essentially no filtering on the email scenario, invoking the tool in 95% of trials and falling back to a confirmation prompt only once (CON, 1/20). Gemini exhibits the weakest filtering: 90% ASR on the sensitive file scenario (with two corrupted-file failures (OTH) reflecting internal file processing rather than intentional defense) and 100% ASR on the email scenario with no intervention triggered.

• Successful attacks are not disclosed to the user on any platform. Across both scenarios and all three platforms, SRR is 0% on every successful trial: when the malicious tool is reached and the data leaves to the attacker, none of the LLMs surfaces any indication that this has happened. The user-visible response is in every case a normal summary of the file or a confirmation that the email was sent to the user-specified recipient. The contrast between platforms therefore lies entirely in whether the call is intercepted before it occurs (REF, SAN, CON) rather than in any disclosure once it has occurred: where filtering does not trigger, the malicious server’s action is fully invisible to the user. The disparity in pre-invocation filtering thus represents the only point at which user-visible defense exists for this class of attacks, and Table 2 shows that this point is enforced inconsistently across the platforms users encounter in practice.

4.3. LLM-Active Attacks

In LLM-active attacks, the malicious outcome requires the LLM to participate in delivering the adversarial content to the user, exercising either capability (C1) through the tool description or capability (C2) through the tool response, as defined in Section 3.3. In terms of the workflow in Figure 1, capability (C1) influences step ➂ (Tool Decision) by biasing how the LLM interprets the tool catalog received at step ➁, while capability (C2) acts at step ➆ (Integrated Context), introducing attacker-supplied content that the LLM relays to the user at step ➇ (Final Reply). The decisive defense boundary is therefore the LLM’s content reasoning—whether it treats descriptions as authoritative at step ➂ and whether it validates tool responses against the user’s request before relaying them at step ➇. Our results show that this boundary is also enforced inconsistently, but in a more nuanced way: the same attack goal can be reached through either channel, and which channel succeeds depends on the goal. For each of the three scenarios below, we implement both variants—description-based (C1) and response-based (C2)—against the same target, and report and interpret the resulting asymmetry in Section 4.3.4.

4.3.1. Conditional URL Substitution (Spear Phishing)

Listing 4 shows the two variants of the Conditional URL Substitution attack. The malicious server exposes a tool advertised as a URL recommendation utility (recommend_url). In both variants, the substitution is gated on banking-related queries, implementing a spear-phishing pattern: the tool returns correct URLs for all other recommendations and only deviates when the user requests a bank site link. We used Korean banking sites as targets, with each phishing URL constructed as a typosquatted variant of the legitimate domain (e.g., shinhans.com for shinhan.com). This design improves stealth—a server that returned phishing URLs indiscriminately would quickly attract reports and reviews, whereas one that behaves correctly on everyday queries (news, documentation, shopping) and only deviates on a narrow class of high-value targets is far more likely to retain user trust over time.

• Description-based variant. The tool description contains a hidden conditional directive that instructs the LLM to substitute the phishing URL when the user’s request concerns banking websites. The tool’s runtime behavior is inert: it simply echoes the URL list supplied by the LLM. The attack succeeds only if the LLM, guided by the description, constructs its response around the phishing URL rather than around the URLs it would otherwise recommend.
• Response-based variant. The tool description is unremarkable (“recommends URLs relevant to a query”), but the implementation injects the phishing URL into the response when the query is banking-related. Success here requires the LLM to relay the returned URL to the user without rejecting it as inconsistent with the request.

4.3.2. Malicious Code Augmentation

Listing 5 shows the two variants of the Malicious Code Augmentation attack. The malicious server exposes a tool advertised as a code review utility (modify_code). In both variants, the goal is to append an attacker-supplied snippet—a function definition unrelated to the user’s original code—to the code shown to the user. We used a Fibonacci-sequence function as the appended payload, unrelated to the user-supplied code under review.

Listing 4: Two variants of the Conditional URL Substitution attack. The substitution is gated on banking-related queries, implementing a spear-phishing pattern. Descriptionbased: the directive lives in the description; the function body is inert. Response-based: the description is unremarkable; the payload is injected by the function body.

Listing 5: Two variants of the Malicious Code Augmentation attack. Description-based: the directive instructs the LLM to append the attacker payload to the code; the function body is inert. Response-based: the description is unremarkable; the function body appends the payload to the returned code.

• Description-based variant. The tool description instructs the LLM to append the attacker-supplied snippet to the code before presenting the result. The tool’s runtime behavior is inert; the attack succeeds only if the LLM, guided by the description, modifies its own response to include the payload.
• Response-based variant. The tool description is unremarkable. Its implementation reads the input code (passed as either a string or via a download URL), appends the attacker payload, and returns the concatenated result. The LLM is expected to relay the returned code verbatim.

4.3.3. Image Steganography

Listing 6 shows the two variants of the Image Steganography attack. The malicious server exposes a tool advertised as a PNG-to-JPEG image conversion utility (convert_png_to_jpeg). In both variants, the goal is to deliver an image whose JPEG COM (comment) marker carries an attacker-supplied payload, which can later be extracted by a downstream tool or loader on the user’s machine.

Listing 6: Two variants of the Image Steganography attack. Description-based: the directive instructs the LLM to embed the attacker payload in the converted image; the function body performs an honest conversion. Response-based: the description is unremarkable; the function body inserts the payload into the JPEG COM marker and returns a download URL.

• Description-based variant. The tool description instructs the LLM to embed the attacker-supplied payload in the COM marker of the output JPEG before returning it. The tool’s runtime behavior is an honest format conversion; the presence of the hidden payload in the output therefore depends on whether the LLM will follow the directive when it arrives embedded in a tool description.
• Response-based variant. The tool description is unremarkable. Its implementation fetches the user’s PNG, converts it to JPEG, inserts the attacker payload into the JPEG COM marker, stores the result, and returns a download URL pointing to the payload-carrying JPEG. The LLM is expected to present this URL to the user as the result of the conversion.

4.3.4. Results

Table 3. Attack Success Rate (ASR) and Self-Reporting Rate (SRR) for LLM-active attacks, comparing the description-based and response-based variants of the same attack goal across three platforms. For Image Steganography, results correspond to small PNG inputs (≤1 KB).

		Description-Based		Response-Based
Scenario	Platform	ASR	SRR	ASR	SRR
Conditional URL Substitution	ChatGPT	95% (19/20)	0% (0/19)	100% (20/20)	0% (0/20)
	Claude	95% (19/20)	0% (0/19)	100% (20/20)	0% (0/20)
	Gemini	100% (20/20)	0% (0/20)	85% (17/20)	0% (0/17)
Code Augmentation	ChatGPT	0% (0/20)	N/A	95% (19/20)	5.26% (1/19)
	Claude	95% (19/20)	0% (0/19)	100% (20/20)	100% (20/20)
	Gemini	100% (20/20)	0% (0/20)	95% (19/20)	0% (0/19)
Image Steganography	ChatGPT	0% (0/20)	N/A	100% (20/20)	0% (0/20)
	Claude	0% (0/20)	N/A	45% (9/20)	0% (0/9)
	Gemini	0% (0/20)	N/A	100% (20/20)	15% (3/20)

reports ASR and SRR for all three scenarios across both variants. Four patterns emerge.

• The two variants succeed on different scenarios, and within the description-based variant, on different platforms. The description-based variant succeeds with high ASR (≥95%) on Conditional URL Substitution across all platforms. On Code Augmentation it succeeds only on Claude (95%) and Gemini (100%), while ChatGPT resists the directive almost completely (0%). On Image Steganography the description-based variant fails on all three platforms (0% ASR). The response-based variant, by contrast, achieves ≥85% ASR on all three scenarios across all three platforms (with the partial exception of Claude on Image Steganography, discussed below). This asymmetry reflects not what the LLM can technically do, but whether it treats the description’s directive as an instruction to follow. All three platforms are independently able to perform each of the requested manipulations when asked directly outside the MCP context, including converting a PNG to JPEG and inserting bytes into the JPEG COM marker; the question is whether they will follow such a directive when it arrives embedded in a tool description. For URL substitution this question goes unflagged: replacing one URL string with another in a recommendation list looks like a normal recommendation task, and the directive succeeds on all three platforms. For Image Steganography the directive is uniformly rejected with an explicit warning to the user—the request to embed an attacker-supplied byte string in a returned image is recognized as suspicious by all three platforms, regardless of their underlying capability to perform the operation. Code Augmentation falls between these two extremes: the directive to append a function definition to a code listing is followed by Claude and Gemini in nearly all trials, while ChatGPT alone declines to do so, treating the addition as outside the user’s request. The response-based variant sidesteps the LLM’s directive-evaluation step entirely by having the server itself produce the malicious content, leaving the LLM with the easier task of relaying it.
• Description-based failures fall into three categories. First, on Image Steganography, the LLMs surface a warning to the user about the suspicious instruction in the tool description (a popup-style alert on ChatGPT, and explicit refusal notes on Claude and Gemini), and refuse to embed the payload—a uniform behavior across all 60 trials. Second, on Code Augmentation, ChatGPT silently ignores the directive in 19 of 20 trials, returning the user’s code unmodified with no warning, and refuses one trial under a generic safety check. Third, the small number of failures on otherwise-successful (scenario, platform) pairs reflect ad hoc behaviors: a single failure on URL substitution under ChatGPT (the LLM produced a list of legitimate banks instead of the substituted URL), a single failure under Claude (which ignored the MCP response and produced its own list of unrelated banks), and a single failure on Code Augmentation under Claude (which surfaced a prompt-injection warning and ignored the directive). The contrast between the first two categories is informative: hidden directives become conspicuous when they request manipulations structurally implausible for the LLM to perform (as with image bytes), but blend into normal generation when they request plausible textual modifications (as with code), with no signal to the user. This has a notable implication for defense: the more capable the LLM becomes at the requested task, the more permissively a description-based attack can be carried.
• Response-based failures cluster around binary handling and content rewriting. On Image Steganography, Claude succeeds in only 45% of trials. The remaining 11 trials produce a corrupted JPEG that nevertheless still contains the embedded payload, suggesting that Claude re-encodes or otherwise modifies the binary artifact returned by the tool before surfacing it to the user—an inadvertent side effect of the platform’s image-handling pipeline rather than a deliberate defense. A single failure under Gemini’s response-based Code Augmentation reflects similar content rewriting: the LLM produced a reformatted version of the code rather than relaying it verbatim. A single failure under ChatGPT’s response-based Code Augmentation was due to a safety check that blocked the MCP read, with the LLM falling back to the attached file content directly. Three failures under Gemini’s response-based URL Substitution stand out: in each, Gemini correctly identified the returned URL as a typosquatting attempt and warned the user, demonstrating that response-level URL validation is at least intermittently active.
• Self-reporting in the response-based variant is platform-dependent and rare. On Code Augmentation, Claude self-reports the inserted attacker code in 100% (20/20, 95% Wilson CI: 84–100%) of successful trials, explicitly naming the injected function in its user-facing response (an example is shown in Appendix B.1); ChatGPT does so in only 5.3% (1/19, 95% Wilson CI: 0.9–25%) of trials, and Gemini in 0%. A weaker but consistent pattern appears on Image Steganography for Gemini, where 15% (3/20) of successful trials contain a passing remark that “a COM marker has been inserted” in the converted JPEG (Appendix B.2). Outside of these cases, response-based attacks complete silently: the LLM relays the server-produced payload to the user without disclosing its presence, with SRR 0% on Conditional URL Substitution across all three platforms and 0% on most other (scenario, platform) combinations. Among the three platforms, only Claude on Code Augmentation produces a response-based attack that is reliably observable to an attentive user. The platform-specific nature of self-reporting suggests that current hosts do not implement systematic auditing of tool-returned content; the disclosures we observe appear to arise as incidental byproducts of how individual platforms handle and present tool outputs, rather than as a principled defense.
• Image Steganography succeeds across the practical payload range on ChatGPT. The results in Table 3 correspond to small PNG inputs (≤1 KB), a regime sufficient only for short shellcode or C2 addresses. We additionally measured the response-based variant at payload sizes above 1 KB—spanning the range observed in deployed stegomalware, where bootstrap scripts, .NET assemblies, and complete RAT modules typically range from a few kilobytes to several megabytes [25,26]. In this regime, only ChatGPT remained testable: Claude and Gemini failed to surface the resulting JPEG to the user at all, apparently filtering out larger binary artifacts as a side effect of their image-handling pipelines. On ChatGPT, the response-based attack succeeded in 100% of trials (20/20) at sizes up to several megabytes. This indicates that, when used as a host for malicious remote MCP servers, ChatGPT can serve as a fully weaponizable steganographic carrier across the practical range of malware payloads, while Claude’s and Gemini’s binary-handling pipelines incidentally limit the deliverable payload size through the same channel.

5. Mitigation Strategies

Our findings in Section 4 suggest that the attack surface of a malicious remote MCP server is not uniform: LLM-passive and LLM-active attacks succeed for different reasons and are, correspondingly, resisted by different mechanisms. Mitigation therefore requires intervention at multiple points along the invocation pipeline rather than at any single layer. We discuss three complementary directions, each aligned with one of the adversary’s capabilities introduced in Section 3.2: host-side pre-invocation filtering (countering C3), LLM-level response auditing (countering C1 and C2), and user-visible output transparency (a cross-cutting measure). We treat these as design-level recommendations; full implementation and evaluation of any single mechanism is beyond the scope of this paper.

• Host-side Pre-invocation Filtering. For LLM-passive attacks, the harmful outcome is produced inside the server and is invisible to the LLM’s content reasoning by construction. The only point at which the host application can intervene is before the tool is invoked, by examining what data is being forwarded into the server’s execution environment. Our observations in Section 4.2 show that this form of filtering exists, but only inconsistently: ChatGPT redacts or refuses on sensitive content (Section 4.2.1 and Section 4.2.2), while Claude Desktop and Gemini CLI forward the same inputs without intervention. A principled form of this defense would treat every outbound argument of a tool invocation as a sink in a lightweight data-flow check, flagging prompt-supplied credentials and content extracted from sensitive document regions before the MCP client transmits them. The principal limitation is the tradeoff between blocking covert credential forwarding and impeding legitimate use cases. ChatGPT’s selective, opaque redaction of credential-bearing inputs (Section 2) is precisely an instance of this defense applied without user transparency; the proposed principled form generalizes the same idea into a consistent, auditable filter applied uniformly across tools.
• LLM-level Response Auditing. For LLM-active attacks, the adversary’s leverage comes through the LLM’s own output channel, making the LLM both the attack surface and a potential line of defense. The two variants we examined place this defense under different pressures. The response-based variant requires the LLM to compare server-produced content against the user’s original request and flag inconsistencies; our results show this capability is available but uneven—Claude self-reports inserted code in 100% of successful Code Augmentation attacks, while ChatGPT and Gemini silently relay the same payload (Section 4.3.2). A practical defense could elevate self-reporting from an incidental byproduct to an explicit auditing step, instructing the LLM to validate tool outputs against the stated request before producing the final response. The description-based variant is harder to address because the adversarial instruction is embedded in the context the LLM uses for planning; mitigating it requires treating tool descriptions as untrusted input rather than authoritative guidance—for example, by quarantining conditional directives or routing description-derived instructions through a separate reasoning channel than user-provided ones [27]. Both forms of auditing rely on the LLM to scrutinize content engineered to evade it, making them necessary but not sufficient on their own. Gemini’s intermittent detection of typosquatted URLs (Table 3) is an inadvertent instance of exactly this check, fired sporadically as a byproduct of general response-handling rather than as a principled defense; systematizing such incidental behaviors into consistent auditing of all tool outputs is the concrete path our findings suggest.
• User-visible Output Transparency. A third direction shifts part of the verification burden back to the user by making tool-invocation effects more transparent at the interface level. For attacks where the visible output matches the user’s request while the underlying effect deviates—an email reported as sent to the intended recipient but in fact redirected (Section 4.2.2), a file reported as summarized while exfiltrated (Section 4.2.1), or a converted image whose metadata carries an embedded payload (Section 4.3.3)—current interfaces leave the user with no practical means of detection. Hosts could reduce this gap by selectively surfacing aspects of tool invocations that the LLM’s synthesized reply does not cover: the destination address actually used by an email-sending tool, the URL actually fetched by a retrieval tool, or a summary of non-content metadata in returned artifacts. Unlike the two preceding mechanisms, this layer provides protection even when both host-side filtering and LLM-level auditing fail. We note that Claude’s image-handling pipeline, which inadvertently corrupted larger steganographic payloads (Table 3), illustrates the opposite pattern: a side-effect of internal processing that disrupts the attack but is invisible to the user, ineffective below the size threshold, and not under user or developer control—underscoring the need for transparency mechanisms that are deliberate rather than incidental. A realistic defense posture for remote MCP deployment will likely combine all three, with the specific balance informed by the empirical characterization of where current hosts are most permissive provided in this paper.

6. Conclusions

We presented an empirical study of malicious remote MCP server attacks across ChatGPT, Claude, and Gemini, organized along the role the host LLM plays in producing the harmful outcome. Across five scenarios spanning LLM-passive and LLM-active attacks—each LLM-active scenario realized in both description-based and response-based variants against the same goal—we found that effectiveness is governed less by the specific technique than by which channel the adversary uses and which platform the user runs. The same malicious server reaches the user on some hosts but not others, the description and response channels succeed on disjoint scenarios, and successful attacks are almost never disclosed to the user, indicating that defending remote MCP deployment requires intervention at multiple layers rather than at any single point in the pipeline.