Tool Poisoning in MCP Server Registries

Tool poisoning in MCP server registries is a structural problem built into the protocol itself. It works because the protocol never built a wall between trusted instructions and untrusted data, and closing that gap means covering both server approval and what happens after approval, not just one or the other.

Why MCP tool descriptions are structurally indistinguishable from instructions

Anthropic introduced the Model Context Protocol in late 2024, and it gave agents a standard way to find outside tools and call them. A server hands back a manifest listing what it offers, and each tool carries a free-text description the agent reads to decide whether and how to use it. That text field has no length limit, no check on what it contains, and no built-in cleanup process. Nothing in the protocol flags it as data the model should treat with suspicion. It sits in the same context window as the system prompt, read with the same weight.

An agent cannot reliably tell honest documentation from a hidden command because the protocol hands both to the model the same way, a flaw built into the structure rather than one vendor's implementation. A more capable model doesn't help. If a model follows instructions better, it also follows hidden instructions better, so when capability improves, the problem gets worse, not better.

Even a person reading the description by eye can miss what an attacker hides in it. A description can hide Unicode homoglyphs, a zero-width space, or text tacked on after the legitimate part, and it still looks normal to a reviewer's eye. The Cloud Security Alliance's research note states the underlying failure directly: MCP clients inherit trust from the servers they connect to without continuous verification of that trust. Every attack variant that follows traces back to that single sentence.

Three attack variants that exploit the same structural weakness in different ways

Trust without verification is the root cause, and it appears in at least three distinct forms in MCP deployments, so each one needs its own defense.

With direct embedding, malicious instructions go straight into a tool's description when it's registered. The agent reads the whole description as ground truth and carries out the hidden command as if it were a normal part of doing the job, while the user sees a clean result.

A rug pull works differently. It passes review honestly and sits approved for a while, but later on it ships a malicious update. The approval was genuine when it happened. It just didn't last, because nothing re-checked the server after that first approval.

Tool shadowing is the third form. OWASP classifies it as a sub-technique under MCP03:2025, its Tool Poisoning category. One server's description can reach across the session, where it overrides or intercepts calls meant for a different, legitimate tool.

All three come from the same gap: a server earns trust once, at connection, and nothing in the protocol checks whether that trust still holds. That shared cause doesn't mean one fix handles all three. Hash pinning on tool definitions catches rug pulls. Scanning content at runtime catches direct embedding. Isolating sessions from each other catches shadowing. No single control covers all three, so a defense built around just one leaves the other two wide open.

What confirmed incidents reveal about the blast radius

The scope of damage in each confirmed incident tracks the access the agent already had, not some new permission the attacker had to invent.

Invariant Labs built the first working proof of concept against Cursor in April 2025. A poisoned calculator tool description pulled a developer's SSH private key and the Cursor MCP configuration file out silently, while the model kept returning the correct arithmetic answer the whole time. The developer never saw the instruction that did it.

A month later, in May 2025, the blast radius widened. One malicious GitHub issue, posted publicly, hijacked an agent connected to GitHub's MCP server the moment a user asked it to check open issues. The agent read the poisoned issue text as a command: it used its existing access token to pull salary data and private repository contents, then it opened a public pull request exposing all of it. GitHub's server code had nothing wrong with it. The damage came from pairing a token with broad access to an agent that can't tell a trusted instruction apart from one buried in user content.

By September 2025, the pattern reached the software supply chain itself. A package called postmark-mcp impersonated Postmark's real email integration: it shipped fifteen clean versions to build a trust record, then version 1.0.16 quietly added one line that blind-carbon-copied every outgoing email to an address the attacker controlled. Postmark confirmed only one known customer was running the package, so few organizations were exposed by the time anyone caught it. That case is the first confirmed instance of an in-the-wild malicious MCP server built around deliberate trust-building as the setup for a rug pull.

None of these incidents stay contained to the one server that got poisoned. Practical DevSecOps's 2026 MCP security report finds that when multiple servers in a deployment get compromised at the same time, cascade failure happens at a high rate, so one poisoned server tends to pull adjacent, legitimate servers into the same attack.

The authentication gap that turned registries into an attack surface

Tool poisoning does more damage because the protocol left authentication optional, and thousands of servers went live without it. The MCP authorization spec does define an OAuth 2.1 framework, but it leaves authorization itself optional.

The scans back this up. An internet scan found that a substantial number of public MCP instances answered unauthenticated requests, and a follow-up scan found that count had grown by a wide margin. Research from HOL found that only a small share of public servers use OAuth at all. Most run on static API keys, and these typically never expire, so they carry access indefinitely.

