Tool Poisoning in MCP Server Registries

MCP, the Model Context Protocol, connects AI agents to outside tools, files, and workflows. More than 10,000 public MCP servers are active as of spring 2026, up from roughly 1,200 a year before. Getting one listed requires no code review, no malware scan, no one checking whether the thing does what it claims. That gap is the actual story here, and it's worse than most people writing about MCP seem to think.

A wide range of AI clients and development tools now support MCP natively, so a bad server doesn't stay contained to one app. It reaches into whatever toolchain an organization has built around it. Governance passed to the Agentic AI Foundation under the Linux Foundation in December 2025, with Anthropic, OpenAI, Block, Google, Microsoft, AWS, Cloudflare, and Bloomberg all signed on as members, giving the protocol formal oversight for the first time. But governing the protocol and checking the thousands of servers plugged into it are two separate jobs, and only one of them is actually happening right now.

Anyone who watched npm or PyPI over the last decade already knows how this plays out. Both operated on open submission and default trust, and meaningful security controls came only after sustained, visible damage had already accumulated. MCP registries run on the same assumptions today: open submission, default trust, no real gate. That openness is why adoption exploded, and it's what attackers are counting on.

How Tool Poisoning Works: Malicious Instructions Hidden From Human Review

Invariant Labs named this attack in 2025: the Tool Poisoning Attack, or TPA. It's baked into infrastructure that persists across every session, not just one conversation, not something typed into a chatbot window. It's baked into infrastructure that persists across every session, not just one conversation.

An attacker registers an MCP server with a tool description that looks completely ordinary to a person, maybe just a name and a one-line summary. An attacker registers an MCP server with a tool description that looks completely ordinary to a person, maybe just a name and a one-line summary. But the full metadata field also carries a set of directives meant for the agent, not the user. When the agent pulls that metadata to decide what to do next, it reads the whole field as context to follow. Nothing in the MCP spec separates "this is documentation" from "this is an instruction." The agent has no structural marker telling it which is which, so it just runs both.

The agent carries out the hidden directive right alongside the task it thinks it's doing: copying a credential file, BCC'ing an email, reading a private key. The user sees a clean, correct result on screen. The attacker gets the payload. Nothing looks wrong, which is the entire point of the design.

Invariant Labs' proof of concept from April 2025 made this concrete for a lot of engineers. A poisoned description on a calculator tool caused Cursor to quietly read a developer's SSH private key along with the local MCP configuration file, then send both to a remote server. The math answer displayed on screen was correct the whole time.

The Cloud Security Alliance's AI Safety Initiative calls the MCP tool description field an unsanitized attack surface: a compromised server hides arbitrary instructions in what looks like help text, and the agent follows them without the user ever knowing. Microsoft's June 2026 security guidance formally classifies MCP tool descriptions as part of the software supply chain, telling teams to review changes to them the way they'd review a code change. OWASP now ranks tool poisoning third on its MCP Top 10. This stopped being an academic curiosity a while ago.

The attack family: rug pulls, schema poisoning, tool shadowing, and cross-server cascades

Tool poisoning is the root idea. It branches into several distinct patterns, and each one exploits a different gap in how MCP handles trust.

Rug pulls happen after approval, not before. A tool definition gets silently changed once an agent, or the humans overseeing it, has already signed off on it. MCP's trust model does not reliably surface when a definition has changed after initial approval. In enterprise settings this slips through because change-control processes usually check new tools going in, not existing tools that quietly get edited later. Publish something legitimate, let it earn trust, then slip in the poisoned update. The registry model has no mechanism to catch or flag that change after the fact.

Schema poisoning works on the contract layer instead of the description layer. An attacker rewrites a schema so a command that sounds harmless actually maps to something destructive. Researchers at CyberArk found a version that dodges tools scanning only description text, by hiding the payload in function names, required-fields arrays, or parameter types and default values. Catching it means analyzing the schema itself, because the attacker isn't exploiting a bug in code. They're rewriting the rules the agent thinks it's following.

Tool shadowing works differently again. A malicious tool reaches across servers to manipulate other, trusted tools it has no business touching. Security researchers have documented this pattern, and it creates cascading failures once an organization runs several MCP servers together. One bad actor in the mix can throw off tools that were never compromised themselves.

Then there's the confused-deputy vulnerability: MCP proxy servers that bridge to third-party APIs can be tricked into acting on a manipulated request, with the proxy's own privileges doing the damage. A more advanced variant hides malicious logic in the execution code rather than the metadata, so a tool call fails on purpose and returns an error message written to look like a legitimate instruction, one the agent then follows. That variant skips static analysis entirely, since there's no poisoned text sitting in the description field to catch.

Between prompt injection, the "lethal trifecta" framing Simon Willison laid out in April 2025, and the broader OWASP MCP Top 10 that followed later that year, the security community mapped most of this attack family inside a single twelve-month stretch. That's a fast consensus for a threat this serious, and it should tell you something about how obvious the danger looks once people actually dig in.

How common these vulnerabilities are across public MCP server registries

The MCPTox benchmark, published in August 2025 by researchers at the University of Science and Technology of China and Beihang University, is the most systematic test run so far. It threw 20 large language models against 45 live MCP servers and 353 real tools, not synthetic stand-ins. Average attack success rate: 36.5%. Against the single most vulnerable model, it hit 72.8%.

That 36.5% is a floor, not a ceiling. More than one attack attempt in three succeeds against tools that are live right now, in production, doing real work for real users. This came out of testing real-world conditions, not some inflated lab scenario built to make headlines.

