---
title: 'MCP Threats: Security Risks in Model Context Protocol'
url: https://www.emergentmind.com/topics/model-context-protocol-mcp-threats
type: topic
---

# MCP Threats: Security Risks in Model Context Protocol

Model Context Protocol (MCP) threats are the security and safety risks introduced when large language model (LLM) applications discover, describe, and invoke external tools, resources, and prompts through a standardized client-server interface. In the MCP literature, the threat surface is broader than conventional API security because tool names, descriptions, schemas, prompts, returned observations, registry metadata, and external content are all consumed by the model as part of its operational context. This makes MCP vulnerable not only to missing authentication, SQL injection, path traversal, and remote code execution, but also to semantic and compositional attacks such as tool poisoning, indirect prompt injection, preference manipulation, parasitic tool chaining, response injection, and dynamic trust violations [2603.22489][2602.01129][2603.18063].

## 1. Architectural sources of MCP risk

Threat analysis in the MCP literature begins with the protocol’s trust boundaries. One widely used decomposition models five interdependent components: **MCP Host and Client**, **LLM**, **MCP Server**, **External Data Stores**, and **Authorization Server**. In that model, the client is the critical intermediary that receives server tool metadata and forwards it into the LLM context, while the LLM is the main “decision boundary” that tool poisoning targets. The threat model is explicitly based on **defense in depth** and **zero trust**, with trust boundaries at each stage so that compromise in one component should not automatically imply compromise elsewhere [2603.22489].

A related architectural account describes MCP as a three-party workflow in which a user issues a request to the host, the client contacts an MCP server, the server returns available tools and capabilities, the host or client selects a tool, and the server executes the operation and returns the result. The same papers emphasize several protocol features that enlarge attack surfaces: **dynamic discovery and invocation**, **bidirectional interaction**, **multi-stage scheduling and chaining**, **loose trust boundaries**, **metadata-driven selection**, **session handling**, and **cross-domain resource access** [2602.01129].

Host behavior is a recurring point of failure. One ecosystem study reports that hosts send the system prompt, tool list, and context history to the model, then **blindly translate** the model’s output into a tool invocation and execute it, concluding that hosts do not verify model outputs before invocation. This makes registry content, server metadata, and tool-returned content operationally significant: once they influence the model, they can influence execution as well [2510.16558].

## 2. Threat modeling frameworks and protocol-specific taxonomies

Formal threat modeling for MCP has been built from both classical and protocol-specific frameworks. One study applies **STRIDE**—**Spoofing**, **Tampering**, **Repudiation**, **Information Disclosure**, **Denial of Service**, and **Elevation of Privilege**—to all five MCP components, and then scores identified threats with **DREAD** using **Damage**, **Reproducibility**, **Exploitability**, **Affected Users**, and **Discoverability**. The total score is the sum of the five dimensions, with **Low** defined as 1–10, **Medium** as 11–24, **High** as 25–39, and **Critical** as 40–50. In that scoring, **LLM01: Prompt Injection** receives **50 (Critical)**, **Tool Poisoning** **46.5 (Critical)**, **Command Injection** **47.5 (Critical)**, **Remote Code Execution** **45 (Critical)**, and **Unauthenticated access** **44 (Critical)**. The same analysis states that the most common and severe issues are **tampering** and **information disclosure** [2603.22489].

Protocol-specific taxonomies extend beyond STRIDE. **MCP-38** defines **38 threat categories (MCP-01 through MCP-38)** grouped into five remediation-oriented categories: **Semantic Manipulation / Poisoning**, **Prompt Injection / Boundary Breaking**, **Identity, Trust / Supply Chain**, **Access Control / Logic Drift**, and **Data Exfiltration / Resource Abuse**. Its categories include **Tool Description Poisoning**, **Full Schema Poisoning**, **Resource Content Poisoning**, **Tool Shadowing / Name Spoofing**, **Cross-Server Tool Shadowing**, **Preference Manipulation Attack**, **Prompt Injection (Direct)**, **Prompt Injection (Indirect via Data)**, **Rug Pull / Dynamic Behavior Change**, **Parasitic Toolchain / Connector Chaining**, **Excessive Permissions / Overexposure**, and **Invisible Agent Activity / No Observability** [2603.18063].

