When the MCP Server Is the Payload: Attacking MCP at the Implementation Layer

This is Part 1 of a two-part series on MCP security. This part attacks the server itself — sandbox escapes, command injection, and the supply chain. Part 2 assumes everything here is patched and breaks the identity layer instead.

General MCP architecture

Before MCP, connecting a model to external tools meant manual API wiring, plugin interfaces, and agent frameworks (structured tool invocation, but integration left manual). MCP replaces all three with one open, model-agnostic, bi-directional protocol: tools are described and discovered uniformly, so an integration written once interoperates across hosts.

Figure 1: tool invocation with and without MCP. Credit: Hou et al.

Core components of MCP architecture:

1. MCP Host — the AI application providing the execution environment (Claude Desktop, Cursor, an agent runtime). It embeds the client.
2. MCP Client — the intermediary inside the host, holding a one-to-one link to an MCP server. It queries the server’s capabilities, issues invocation requests on the host’s behalf, and processes the server’s responses and notifications.
3. MCP Server — exposes capabilities to the host through the client, and executes operations against external systems.

Figure 2: the workflow of MCP. A user prompt is processed through a series of stages involving intent analysis, tool selection, and API invocation across the MCP host, client, and server. The MCP server provides tools, resources, and prompts that enable interaction with external data sources such as web services, databases, and local files. Credit: Hou et al.

The communication workflow starts with the host querying the MCP server, via the client, to enumerate the tools and operations it exposes. Based on the user’s request, the host selects the most suitable tool and invokes it through the client interface. The server fulfills the request by interacting with the corresponding external system and, upon completion, returns the execution result to the client, which relays it back to the host.

Figure 3: MCP communication workflow between the host, client, server, and external tools.

Server internals. The MCP server carries:

1. metadata (name, version, description — how clients identify it),
2. configuration (source, config files, manifest),
3. a tool list (catalog with I/O formats and access permissions),
4. a resources list (allowed endpoints and their permissions), and
5. prompt templates.

The threat landscape

Hou et al. organize MCP threats into four adversary classes: malicious developer, external attackers, malicious users, and general security flaws. On top of their analysis and grouping of threats, the SlashID team reconstructs the underlying failure at a technical level and, where a known-patched CVE illustrates it, reproduces the vulnerability against its affected pre-patch versions to show the mechanism concretely rather than in the abstract.

Malicious developer — poisoning the tool surface

Tool poisoning

Tool poisoning hides an attack inside a tool’s description in metadata rather than its code: since MCP hosts feed tool metadata directly to the model as trusted context, an attacker can embed an instruction inside a file, then POST it to a remote server that runs silently alongside the tool’s real function, with no signal to the user that anything beyond the stated operation occurred.

A related technique, preference manipulation, doesn’t inject instructions at all; it just biases which tool gets picked among functionally identical options by wording one description with authority language like “the best and most reliable.” Both exploit the same gap: nothing in the protocol separates a description that documents a tool from one that commands the model.

Figure 4: illustrative reconstruction combining tool-poisoning and preference-manipulation examples into a single scenario.

MCP typosquatting

Unlike attacks that manipulate an MCP server’s description or metadata, MCP typosquatting targets the server’s identity. Attackers register deceptively similar server names, relying on users or AI agents to mistakenly select the malicious server instead of the legitimate one. According to UpGuard, four major MCP server registries are currently in use, each presenting a different level of security risk:

1. GitHub MCP Registry — official only, 57 entries, highly moderated.
2. Smithery.ai — 3,500+ servers, only 8% verified.
3. Official MCP Registry — ~1,000 servers, no formal verification yet.
4. MCP.so — 17,000+ servers, unmoderated, high-risk.

Figure 5: illustrative reconstruction of MCP typosquatting.

UpGuard also identified between 3 and 15 unverified lookalike servers for every legitimate brand, representing approximately 10–16% of all servers examined. For example, searching for HubSpot returned nine MCP servers, only one of which was genuine. Inconsistent casing rules make it worse: case-insensitive systems can silently merge a typosquat with the real server, while case-sensitive ones let attackers register brand-name variants outright, since no registry enforces unique ownership.

Rug pulls