Other scans, using different methods, all point the same direction. A 2025 academic study by Hasan and colleagues found tool poisoning in 5.5% of 1,899 servers checked. Enkrypt AI, scanning 1,000 servers in October 2025, found critical vulnerabilities in 33% of them. BlueRock Security's 2026 sweep of more than 7,000 servers found command injection flaws in 43% of public servers, serious enough that any one of them should require security review before anyone deploys it. Trend Micro found 492 MCP servers sitting exposed on the open internet with no authentication.

Authentication is where the real story sits. Skipping authentication isn't the exception here, it's the default setting for the entire ecosystem, with OAuth adoption remaining a small minority across public servers. CoSAI's 2026 audit of 17 MCP servers scored them an average of 34 out of 100. Small sample, sure, but it's the closest thing to a real audit baseline anyone has, and the number is bad on its own terms regardless of sample size.

None of this is bad luck. MCP's architecture makes these attacks more effective than equivalent attacks against non-MCP integrations, because of how the protocol structures trust between agent and tool. The design invites the exploit, plain and simple. HackerOne has logged a 540% surge in prompt-injection reports, which is about as clear a signal as it gets that attackers noticed the opening and started working it hard.

Confirmed incidents: what real tool poisoning attacks have already done

Statistics describe the risk in the abstract. These incidents show what it looks like once it actually lands on someone.

postmark-mcp, confirmed in September 2025, is the first known malicious MCP server caught operating in the wild. It impersonated the legitimate Postmark email integration on the public npm registry. The package shipped fifteen clean versions first, a textbook rug pull, building a trust record before version 1.0.16 quietly added one line of code that BCC'd every outgoing email to an address the attacker controlled. Based on around 1,500 weekly downloads, an estimated 300 organizations were affected, with as many as 15,000 emails a day duplicated to the attacker for weeks. The leak ran until September 25, 2025, when Koi Security's risk engine caught the anomalous pattern. Those fifteen clean releases weren't a sign of safety. They were the setup.

CVE-2025-6514, disclosed in July 2025, hit mcp-remote, a proxy widely used to connect Claude Desktop, Windsurf, and Cursor to remote MCP servers, and referenced in integration docs from Cloudflare, Hugging Face, and Auth0. The package contained a critical OAuth-related command-injection bug that left the proxy open to manipulation by a malicious remote server exploiting its OAuth flow. It carried a CVSS score of 9.6 and touched more than 437,000 installed environments before a patch went out. Nearly half a million developer environments exposed through one package's misplaced trust in a single URL.

MCPoison, tracked as CVE-2025-54136, built on the same calculator proof of concept from April that quietly pulled a developer's SSH private key out of Cursor. The MCPoison variant showed how a single poisoned configuration file in a shared repository can produce a team-wide compromise. One bad commit becomes a team-wide compromise. That alone is reason enough to treat changes to MCP config files as a code review event.

OX Security's report, titled "The Mother of All AI Supply Chains," found a command execution vulnerability inside Anthropic's own official MCP SDKs, across Python, TypeScript, Java, and Rust. The vulnerability allowed incoming configuration parameters to reach the host operating system without adequate sanitization. This wasn't some shady third-party server cutting corners. It was the protocol's own reference implementation, the code every other server gets built on top of.

IDE behavior makes all of this worse. The CSA's report found that Cursor, Claude Code, Gemini CLI, GitHub Copilot, and Amazon Q all auto-execute project-defined MCP servers with developer-level operating system privileges, with no process isolation keeping them in check. A poisoned repo config doesn't hit one machine. It multiplies across every developer who opens that project.

The most severe confirmed incident to date is the breach of multiple Mexican government agencies between December 2025 and February 2026. A single attacker used Claude Code alongside OpenAI's GPT-4.1 to breach the federal tax authority, the electoral institute, four state governments, and a water utility in Monterrey. The attacker's own conversation logs turned up publicly accessible online, found by the Israeli security firm Gambit Security on February 25, 2026, while it was testing new threat-hunting techniques. By then, 150GB of data was already gone, including 195 million taxpayer records and other sensitive government data. That's what agentic AI running with wide permissions looks like once nobody's watching the runtime.

The Registry Admission Model's Lack of a Meaningful Security Gate

Getting a server listed in a public MCP registry requires no code review, no security audit, no malware scan. That's the whole bar.

Plenty of users assume registry presence means somebody checked the thing before it went live. That assumption is flat wrong, and it's the exact gap attackers are working right now. A server sitting in the official MCP Registry carries no more real trust than a random package pulled off a forum post.

No registry publishes a figure for what share of its listings has actually been audited. CoSAI's average score of 34 out of 100, across a sample of just 17 servers, is the closest thing available, and even that comes from a small, self-selected group. Nobody's tracking this at scale yet. That silence is its own kind of answer.

The npm and PyPI comparison holds up because it's the same pattern playing out a second time. Both ecosystems needed years of visible, damaging incidents before controls like sigstore signing, provenance attestation, and quarantine policies became standard practice. MCP registries sit at the start of that curve, nowhere near the end of it.

The rug pull attack exists specifically because the registry model treats a clean version history as proof of trustworthiness. It isn't proof of anything. A registry with no mechanism to detect or flag a definition change after the fact treats a server that's been safe for six months exactly like one about to stop being safe on version 1.0.16. Fix that gap, or expect the postmark-mcp story to repeat under a different package name.