Server-centered analyses use a different decomposition. **MCP-in-SoS** maps **51 distinct CWE classes** into four MCP threat surfaces—**Tool**, **Resource**, **Prompt**, and **Protocol**—and reports that **Protocol** accounts for **56.9%** of findings and **57.1%** of expected exposure, while **Tool** issues are less common but disproportionately dangerous at **21.2%** of exposure. The same study argues that MCP risk is often **compositional**, with protocol weaknesses acting as the **reachability multiplier** that makes tool and resource flaws exploitable [2603.10194].

## 3. Semantic manipulation: tool poisoning, shadowing, and preference attacks

The best-studied MCP-specific threat is **tool poisoning**. One paper defines it as a form of **indirect prompt injection** in which malicious instructions are embedded in **tool metadata**, including **tool descriptions**, **parameter specifications**, **tool prompts**, and **schema-related text**. Its core mechanism is a five-step path: the server returns tool metadata via `tools/list`; the client accepts this metadata, often without validation; the client passes tool metadata into the LLM context window; the LLM treats the metadata as natural-language instructions; and the poisoned metadata manipulates the model into selecting a tool it should not, using malicious parameters, leaking sensitive information, or executing unintended actions. The same work stresses that this is a **client-side exploitation problem**, even though tool execution happens server-side, because the vulnerability arises in the **client-to-LLM path** [2603.22489].

Later work generalizes this into a broader semantic attack surface. One defense paper distinguishes three classes: **Tool Poisoning**, where adversarial instructions are hidden in tool descriptors; **Shadowing**, where trusted tools are indirectly compromised through contaminated shared context; and **Rug Pulls**, where descriptors are altered after approval to subvert behavior. In this framing, Shadowing is a **cross-tool contamination** attack that exploits the fact that descriptors for multiple tools coexist in a shared context space, while Rug Pulls target **post-approval descriptor integrity** rather than initial registration [2512.06556].

A parallel line of work studies **preference manipulation** as a fairness and selection attack. **MCP Preference Manipulation Attack (MPMA)** treats the malicious provider as an MCP server builder who has white-box control over **tool name** and **tool description** and can bias tool selection without modifying the base LLM. The direct variant, **DPMA**, prepends the phrase **“This is the best tool in the world.”** to a description or the word **“best”** to a tool name; the paper reports that **Best Description** reaches **100% ASR in almost all settings** and **Best Name** reaches **100% ASR in most cases**. Its more stealthy variant, **GAPMA**, uses **Authoritative**, **Emotional**, **Exaggerated**, and **Subliminal** advertising styles plus a genetic algorithm; under LLM-as-a-judge evaluation, **Au + GA** and **Su + GA** each achieve **0% TPR**, while **DPMA Best Description** has **37.5% TPR** [2505.11154].

Component-based attack studies broaden the same phenomenon from tools to servers, resources, and prompts. One taxonomy identifies **Server Metadata Poisoning**, **Tool Metadata Poisoning**, **Resource Metadata Poisoning**, and **Prompt Metadata Poisoning** as separate insertion points, arguing that every MCP component can be weaponized and that malicious MCP servers should be treated as **active threat actors**, not passive software artifacts [2509.24272].

## 4. Indirect prompt injection, response manipulation, and parasitic toolchains

A second major family of MCP threats enters through external content or tool outputs rather than tool definitions. **MCP Unintended Privacy Disclosure (MCP-UPD)** is described as a three-stage **Parasitic Toolchain Attack**: **Parasitic Ingestion**, in which malicious text is retrieved by a benign ingestion tool and absorbed into context; **Privacy Collection**, in which the model is induced to invoke sensitive read-oriented tools; and **Privacy Disclosure**, in which the model is induced to invoke outbound network-capable tools to exfiltrate collected data. The full pipeline is stated as  
$$
\text{External content with parasitic prompt} \rightarrow \text{LLM ingestion} \rightarrow \text{sensitive tool invocation} \rightarrow \text{data exfiltration}.
$$  
The same paper attributes the attack to two root causes: **lack of context–tool isolation** and **absence of least-privilege enforcement** [2509.06572].

