MCP Rug Pull Risks in Third-Party Servers

The trust boundary that changes everything: why an MCP server is not a plugin

Anthropic released an open standard in November 2024 for hooking language models up to tools, databases, and APIs. People called it the "USB-C for AI," and the name stuck because it's accurate: plug any model into any tool once, and skip the custom integration work most engineers used to write by hand. The danger appears once the server has earned trust and nobody's watching the connection anymore, after that plug goes in. That gap, between approval and betrayal, is what this piece is about.

Adoption didn't creep up. It exploded, and adoption's growth was anything but gradual. By March 2026, SDK downloads across Python and TypeScript passed 97 million a month, and remote MCP server deployments grew fourfold since May 2025 alone. A May 2026 pull of the official MCP Registry API counted 9,652 latest server records and 28,959 total server and version records, and that's just the official registry. Third-party directories dwarf it: Glama indexes over 71,000 servers, MCP Toplist nearly 101,000. Stacklok's software industry report puts 41% of surveyed organizations already running MCP servers in limited or broad production, real infrastructure rather than a pilot program. That's infrastructure, not a pilot program.

In a regular API call, whatever comes back is just data. Application code decides what to do with it, the same way every time, no matter what the response contains. MCP breaks that pattern on purpose. When an MCP server responds, its tool descriptions and outputs land straight inside the model's context window as trusted content, and the model reads instructions and follows them. That's the whole design. There's no wall separating "data the server sent" from "action the agent takes next." The two blur together by construction.

Most local deployments make this worse. The MCP server runs inside the agent's own process, with the agent's own privileges, closer to a browser extension sitting next to everything the agent can touch than to a REST dependency tucked behind a network boundary. CyberArk's 2026 research on this point doesn't hedge: every field the server controls, tool names, descriptions, arguments, results, even error strings, works as a possible injection channel. Not some of those fields. All of them.

How a rug pull attack works, the mechanics of post-approval betrayal

A rug pull, sometimes called silent redefinition, happens when an MCP server changes its own tool definitions after someone has already installed it, trusted it, and folded it into daily work. The server behaves during review, then later swaps in something completely different.

The protocol itself makes this possible. MCP ships a feature called notifications/tools/list_changed that lets a server push updated tool definitions to a client that's already connected. By default, nothing ties a re-approval step to that push. No version pinning, no content hash checking whether the new definition still matches the old one. Most MCP hosts bind trust to a tool's name rather than to what it actually says or does, so a tool that keeps its name but rewrites its instructions inherits all the approval the original earned. Nothing forces a second look, and that's the design flaw the whole attack rides on.

The lifecycle runs in four phases. In phase one, trust-building, an attacker publishes a genuinely useful server: clean code, benign descriptions, nothing to flag. People install it, approve it, start relying on it. The second phase is the wait: the server runs cleanly for days or weeks, survives whatever security review it faced, gets written into mcp.json files, and becomes part of how a team works. Phase three is the swap: an update lands, replacing the benign tool description with a malicious one, and most hosts wave it through without asking anyone to re-approve. Phase four is silent exploitation: the client keeps calling the tool exactly as before, no new consent required, while data leaves the building, behavior gets steered somewhere it shouldn't, or security controls quietly stop working.

The betrayal lives in the gap between phase two and phase three, the exact stretch where an organization has already stopped watching.

The attack surface around rug pulls, related vectors that share the same root cause

Rug pulls are one branch of a family of attacks that all trace back to the same problem: models read text as instructions, and that text can come from anywhere.

Tool poisoning hides malicious instructions inside a tool's description field, the text a model reads but a user almost never bothers to inspect. A tool that looks as harmless as add(a, b) can carry a hidden instruction telling the agent to go read private files and send them out. This maps mostly to ASI04, Agentic Supply Chain Vulnerabilities, in the OWASP Top 10 for Agentic Applications, with some spillover into ASI01, Agent Goal Hijack, whenever the poisoning succeeds in redirecting what the agent is actually trying to do.

Tool shadowing is the cross-server version. When an agent connects to multiple servers, a compromised one can intercept or override calls meant for a legitimate tool elsewhere, a classic confused-deputy setup. The agent believes it's calling the tool it trusts. The agent believes it's calling the tool it trusts, but it is actually calling a different one.

A chaining variant stacks the risk one level deeper. A trusted MCP server connects onward to a second, untrusted server. That second server returns something malicious, the trusted server merges it into its own response, and forwards the whole thing to the agent. Reporting from CSO Online on top MCP vulnerabilities found that the organization on the receiving end never connected to the malicious server directly. It inherited the risk secondhand, through a server it did trust.

One combination causes nearly all of it: an agent with access to private data, that also reads untrusted content, and also has some outbound path to send things out. MCP makes it easy to wire all three together without meaning to, because connecting tools is the entire point of the protocol.

