Your MCP Tool Descriptions Are Executable Code
A developer on your team installs an MCP server that adds a single helper tool. They read the code. It is forty lines, it does what it says, and there is no network call in it that shouldn’t be there. It gets approved.
The next morning your agent starts prefixing its shell commands with something nobody wrote, and the SSH key on that laptop is on someone else’s server.
Nothing in the code did that. The payload was in the tool’s description — a string field the developer never thought to read, because in every other system they have ever worked on, descriptions are documentation. In MCP, descriptions are the part the model actually obeys.
This is not a hypothetical. It is a measured attack class with success rates in the literature, a named taxonomy, assigned CVEs, at least one confirmed in-the-wild malicious server, and a self-replicating worm proof-of-concept. Below: what the scan data says about exposure, what the attack numbers actually are, and — the part most security content skips — the measured evidence that the defenses most teams are buying do not work.
The trust boundary nobody drew
MCP’s design has one property that generates most of its security behaviour. When a client connects to a server, it calls tools/list. The server returns tool names, schemas, and descriptions. Those descriptions go directly into the model’s context window.
There is no privilege separation between that text and your system prompt. The model does not have a mechanism to treat one as instructions and the other as data, because there is no such mechanism in a single token stream. OWASP states this plainly: LLMs collapse the data plane and the control plane into a single channel, where system prompts, user requests, and retrieved content are all processed identically.
So the description field is not documentation. It is an instruction channel exposed to whoever wrote the server.
Trail of Bits named the resulting attack line jumping in April 2025 and made the sharp observation that it defeats two of MCP’s core security assumptions at once:
- Invocation-based control — the assumption that a tool can only cause harm when explicitly called. Line jumping lands at discovery time. The tool is never invoked.
- Cross-server isolation — the assumption that a compromised server cannot affect others. All descriptions share one context window.
Their phrase for it is worth keeping: a security system that activates only after intruders have gained access.
Conventional model MCP reality
──────────────────── ──────────────────────
code = executable code = executable
description = docs description = executable
approval gates invocation injection lands pre-invocation
server A ≠ server B one shared context window
What the scans actually found
Before attack rates, exposure. Two independent 2026 measurements converge.
A May 2026 study of the remote MCP ecosystem identified 7,973 live remote MCP servers and found 40.55% expose their tools with no authentication at all — roughly 3,200 servers where tool invocation requires nothing.
Censys, scanning from a different angle, identified 12,520 Internet-accessible MCP services across 8,758 unique IP addresses as of 28 April 2026, spanning 56 countries and 425 autonomous systems. Their explanation for the unauthenticated majority is structural rather than accidental: the protocol does not require authentication or authorization by default.
The authentication picture among servers that do implement OAuth is worse than the unauthenticated one, in a sense:
Remote MCP servers with OAuth (n=119 testable)
──────────────────────────────────────────────
Servers with ≥1 auth flaw 100% ████████████████████
Affected by DCR vulnerabilities 96.6% ███████████████████
Total flaws detected 325
Every tested server had at least one flaw. Dynamic client registration was the dominant weakness class.
And most deployments are running a specification that predates the current hardening: Censys found 89.4% of observed services (11,189) on protocol version 2025-03-26.
On the implementation side, VIPER-MCP (arXiv:2605.21392) took a taint-style approach across 39,884 real-world open-source MCP server repositories and found 106 zero-day vulnerabilities, all confirmed through end-to-end exploit traces rather than left as static alerts, with 67 CVE IDs assigned at submission. Their threat model explains why the hit rate is high: MCP tool handlers expose privileged sinks — shell execution, network access, filesystem manipulation — so an implementation flaw creates a direct path from natural-language input to a security-sensitive sink.
The number that should change your threat model
Exposure data tells you how many doors are unlocked. It does not tell you whether the attack works on a well-configured system. That is what MCPTox measured.
MCPTox (arXiv:2508.14925) is the first systematic large-scale evaluation of tool poisoning in realistic settings — prior evidence was isolated demos. It is built on 45 live, real-world MCP servers and 353 authentic tools, generating 1,312 malicious test cases across 10 risk categories, evaluated against 20 prominent LLM agents.
Peak attack success rate: 72.8%, against o1-mini.
That number is bad. This one is worse:
| Metric | Value |
|---|---|
| Highest attack success rate | 72.8% (o1-mini) |
| Highest refusal rate, any agent | under 3% |
Under three percent. The best-refusing agent in the study — Claude 3.7 Sonnet — declined these attacks less than 3% of the time. The paper’s explanation is the important part: the attacks use legitimate tools for unauthorized operations. There is no obviously harmful request for alignment to catch. The agent is asked to use a real tool it is allowed to use, for a purpose the user did not intend.
Safety alignment is not a control here. It was never pointed at this problem.
Then there is the finding that should reorganize how you think about model upgrades:
More capable models are often more susceptible, as the attack exploits their superior instruction-following abilities.
Instruction-following is the capability being attacked. Improving it improves the attack. If your mitigation plan includes “wait for better models,” the measured direction of travel is against you.
The taxonomy, and why the names matter
The ecosystem has converged on distinct named attack classes. They have different entry points and therefore different defenses, which is why lumping them together as “prompt injection” produces bad mitigation plans.
| Attack | Entry point | Fires when | Primary defense |
|---|---|---|---|
| Tool poisoning | Tool description metadata | Discovery (tools/list) | Description pinning, pre-model scanning |
| Line jumping | Tool description metadata | Before any invocation | Same — approval gates are too late |
| Rug pull | Description mutated post-approval | On reconnect | Trust-on-first-use + change diffing |
| Tool shadowing | Malicious server’s description | Alters use of a trusted tool | Cross-server dataflow boundaries |
| Sampling injection | Server-initiated LLM completions | On sampling request | Strict templating, per-server sampling ACL |
| Parasitic toolchain | External data the agent ingests | Normal operation | Context-tool isolation, least privilege |
A few of these deserve specifics, because the demonstrations are more alarming than the labels suggest.
Tool shadowing breaks the mental model most teams have. Invariant Labs showed a malicious server’s add tool — a tool that adds numbers — whose description altered the agent’s use of a separate, trusted send_email tool, redirecting all mail to an attacker address. The trusted server was not compromised. It did not need to be. MCP trust does not isolate per server.
Sampling injection exploits MCP’s sampling feature, where a server requests LLM completions back through the client. Unit 42 found it relies on an implicit trust model with no built-in security controls, and demonstrated three escalating proofs-of-concept: resource theft where the client generates extensive hidden content the user is never shown, persistent conversation hijacking where injected instructions survive across turns, and covert tool invocation where a malicious summarizer caused the model to secretly call a writeFile tool without consent.
Parasitic toolchain attacks are the one to watch architecturally. The IEEE S&P 2026 paper “Parasites in the Toolchain” (arXiv:2509.06572) ran the first large-scale empirical security census of the ecosystem — 12,230 tools across 1,360 servers — and characterized an attack where the adversary never touches the user. They plant instructions in external data the agent ingests during normal operation, which then chains individually-legitimate tools through three phases: parasitic ingestion, privacy collection, privacy disclosure. Their root-cause finding is the one to internalize:
MCP lacks both context-tool isolation and least-privilege enforcement.
That is an architectural gap, not an implementation bug. No amount of careful server authoring closes it.
It stopped being theoretical
The first malicious server in the wild. In September 2025, Koi Security identified postmark-mcp on npm — a package that shipped 15 clean versions building legitimacy before version 1.0.16 added a single line inserting a BCC recipient into every outbound email routed through it. The malicious code persisted through 1.0.18. Published 15 September 2025, removed 25 September 2025, downloaded roughly 1,500 times weekly. OWASP’s incident tracker independently corroborates it as the first in-the-wild malicious MCP server on npm.
Two corrections, because this incident is routinely misreported. It is a 2025 event, not 2026. And no CVE was ever assigned to it — if you see one cited, it is fabricated. Vendor estimates of affected organizations and daily exfiltrated volume were derived from assumed usage rates applied to download counts, not measured telemetry, and should be cited as estimates or not at all.
The supply-chain CVE cluster. OX Security’s April 2026 advisory documented a systemic pattern: applications passing unsanitized, non-allowlisted command and argument values directly into StdioServerParameters, which the OS then executes as a subprocess. The advisory enumerates 12 assigned CVEs across distinct AI and agent projects — LiteLLM, Agent Zero, Jaaz, Langchain-Chatchat, Upsonic, Flowise, DocsGPT, GPT Researcher, LangBot, Fay, Bisheng.
One correction worth making, because the summary circulating says all twelve are Critical: ten are Critical and two are High in OX’s own severity column — CVE-2026-30625 (Upsonic) and CVE-2026-40933 (Flowise) are rated High.
The prompt-injection-to-RCE chain. CVE-2026-30615, published 15 April 2026 and last modified 17 June 2026, is the cleanest published example of the full chain. In Windsurf 1.9544.26, processing attacker-controlled HTML content causes unauthorized modification of the local MCP configuration and automatic registration of a malicious MCP STDIO server — arbitrary command execution with no further user interaction, and the malicious config persists.
It carries a CISA-ADP CVSS 3.1 base score of 8.0 High, vector AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H. Note AV:L — despite the “remote attacker” framing in the description, the scored attack vector is local. It is classified CWE-77, command injection. NVD is framing prompt injection as a classical command-injection weakness rather than a novel AI class, which has real consequences for how these bugs get triaged.
Active exploitation of exposed instances. OWASP’s Q1 2026 round-up documented CVE-2025-59528, RCE in Flowise reachable via CustomMCP configuration, with 12,000–15,000 instances exposed online when active exploitation was discovered on 7 April 2026.
The worm. AgentWorm (arXiv:2603.15727) demonstrates the first self-replicating worm against a production-scale agent framework: a single message triggers a fully autonomous infection cycle that hijacks the victim’s core configuration for persistence across restarts, executes a payload on each reboot, and propagates to every newly encountered peer agent. 63% aggregate attack success rate across five LLM backends, three infection vectors, and three payload types, with sustained multi-hop propagation. It targets OpenClaw, an open-source platform with over 40,000 active instances.
The ecosystem measurement in that paper is the sentence that should end the “we’ll deal with it later” conversation:
The critical controls capable of breaking the infection loop are not enabled in any of the observed deployments.
Not “rarely enabled.” Not “under-configured.” Not in any of them.
Reconnaissance is live. As of July 2026, opportunistic internet-wide scanning for exposed MCP infrastructure is confirmed. A single small web host’s 14-day logs recorded roughly 200 MCP and AI-agent reconnaissance requests, with the MCP handshake category alone arriving from 49 distinct source IPs. The probes are protocol-aware, sending correctly formed MCP initialize handshakes with real protocol versions in valid JSON-RPC 2.0 bodies — and specifically requesting AI-assistant credential paths like /.claude/mcp.json, /.cursor/mcp.json, and /.claude/.credentials.json.
Somebody is enumerating this attack surface at internet scale, today.
Why the defenses you are buying do not work
This is the section that matters, and it has better evidence behind it than most of the field.
Input filtering and classifiers
The strongest result here is an October 2025 study that systematically tuned general optimization techniques — gradient descent, reinforcement learning, random search, human-guided exploration — against 12 recent defenses and bypassed most of them at above 90% attack success.
The line that should be printed on a poster:
The majority of defenses originally reported near-zero attack success rates.
The bypassed set spans four categories and includes the commercially deployed filtering and classifier products: Protect AI’s detector, PromptGuard, PIGuard, Google Model Armor, plus secret-knowledge detectors Data Sentinel and MELON.
Corroborating evidence from two independent directions:
Study Defenses broken Attack success
────────────────────────────────────────────────────────────────
Adaptive optimization (2025) 12 >90% for most
NAACL 2025 Findings 8 >50% on each
Guardrail evasion (2025) 6 up to 100%
That third row tested six production guardrails including Microsoft Azure Prompt Shield and Meta Prompt Guard, achieving up to 100% evasion while preserving the payload’s adversarial effect. It also showed attackers can raise success against black-box hosted classifiers by computing word-importance rankings on offline white-box surrogates — so a closed, hosted detector buys no security by obscurity.
The structural reason these fail, stated in the first paper: the detector is itself a neural network, so an adversary can fool the classifier and the target model simultaneously. You did not add a security boundary. You added a second model to attack.
There is also a measurement explaining why keyword and pattern approaches specifically underperform. Unit 42’s analysis of indirect prompt injection observed in the wild found payload construction breaks down as:
Social engineering (natural language) 85.2% █████████████████
JSON / syntax injection 7.0% █
Multi-lingual instructions 2.1% ▌
Across 22 distinct techniques identified in the wild. The overwhelming majority of real payloads are plain persuasive English. There is no syntax to pattern-match, because the attack is semantics.
Human-in-the-loop approval
Weaker than assumed, for two independent reasons.
Timing kills it first: line-jumping attacks land at discovery, before any invocation-approval gate exists to fire. There is nothing to approve.
Human factors kill what remains. Trail of Bits argues approval degrades into “human-as-the-rubber-stamp” because users cannot meaningfully evaluate modifications in unfamiliar technical domains, and automated execution workflows bypass real review. Their own defensive tool documents the same ceiling honestly: frequent legitimate server updates induce alert fatigue that can cause users to approve malicious changes.
Safety alignment
Already covered, but worth restating as a defense claim: under 3% refusal in MCPTox across 20 agents. Alignment is oriented toward refusing harmful requests. Tool poisoning issues permitted requests against legitimate tools.
Sandboxes and allowlists
Better than the above — these are containment, which is the right category — but not airtight. OWASP cites CVE-2026-22708 (Cursor allowlist bypass, January 2026) and CVE-2025-59532 (Codex CLI sandbox boundary bypass), with the sharp framing that sandboxes and allowlists whose assumptions were calibrated for human operators become exploitable when the agent can influence its own containment environment. An audit referenced as IDEsaster reportedly found vulnerabilities in 100% of tested major AI coding IDEs.
What actually reduces risk
Containment, not detection. The evidence base points one direction and it is not the direction most budgets go.
The best-measured defense family is out-of-band enforcement — external policy engines rather than model training. Progent cut mean attack success on AgentDojo roughly sixfold, 25.8% to 4.2%, with Qwen2.5-7B. That is a real, large improvement.
It is also not elimination. Under adaptive, attacker-aware evaluation rather than the static benchmark, a hand-crafted template attack still achieved 2.6%. The June 2026 paper making this point argues that existing evaluations of the whole out-of-band family — CaMeL, FIDES, Progent, RTBAS, FORGE — rely on static benchmarks that systematically overstate efficacy, and the authors are careful to characterize their own result as a single small-scale data point with stronger white-box attacks untested.
Take that seriously in both directions. Out-of-band enforcement is the best-evidenced thing available and you should design assuming a low-single-digit leak rate rather than a closed door.
Concretely, in rough order of value per unit of effort:
- Pin tool descriptions on first use; diff on every reconnect. This directly defeats rug-pull mutation, which is otherwise invisible. Trail of Bits’
mcp-context-protectorimplements exactly this: a new server’s config is untrusted and all features blocked until a human approves. Treat every modified field — descriptions, server instructions — as a fresh injection vector. - Default-deny outbound egress. This is the highest-leverage control on the list, because it breaks the impact of an injection you failed to prevent. An agent that has been successfully hijacked but cannot reach an attacker endpoint has leaked nothing. OWASP’s ASI02 guidance centers exactly here: isolated execution sandboxes plus outbound allowlists denying all non-approved destinations.
- Scope credentials per server. Never pass a shared token through to MCP servers. Token passthrough turns any single compromised server into a confused deputy holding everyone’s authority.
- Adopt the 2026-07-28 specification. Shipping 28 July 2026, it requires clients to validate the
issparameter on authorization responses per RFC 9207, mitigating OAuth mix-up attacks that are more prevalent in MCP’s single-client-many-server pattern. It binds registered credentials to the issuing authorization server and forces re-registration on migration, and adds OpenID Connectapplication_typedeclaration during dynamic client registration. Given that 96.6% of tested OAuth servers had DCR vulnerabilities and 89.4% of deployments run a 2025 spec, this is the single highest-value version bump available. - Sanitize
StdioServerParametersinputs against an allowlist. This is the concrete root cause behind the 12-CVE cluster. It is ordinary command-injection hygiene, and it is being skipped ecosystem-wide. - Strip ANSI escape codes from tool output. A confirmed obfuscation vector used to hide injected instructions from human reviewers.
mcp-context-protectorreplaces the escape character with the literal stringESC. - Log tool descriptions, not just tool calls. If your observability captures invocations but not the descriptor text that entered context, you cannot reconstruct a line-jumping incident after the fact. Most agent tracing setups have this gap.
Where the numbers are weak
Being straight about evidence quality, because a lot of MCP security content is not.
The postmark-mcp blast radius is an estimate, not telemetry. Roughly 300 affected organizations and 3,000–15,000 daily exfiltrated emails come from applying an assumed 20% active-usage rate to download counts. Cite the incident, not those numbers.
CVE counts undercount the real surface, structurally. OWASP’s Q1 2026 round-up analyzed 8 major AI security incidents from 1 January to 11 April 2026 and found only one carried a formally assigned CVE. Their attribution: most agentic security events arise from misconfiguration, design flaws, supply-chain weaknesses, and prompt injection rather than discrete code defects. They also explicitly state their methodology is a curated consolidation and must not be cited as prevalence or base-rate statistics.
Adoption survey data is thin and conflicting. The most-cited enterprise figure — 11% of respondents building or using MCP servers in production, with 64% naming security as the top blocker — comes from a December 2025 survey of 300 senior technical leaders, 78% US-based. Another widely-quoted survey reports 17% production usage from 92 self-selected respondents, and its own embedded page metadata contradicts its stated methodology by describing 292 developers. Treat all of these as directional.
Server population counts disagree by an order of magnitude — 1,412, 7,973, 12,520, 17,000+ — because they measure different things: publicly discoverable versus internet-reachable versus publicly listed. Always cite which.
Specific numbers I could not verify. The NSA’s May 2026 MCP guidance is real (U/OO/6030316-26), but the primary PDF returned 403 and its contents are known here only through secondary summaries; it also appears to be NSA-only, not the NSA/CISA joint product it is often described as. Notably, it recommends input screening, which sits in tension with the adaptive-attack evidence above.
Predictions
Clearly marked as predictions. None of this is established.
Prompt injection will not be solved at the model layer, and the industry will stop trying by 2027. The evidence is already one-sided — adaptive attacks break detection-based defenses at above 90% while their authors reported near-zero — and the data-plane/control-plane collapse is architectural. Expect investment to shift decisively toward capability-based containment.
Expect a real, disclosed agent worm incident. AgentWorm is a proof-of-concept at 63% success against a platform with 40,000+ instances, and the controls that break the loop are enabled nowhere. The gap between that and an incident is motivation, not capability.
CWE-77 framing will become a problem. Triaging prompt-injection chains as classical command injection routes them to teams whose playbooks assume deterministic input validation. That mismatch will produce a notable mis-triaged incident.
MCP registries will grow mandatory description-pinning and provenance. It is the npm story with a faster clock, and postmark-mcp was the first data point rather than the last.
The takeaway
The single most useful reframe: the tools/list response is untrusted input that arrives with instruction-level authority. Everything else follows from taking that seriously.
Your code review does not cover it. Your classifier does not catch it — that is measured, repeatedly, against commercial products. Your approval gate fires too late. Your model’s safety training refuses under 3% of the time, and upgrading to a more capable model makes the attack work better, not worse.
What is left is containment: pin the descriptions, deny the egress by default, scope the credentials, and assume a few percent gets through anyway.
FAQ
What is tool poisoning in MCP?
Tool poisoning is an attack where malicious instructions are embedded in an MCP tool’s description or metadata rather than in its code. When a client connects to a server, the tools/list response is inserted directly into the model’s context window, and the model reads those descriptions with the same authority as your system prompt. The critical property is that the tool never has to be invoked. Trail of Bits named this variant line jumping and demonstrated that a server can alter model behaviour purely at discovery time, before any approval gate or invocation control activates. Invariant Labs demonstrated the original primitive in April 2025 with a poisoned add tool whose description instructed the agent to read ~/.cursor/mcp.json and ~/.ssh/id_rsa and transmit them, masking the behaviour behind a benign explanation of arithmetic.
How often does tool poisoning actually succeed?
MCPTox (arXiv:2508.14925) is the first large-scale measurement in realistic conditions: 45 live real-world MCP servers, 353 authentic tools, and 1,312 malicious test cases across 10 risk categories, evaluated against 20 prominent LLM agents. The highest attack success rate was 72.8% against o1-mini. The more important number is the refusal rate: the best-refusing agent in the study declined under 3% of the time. The attacks use legitimate tools for unauthorized operations, so safety alignment has nothing obviously harmful to refuse. The paper also found that more capable models are often more susceptible, because the attack exploits their superior instruction-following ability — capability scaling makes this worse, not better.
Is prompt injection in the OWASP Top 10 for Agentic Applications?
Not as a standalone ranked entry, and this is widely misreported. The 2026 list, published December 2025, runs ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse, ASI04 Agentic Supply Chain Vulnerabilities, ASI05 Unexpected Code Execution, ASI06 Memory and Context Poisoning, ASI07 Insecure Inter-Agent Communication, ASI08 Cascading Failures, ASI09 Human-Agent Trust Exploitation, and ASI10 Rogue Agents. Prompt injection is treated as a causal mechanism operating inside ASI01 and ASI02 rather than as a category of its own. OWASP separately states it is the most prevalent attack technique targeting AI systems and maps it to six of the ten categories. The distinction matters: it is not a bug class you close, it is a mechanism that shows up across most of the list.
How many MCP servers are exposed without authentication?
Two independent 2026 measurements agree closely. A May 2026 study of the remote MCP ecosystem identified 7,973 live remote servers and found 40.55% expose their tools with no authentication at all. Censys separately identified 12,520 Internet-accessible MCP services across 8,758 unique IP addresses as of 28 April 2026, noting the protocol does not require authentication or authorization by default. The same study tested 119 OAuth-enabled servers and found 325 authentication flaws, with every single tested server exhibiting at least one, and 96.6% affected by dynamic client registration vulnerabilities. Censys also found 89.4% of observed deployments still running protocol version 2025-03-26, which predates the newer authorization hardening.
Do prompt injection filters and guardrails work?
Not reliably, and this is one of the better-evidenced findings in the field. An October 2025 study systematically tuned gradient descent, reinforcement learning, random search, and human-guided exploration against 12 recent defenses and bypassed most of them at above 90% attack success — while the majority of those same defenses had originally reported near-zero attack success. The broken set included deployed commercial classifiers. A separate NAACL 2025 Findings paper bypassed all 8 evaluated defenses at over 50% success using adaptive attacks. A third study evaded six production guardrails including Azure Prompt Shield and Meta Prompt Guard at up to 100% success while preserving payload effect. The structural reason is that a detector is itself a neural network, so an adversary can optimize against the classifier and the target model jointly.
Does human-in-the-loop approval stop these attacks?
It is much weaker than teams assume, for two reasons. First, timing: line-jumping attacks land at tool-discovery time, before any invocation-approval gate activates, so there is nothing to approve yet. Second, human factors: Trail of Bits argues approval degrades into what they call human-as-the-rubber-stamp, because users cannot meaningfully evaluate modifications in unfamiliar technical domains and automated workflows bypass real review. Their own defensive tool, mcp-context-protector, documents the same limit honestly — frequent legitimate server updates induce alert fatigue that can cause users to approve malicious changes. Approval is a useful control for high-blast-radius actions. It is not a control you can put load-bearing weight on at scale.
What was the postmark-mcp incident?
postmark-mcp was an npm-distributed MCP server that Koi Security identified in September 2025 as the first malicious MCP server observed in the wild, a characterization OWASP later echoed. The package shipped 15 clean versions building legitimacy before version 1.0.16 added a single line that silently inserted a BCC recipient into every outbound email routed through the server. The malicious code persisted through 1.0.18. The package was first published 15 September 2025 and removed from npm on 25 September 2025, and was downloaded roughly 1,500 times per week. Note two things engineers get wrong: this is a 2025 event, not 2026, and no CVE identifier was ever assigned to it. Vendor estimates of affected organizations and daily exfiltrated email volume were derived from assumed usage rates on download counts, not measured telemetry.
What should I actually do to secure an MCP deployment?
Prioritize containment over detection, because the detection evidence is bad and the containment evidence is better. Concretely: pin tool descriptions on first use and diff them on every reconnect, which directly addresses rug-pull mutation; enforce default-deny outbound egress allowlists so that a successful injection still cannot reach an attacker-controlled endpoint; run tool execution in isolated sandboxes; scope credentials per server rather than passing through a shared token; and treat the tools/list response as untrusted input that enters your context with instruction authority. Adopt the 2026-07-28 specification, which adds RFC 9207 iss validation against OAuth mix-up attacks and binds registered credentials to the issuing authorization server. Assume residual risk rather than elimination: the best-measured out-of-band defense still leaked 2.6% under adaptive attack.
References
Research papers
- MCPTox: A Benchmark for Tool Poisoning Attacks on Real-World MCP Servers — arXiv:2508.14925
- Parasites in the Toolchain: Large-Scale Analysis of MCP Ecosystem Attacks (IEEE S&P 2026) — arXiv:2509.06572
- VIPER-MCP: Detecting and Exploiting Taint-Style Vulnerabilities in MCP Servers — arXiv:2605.21392
- AgentWorm: Self-Propagating Attacks Across LLM Agent Ecosystems — arXiv:2603.15727
- Defeating Prompt Injections by Adaptive Attacks — NAACL 2025 Findings, first posted February 2025, code publicly available. Evaluates 8 defenses and bypasses all of them at over 50% attack success.
- Bypassing Prompt Injection and Jailbreak Detection in LLM Guardrails — April 2025, revised July 2025. Evades six production guardrails including Azure Prompt Shield and Meta Prompt Guard at up to 100% success.
- Adaptive attacks against 12 recent jailbreak and prompt-injection defenses, October 2025 — bypasses most at above 90% attack success using gradient descent, RL, random search, and human red-teaming.
Official documentation and standards
- MCP 2026-07-28 Specification Release Candidate
- RFC 9207 — OAuth 2.0 Authorization Server Issuer Identification
- OWASP Top 10 for Agentic Applications 2026 (ASI01–ASI10), December 2025
- OWASP State of Agentic AI Security and Governance 2.01, June 2026
- OWASP, A Practical Guide for Secure MCP Server Development, February 2026
- NSA Cybersecurity Information Sheet, MCP: Security Design Considerations for AI-Driven Automation (U/OO/6030316-26), May 2026
Vendor research and advisories
- Trail of Bits — Jumping the line: how MCP servers attack you before you use them
- Trail of Bits — mcp-context-protector
- Invariant Labs — MCP Security Notification: Tool Poisoning Attacks
- Unit 42 — Model Context Protocol attack vectors via sampling
- OX Security — MCP supply chain advisory: RCE vulnerabilities across the AI ecosystem
- NVD — CVE-2026-30615