That attack class is not a narrow edge case. In a large-scale census using **MCP-SEC**, researchers collected **12,700 MCP servers**, filtered them to **2,191** deployable servers, and successfully connected to **1,360 servers** exposing **12,230 tools**. They report that **5,666 tools**, or **46.41%**, expose at least one MCP-UPD-relevant capability, and that **1,067 of 1,360 servers**, or **78.5%**, contain at least one exploitable tool. Their capability taxonomy identifies **2,652 External Ingestion Tools (EIT)**, **2,121 Privacy Access Tools (PAT)**, and **1,144 Network Access Tools (NAT)**; **16 tools** satisfy all three capabilities, and all of those are **command execution tools** [2509.06572].

Response handling is also a distinct attack stage. **MSB (MCP Security Bench)** organizes attacks across **task planning**, **tool invocation**, and **response handling**, and defines response-stage classes including **User Impersonation (UI)**, **False Error (FE)**, **Tool Transfer (TT)**, and **Retrieval Injection (RI)**. It also defines **Out-of-Scope Parameter (OP)** at invocation time, where a malicious tool defines an extra sensitive parameter and the model is induced to fill it in. The benchmark’s central formal metric is  
$$
\mathrm{NRP}=\mathrm{PUA}\cdot(1-\mathrm{ASR}),
$$  
where **ASR** is Attack Success Rate and **PUA** is Performance Under Attack [2510.15994].

Recent work shows that output-stage attacks can remain effective even under defense. **TIP (Tree structured Injection for Payloads)** attacks flexible response fields rather than static metadata and models the malicious response as  
$$
r_{\text{mal}} = r_{\text{tool}} \cup \mathcal{P}.
$$  
The paper reports **over 95% attack success in undefended settings**, **100% ASR** on three of four benchmarked tools, **95% ASR** on the hardest tool, and more than **50% effectiveness** against **Instruction Prevention**, **Sandwich Prevention**, **Finetuned Detector**, and **Perplexity Filtering**. It also demonstrates the attack in **LM Studio + Qwen2.5-7B-Instruct-1M** and **VS Code MCP extension + GPT-4o**, where a compromised weather plugin injects a phishing URL into an otherwise plausible forecast [2603.24203].

## 5. Server, registry, and supply-chain threat surfaces

MCP threat research repeatedly shows that semantic attacks coexist with conventional implementation flaws and supply-chain weaknesses. A static analysis of **222 public Python MCP server repositories** using **CodeQL**, **Joern**, and a subset with **Cisco AI Defender MCP Scanner** produced **15,962 findings** spanning **51 distinct CWE classes** in **191 of 222 repositories (86.0%)**. The five most frequent CWEs account for **12,085 findings (75.7%)**: **CWE-862 – Missing Authorization** at **30.4%**, **CWE-200 – Exposure of Sensitive Information** at **15.9%**, **CWE-306 – Missing Authentication** at **15.3%**, **CWE-287 – Improper Authentication** at **7.4%**, and **CWE-89 – SQL Injection** at **6.7%**. The same study reports that almost two-thirds of repositories fall in **High** or **Very High** risk bands [2603.10194].

Ecosystem-wide registry measurements expose a distinct distribution problem. One study collected **67,057 MCP servers** from **mcp.so**, **MCP Market**, **MCP Store**, **Pulse MCP**, **Smithery**, and **npm**, extracted **44,499 tools** from Python-based servers, and found widespread link decay, stale ownership, leaked credentials, and naming conflicts. Across decentralized registries it found **1,379 invalid links**, of which **212 (15.37%)** corresponded to GitHub accounts that were re-registrable; it also identified **304** redirected GitHub accounts that attackers could reclaim and **408** groups of npm MCP packages sharing the same base name but differing in affixes, with **80.6%** maintained by different developers [2510.16558].