Confirmed incidents that show rug pull mechanics playing out in production

The postmark-mcp npm backdoor is the clearest case on record. The package sat under the official Postmark namespace and shipped 15 clean versions before anything happened, long enough to earn real trust. Version 1.0.16 added a single line of code: BCC every outgoing email to an address the maintainer controlled. Weekly downloads sat around 1,500, and researchers at Snyk estimate roughly 300 organizations were affected. Fifteen clean releases, then one line. That's the slow-build rug pull in its purest form.

Cursor IDE has its own entry, tracked as CVE-2025-54136 and nicknamed MCPoison. Researchers at Check Point found that Cursor trusted an approved config key even after the command sitting behind that key had been fully swapped out. The trust boundary amounted to "you approved this server name," never "you approved this specific binary or this specific config hash." An attacker with write access to a shared repo's MCP config could swap the command and get persistent remote code execution, no re-approval prompt in sight. Check Point reports the fix landed in Cursor version 1.3.

Two more sit in the same family. CurXecute, CVE-2025-54135, carries a CVSS score of 8.5, and sources describe its exploitation path as worse than MCPoison's. DuneSlide scores a 9.8: remote code execution in Cursor triggered by a malicious MCP server, no user interaction needed beyond opening a project. That one got patched in Cursor v3.0.

How vulnerable the ecosystem is, the quantified picture

Researchers disclosed more than 40 CVEs against MCP components between January and April 2026 alone. Four months, forty-plus vulnerabilities. That's not a mature ecosystem patching edge cases. It's an ecosystem still working out fundamentals in public, in real time.

The Vulnerable MCP Project tracks more than 50 known vulnerabilities spread across servers, clients, and infrastructure, 13 of them rated critical. OX Security puts the affected download count in the hundreds of millions across vulnerable MCP packages.

The MCPTox benchmark tested how well agents resist tool poisoning across 45 live MCP servers and 353 real tools. The overall average attack success rate landed at 36.5% across every model setting tested, and the more capable models proved more vulnerable, not less. o1-mini hit a 72.8% attack success rate. Phi-4 came in at 70.2%, GPT-4o-mini at 61.8%, Qwen3-32b in reasoning mode at 58.5%. It's the tradeoff working exactly backward from how most people assume it does, rather than a flaw in those models: the attack succeeds by exploiting good instruction-following, so the better a model follows instructions, the better it... It's the tradeoff working exactly backward from how most people assume it does: the attack succeeds by exploiting good instruction-following, so the better a model follows instructions, the better it follows the malicious ones too. Claude 3.7-Sonnet posted the highest refusal rate in the benchmark and still stayed under 3%. Safety alignment built for chatbot conversations doesn't transfer to an attack that just uses a legitimate tool for something illegitimate.

A separate scan of over 7,000 public MCP servers, published on arXiv under the title "Parasites in the Toolchain," found 43% vulnerable to command injection, 82% using file operations prone to path traversal, and 36.7% vulnerable to server-side request forgery. Those aren't obscure edge-case bugs. They appear when code ships fast and gets reviewed lightly, and at this scale they cover a huge share of what's already running in production.

The structural argument for continuous verification: why upfront vetting fails as the primary defense

Vetting a server before install checks what it does on day one. Rug pulls are built to wait past that, to day ten or day thirty, whenever attention has moved on. A one-time review can't catch a threat engineered to exist outside the review window, and treating vetting as sufficient misreads what the attack is actually built to survive.

Part of the reason is technical. The MCP specification doesn't require servers to cryptographically commit to their tool descriptions, so there's no content hash to compare against. A tool description that got quietly rewritten looks, from the client's side, exactly like one that just got refreshed with better wording. Nothing distinguishes malicious change from routine maintenance.

Static analysis and software composition analysis tools don't help much here either. They scan source code, and they come back clean even when the poison sits inside a natural-language description field rather than in the code path. That's the blind spot: the scanner reads code, and the attack lives in text the model reads as instruction.

Registry listing doesn't fix any of this, and it may actively make things worse by implying that it does. Getting into the official MCP Registry only requires proof of GitHub repository or domain ownership. No code review, no security audit, no malware scan. Users see a listing and reasonably assume someone checked the thing. Nobody did, not in the way that assumption implies, and that mismatch between what users assume and what the registry actually verifies is itself a risk.

None of this argues against vetting at install. It argues that vetting alone can't be the whole defense, because a rug pull is designed specifically to happen after the vetting is finished. What actually counters it is a system that watches for change itself, not one that only checks for badness once at the door: version pinning, content hashing on tool definitions, and re-approval triggers that fire the moment a tool's description shifts rather than the moment it first shows up.