The gap isn't confined to how servers get deployed in the wild. It runs into the SDK code itself. CVE-2026-52869 found that the MCP Python SDK's HTTP transports route requests based only on a session identifier, with no check on who the authenticated principal actually is. CVE-2026-52870, filed alongside it, found that task handlers let any connected client enumerate and cancel other clients' tasks. Separately, CVE-2025-6514, carrying a CVSS score of 9.6, hit the mcp-remote proxy package across more than 437,000 installed environments, letting a client connecting to an untrusted remote server trigger full OS command execution on Windows and launch arbitrary executables with limited parameter control on macOS and Linux.

Most enterprises have no standard approach to how agents authenticate to MCP servers, how far a credential's scope should reach, or how credentials get rotated, revoked, or watched over time. OAuth 2.1 and authentication now carry strong recommendation status in the spec as of 2026, but no enforcement mechanism makes anyone use them, and the protocol still has no way to prove which agent or runtime is holding a given token.

Benchmarking confirms the attack works at scale against real servers

If you measure results against live servers, tool poisoning stops being a qualitative worry: the number is large enough that any organization running MCP at scale needs to plan for compromise, not treat it as a rare edge case.

The MCPTox benchmark, presented at AAAI 2026, ran adversarial versions of hundreds of real tools pulled from 45 live MCP servers against several language models. The Cloud Security Alliance's research note reports that the best-performing agent model in that test reached a 72.8% attack success rate. Claude 3.7 Sonnet showed the strongest resistance of the models tested, refusing more often than the rest, yet it still carried out poisoned descriptions in more than a third of test cases. That result rules out the idea that this is a model alignment issue fine-tuning alone will fix.

The broader scan data points the same direction. Most public servers tested had exploitable flaws in how they handle file operations, and a third of them had critical vulnerabilities. Between January and February 2026 alone, a significant number of CVEs were filed against MCP servers, clients, and supporting infrastructure, and that volume signals a surface still being actively discovered rather than one that has settled. OWASP formally listed tool poisoning as MCP03:2025, and NIST extended its adversarial machine learning taxonomy (AI 100-2) in 2025 to cover autonomous agent risk directly, and together they mark the point where this moved from a research finding to a recognized category of attack.

Shadow MCP usage and audit gaps in enterprise governance

Enterprises face a compounded governance problem: the servers they know about are already difficult to secure, and a large share of their actual MCP usage sits entirely outside any approval process.

Shadow MCP usage, employees connecting agents to servers IT never reviewed, runs completely outside existing access controls and audit systems. The blast radius from tool poisoning then reaches data and credentials the organization never meant to expose to any MCP server in the first place. This isn't a separate vulnerability class from what's already been described. The same technical weakness is just spreading across a wider surface no server-level control can see.

Most organizations early in MCP adoption have more servers running than IT has tracked, and Practical DevSecOps's 2026 report found that only 14.4% of agents reach production with full security approval. The base protocol gives organizations no standard way to log which tools got called, by which agent, with what arguments, and what came back. If you want the audit trail regulators and enterprise customers expect, you need deliberate tooling layered on top of MCP itself, because the protocol hands over nothing by default.

Every agent authenticates with tokens and API keys, and these often never expire, so they keep access once granted. When an organization turns on an MCP integration, it adds a machine identity to its environment, and most identity and access management systems in place today weren't built with that kind of identity in mind.

What continuous verification requires

If a server gets approved once, that tells an organization nothing about whether it can be trusted after its next update, as the rug-pull pattern proves.

CVE-2025-54136, known as MCPoison and disclosed by Check Point Research, showed this directly inside Cursor IDE, a production AI development environment. A team member approved the configuration once, and after that any modification was silently trusted, a vulnerability patched in Cursor v1.3.

The Cloud Security Alliance's research note draws the conclusion that follows from that finding: every tool an agent connects to functions as a live software dependency, and its metadata needs the same change control, review, and ongoing monitoring applied to executable code, not a single decision made at integration time.

Allowlisting which MCP servers an organization approves is a reasonable first gate, but it only answers the question of who gets in the door. To close the gap the rug-pull variant exploits, you need continuous checking of what those already-approved servers are actually returning over time. Hash pinning on tool definitions gives that continuous check a concrete form: record a cryptographic hash of each approved description, and flag any deviation from it before the agent ever processes the changed text.

The same posture extends to how an agent handles anything a tool sends back. If you treat all tool-returned content with the same scrutiny you apply to outside user input, that is what shuts the door on prompt injection reaching the agent's context. Microsoft's June 30, 2026 disclosure confirmed what the incident record had already made clear: natural-language descriptions can be changed quietly after the fact, and nothing short of ongoing verification catches that change before it does damage.