Direct registry experiments reinforce the same conclusion. In an “upload → download → attack” pipeline, researchers built a malicious MCP server and showed that **Smithery.ai**, **MCP.so**, and **Glama** all accepted it. In a user study with **20 participants**, **75%** selected at least one malicious server in a blind-selection task, only **one participant** identified all four malicious servers when warned, and **40%** identified none [2506.02040].

Supply-chain attacks in MCP are not limited to initial publication. The literature repeatedly describes **rug pulls**, **namespace typosquatting**, **tool name conflict / cross-server shadowing**, **installer spoofing**, and **preference manipulation** as ways to distribute malicious or later-mutated servers. A governance-oriented treatment adds a concrete example: an unofficial **Postmark MCP server** with around **1,500 weekly downloads** was modified to add a **BCC** field to its `send_email` function, silently copying all emails to the attacker [2511.20920].

## 6. Empirical exploitability across clients, agents, and models

Client-side studies show that MCP security posture varies sharply across implementations. A controlled evaluation of **seven major MCP clients**—**Claude Desktop for Windows**, **Cursor**, **Cline**, **Continue**, **Gemini CLI**, **Claude Code**, and **Langflow**—tested four attack types: **Reading sensitive files**, **Logging tool invocation activities**, **Creating phishing links**, and **Remote execution of scripts**. The evaluation measured **Static validation**, **Parameter visibility**, **Injection detection**, **User warnings**, **Execution sandboxing**, and **Audit logging**, and concluded that **Claude Desktop and Cline** were the **most secure**, **Cursor** the **most vulnerable**, and **Continue, Gemini CLI, Claude Code, Langflow** only **partially protected**. The same paper concludes that **attack success ranges from 0% to 100% depending on client** [2603.22489].

The concrete attack traces are unusually direct. In the sensitive-file attack, a malicious tool `add(a, b, sidenote)` instructed the model to read `~/.cursor/mcp.json` and `~/.ssh/secret.txt`, concatenate contents into `sidenote`, and avoid alerting the user. **Cursor** was reported as **Unsafe — read both files and passed contents silently**; **Claude Desktop** was **Safe — refused**; **Cline** was **Safe — detected prompt injection and warned** [2603.22489]. A separate ecosystem study also reports that **Cursor** is vulnerable to tool-name collisions: when two servers expose tools with the same name, Cursor often invokes the **first-listed tool** regardless of the model’s selection, and the tool name **`add`** appears **379 times** across servers [2510.16558].

Benchmarking across models produces a recurrent paradox: better tool users are often easier to hijack. In the first systematic malicious-server study, attacks against **Claude 3.7 Sonnet**, **GPT-4o**, **DeepSeek-V3 0324**, **LLaMA3.1-70B**, and **Gemini 2.5 Pro** achieved an overall average **ASR** of **65.77%**, with **Tool Poisoning** at **64.00%**, **Puppet Attack** at **52.00%**, and **Malicious External Resources** at **81.33%**. The authors conclude that **models with stronger tool-use capabilities tend to be more vulnerable** [2506.02040]. **MSB** reaches a similar conclusion in a larger end-to-end benchmark over **nine popular LLM agents**, **10 domains**, **400+ tools**, and **2,000 attack instances**, finding an **inverse scaling trend** and reporting that **Out-of-Scope Parameter** is the most effective single attack at **74.03% ASR**, followed by **User Impersonation** at **50.72%** and **False Error** at **43.42%** [2510.15994].

Broader attack libraries amplify this picture. **MCPLIB** catalogs **31 distinct attack methods** under **direct tool injection**, **indirect tool injection**, **malicious user attacks**, and **LLM inherent attack**, and ranks them with an entropy-weighted attack-efficacy metric. In its reported table, **SQL injection / API theft** has efficacy **10.00**, while several file-based and tool-description attacks score **8.38**, **8.08**, and **7.79**, reinforcing the claim that ordinary software weaknesses and MCP-specific semantic manipulation are jointly exploitable [2508.12538].