A rug pull is a risk where an initially trusted tool’s description, schema, or underlying behavior is silently altered after approval. A user approves a benign-looking tool; weeks later, the provider — or an attacker who’s compromised their server — changes its server-side behavior without touching its name or version string. Since standard MCP clients approve once and never re-verify a tool’s full definition afterward, the modified tool keeps running under the original trust grant. It works because MCP treats a tool’s identity as a static name, not a hash of what it actually does, so nothing forces re-approval when behavior changes but the label doesn’t.

Figure 6: reconstruction of ETDI’s rug-pull prevention flow.

ETDI, a proposed fix, makes tool definitions signed and versioned instead of just named. The client stores the hash and version of what it approved, then re-verifies both on every connection. A legitimate update bumps the version and triggers a fresh approval prompt. An unbumped, silent behavior change fails the hash check outright, and the tool gets blocked. The tool’s identity becomes the hash, not the string.

Command injection (CVE-2025-59536)

Command injection represents malicious logic embedded in an MCP server’s source or config that fires with or without explicit user awareness once loaded. CVE-2025-59536 is a clean instance of that pattern. The vulnerability exists due to a bug in the startup trust dialog implementation that allows malicious code execution before user consent is granted, thus letting attackers achieve arbitrary code execution by tricking users into starting Claude Code in a directory containing malicious project files, bypassing the intended trust dialog security mechanism.

The trust dialog is designed as a security gate requiring explicit consent before project code executes, but due to the implementation flaw, execution occurs before the dialog completes its authorization check — a race condition an attacker wins simply by getting a victim to clone and open a repository.

CVE-2025-59536 reproduced in a controlled lab VM: opening a malicious project directory executes code before the trust dialog can gate it.

External attacker

CVE-2026-21852

A hostile party manipulates a connection before any trust relationship is established. Here, an attacker-controlled repository could include a settings file that sets ANTHROPIC_BASE_URL to an attacker-controlled endpoint, and when the repository was opened, Claude Code would issue API requests before showing the trust prompt, leaking the user’s API key. No filesystem access or stored-secret compromise is needed — just a repository the victim opens.

Figure 7: CVE-2026-21852 — the credentialed request goes out to the attacker endpoint before the trust prompt even appears.

Malicious user

Sandbox evasion (CVE-2025-53109 & CVE-2025-53110)

Both exploit legitimate tool access, not a backdoor or a hijacked handshake. CVE-2025-53110 breaks scope with a naive check where the server used path.startswith(allowed_dir), bypassed by creating /tmp/allowed_dir_evil next to /tmp/allowed_dir. CVE-2025-53109 escalates that into full escape: a crafted symlink can point anywhere on the filesystem and bypass the access enforcement mechanism, enabling reads/writes to files like /etc/sudoers and code execution via cron jobs or Launch Agents. Both were patched in Filesystem MCP Server 2025.7.1.

Figure 8: illustrative reconstruction of CVE-2025-53109 & CVE-2025-53110.

Security flaws — the quiet ones

These flaws do not represent new attack techniques. Instead, they refer to vulnerabilities that remain after a security patch has been released. Even when a CVE is fixed, older vulnerable versions often continue to exist. If someone deploys one of these outdated versions, the same vulnerability is reintroduced. In these cases, attackers do not need to discover a new exploit or perform a sophisticated attack. They simply take advantage of software that is already known to be vulnerable because it was never updated.

All the reproduced CVEs in this research were reconstructed against their specific pre-patch versions in controlled lab environments such as Filesystem MCP Server pre-0.6.3/2025.7.1, mcp-remote pre-0.1.16, and Claude Code pre-1.0.111 — not against current, patched deployments. That distinction matters for how these examples should be read: they demonstrate mechanism, not present-day exposure.

References

[1] X. Hou, Y. Zhao, S. Wang, and H. Wang, “Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions,” arXiv preprint arXiv:2503.23278, 2025. https://arxiv.org/abs/2503.23278

[2] UpGuard, “Typosquatting in the MCP Ecosystem,” UpGuard Blog, 2026. https://www.upguard.com/blog/typosquatting-in-the-mcp-ecosystem

[3] M. Bhatt, V. S. Narajala, and I. Habler, “ETDI: Mitigating Tool Squatting and Rug Pull Attacks in Model Context Protocol (MCP) by using OAuth-Enhanced Tool Definitions and Policy-Based Access Control,” arXiv preprint arXiv:2506.01333, 2025. https://arxiv.org/abs/2506.01333