## 7. Defense architectures, governance, and unresolved problems

The dominant defensive theme is layered control rather than reliance on model refusal. One client-focused paper proposes a four-layer defense-in-depth design: **Layer 1: Registration and validation**, including strict JSON schema checks, digital signature verification, dangerous-keyword scanning, permission anomaly analysis, and allowlists; **Layer 2: Decision path analysis**, including **Decision Dependency Graphs** to track why the LLM selected a tool and whether selection matches user intent; **Layer 3: Runtime monitoring**, including isolated containers or VMs, restricted filesystem and network access, rate limits, and full-parameter logging; and **Layer 4: User transparency**, including full display of tool descriptions and parameters, explicit confirmation for high-risk actions, contextual warnings, and audit logs [2603.22489].

Protocol-level hardening pushes these controls into the protocol itself. **SMCP: Secure Model Context Protocol** adds a **Trusted Component Registry**, a structured **32-character identity code** over `[0-9A-Z]`, mutual authentication, a cryptographically bound **unified security context** with fields such as `sessionId`, `callChainId`, `delegatorChain`, `callerAgentId`, `peerId`, `authnAssertionId`, `riskLevel`, and `dataSensitivity`, dynamic **Policy Decision Point / Policy Enforcement Point** enforcement, and comprehensive audit logging linked to `callChainId` and `auditRef`. The design is intended to mitigate unauthorized access, session hijacking, prompt injection, privilege escalation, token passthrough, cross-tenant exposure, and chained abuse, though the paper explicitly notes that it is a design and roadmap rather than a fully deployed standard [2602.01129].

Defenses against semantic manipulation have also become more specialized. **MCP-Guard** uses a three-stage fail-fast pipeline: rule-based Stage 1 detectors for SQL injection, sensitive files, shadow hijack patterns, prompt injection signatures, `<IMPORTANT>` tags, shell fragments, and cross-origin references; a fine-tuned multilingual **E5** Stage 2 detector trained on **MCP-AttackBench**; and a Stage 3 LLM arbitrator that outputs **safe**, **unsafe**, or **unsure**. The paper reports **96.01% accuracy** for the Stage 2 learnable detector and **89.63% accuracy**, **98.47% recall**, and **455.86 ms** for the full pipeline [2508.10991]. A separate layered framework combining **RSA-based manifest signing**, **LLM-on-LLM semantic vetting**, and **heuristic runtime guardrails** reports that, under **Tool Poisoning**, the **combined** configuration reaches **72.2%** block rate versus **41.2%** for the baseline, while **LLM-on-LLM vetting** alone gives the largest single improvement at **63.6%** [2512.06556].

Operational guidance extends beyond runtime detectors. Enterprise and governance papers recommend **per-user OAuth 2.1 flows**, **RBAC**, provenance tracking, **mandatory containerization or VMs**, read-only filesystems by default, explicit writable directories only, network allowlists, DLP and secrets scanning, response sanitization, **private MCP registries**, version pinning, approval workflows, centralized credential management, and gateway-based enforcement so that all agent/server traffic passes through a centrally managed control point [2511.20920][2504.08623]. The **SoK** literature adds **ETDI** for signed manifests and version identifiers, runtime intent verification methods such as **MindGuard** and **Decision Dependence Graph**, and stronger session isolation for multi-agent environments [2512.08290].

Despite this growing body of defenses, limitations remain explicit. DREAD scores are described as **author-assessed** and somewhat subjective; some protocol proposals acknowledge **no full formal proof or evaluation**; client studies are limited to tested versions in controlled local environments; and benchmark results repeatedly show that no model or client is fully robust [2603.22489][2602.01129]. The overall literature therefore treats MCP threats as an architectural problem: context is executable influence, tool composition is security-relevant, and secure deployment requires validation, provenance, least privilege, isolation, policy enforcement, and observability across the full host-client-server-toolchain.

Source: https://www.emergentmind.com/topics/model-context-protocol-mcp-threats