MCP Server Impersonation and Rug-Pull Attacks

MCP, the Model Context Protocol, gives AI agents a standard way to find tools, hook into them, and run them: file systems, databases, APIs, whatever SaaS product a company plugs in. That convenience rides on a trust assumption baked into the protocol itself. When an agent connects to a server, it takes that server's word for what its tools do, once, at connection time, and never checks again. Rug-pull attacks and server impersonation both exploit that exact gap, and understanding the mechanics of each is the starting point for closing it.

Anthropic launched MCP in November 2024. Within about a year it had industry-wide backing, OpenAI, Google, Microsoft, AWS all on board, with governance now sitting under the Agentic AI Foundation, a directed fund inside the Linux Foundation. A substantial volume of monthly SDK downloads, over 10,000 active public servers, and native client support baked into ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and VS Code, according to a Practical DevSecOps report, mark fast growth for any protocol. That's fast growth for any protocol. Security maturity didn't keep pace, and that lag is the story this piece is about.

How MCP handles trust at connection time, and why it never re-checks

When a session starts, the agent pulls a manifest from the server: tool names, descriptions, input schemas. That manifest lands in the model's reasoning context carrying the same weight as a trusted system instruction. The agent doesn't ask "is this the same tool I approved last week." It just reads what's in front of it and acts.

That's because trust binds to the connection, not to the content. The MCP spec has no cryptographic content-addressing and no version pinning for tool descriptions, a point raised in academic research on MCP tool poisoning. Nothing in the protocol lets a client check whether a server's current tool definitions match what got reviewed during onboarding.

Authentication is optional by design, and most servers skip it. Only 8.5% of public MCP servers use OAuth, and an internet-wide scan in July 2025 turned up at least 1,862 publicly reachable instances answering unauthenticated requests, the Cloud Security Alliance's note on the MCP security crisis found.

Put those two facts together and the structural problem writes itself. A server audited at one point in time can behave completely differently later, with no signal reaching the agent or the person using it, a gap flagged in the academic literature cited alongside this reporting. Rug-pull attacks and server impersonation are two different ways of cashing in on that same blind spot.

How rug-pull attacks work: the silent swap that trust already approved

A rug pull runs in three stages, and the first stage is the one that makes the whole thing work. An attacker publishes a genuinely useful MCP server, clean code, honest tool descriptions, nothing to raise an eyebrow. People install it, approve it, wire it into their workflows. Trust gets earned the normal way.

Then comes the swap. The server ships an update. Maybe the tool descriptions now carry hidden instructions. Maybe the command in mcp.json points somewhere new. Maybe a function that used to be inert now carries a payload. None of that requires breaking in anywhere, it just requires pushing a new version.

Silent execution is the third stage, and it's the one that does the damage. The MCP host loads the update without asking anyone to re-approve it, because approval was tied to the tool's name, never to what the tool actually does. From that point on, the agent runs the attacker's instructions using the full set of credentials the user already granted.

The spec makes this almost inevitable: there's no built-in mechanism for tracking changes to tool definitions or forcing re-approval when they happen, according to both the Practical DevSecOps glossary and the Cloud Security Alliance's security crisis note. And it hides well, because rug pulls travel through the same update channels npm, pip, and Cargo treat as routine background noise. Nobody reads a dependency diff line by line.

The clearest example on record is CVE-2025-54136, nicknamed MCPoison, CVSS score 7.2. Check Point's researchers found that Cursor tied trust to the name of a config entry rather than the command that entry actually ran. An attacker commits a harmless-looking MCP config to a shared GitHub repo, a teammate approves it, and later the attacker edits that same entry to run something else entirely. No new prompt fires. No warning appears.

Check Point disclosed MCPoison to Cursor privately on July 16, 2025, and went public on August 5. Cursor had already shipped a fix in version 1.3 on July 29, and the fix is instructive: any change to an MCP config, even adding a single space, now forces re-approval. That's the correct fix, and it matters later in this piece.

Enterprises make the problem worse, not better, in one specific way. Where tool approvals run through formal change-control processes, those processes typically have no step that re-validates a tool after it's deployed, per the Cloud Security Alliance's best-practices guidance on agentic MCP security. The control exists at the front door and nowhere else.

Security researchers have flagged the same root cause: MCP clients may show a tool's description at onboarding, but nothing in the protocol notifies anyone when that description changes later. The fix has to live in how the client is built.

How server impersonation and tool shadowing redirect agent calls without touching the target

Rug pulls corrupt something the user already trusts. Impersonation attacks skip that step and go straight for the naming system instead.

Cross-server tool shadowing, sometimes labeled MCP-03 in the research, works like this: a malicious server registers a tool name that's identical to one on a legitimate server the agent already trusts. Calls meant for the real tool get routed to the fake one instead, and the agent has no way to tell the difference, because MCP gives it no mechanism for distinguishing two tools that share a name.

Context poisoning is what turns that shadowing trick into something dangerous. MCP doesn't enforce any isolation between servers running in the same session. So a malicious tool on one server can bury instructions inside its own description, and those instructions stick around in the model's working context, quietly shaping how the agent behaves toward tools on a completely different server, according to the academic research behind this reporting.

Notice what doesn't happen here: the malicious server never touches the legitimate one. It just poisons the shared context and lets the agent do the routing on its own. Encrypting the transport layer does nothing to stop this, because the leak happens above that layer entirely, inside the model's reasoning.

Invariant Labs built a proof of concept for exactly this in April 2025. A fake trivia-game MCP server buried instructions in its tool description that targeted a legitimate WhatsApp MCP server running in the same session. The agent pulled WhatsApp message history and shipped it out through the trusted server, and from the outside it looked like ordinary traffic the whole time, per the Cloud Security Alliance's note on the broader MCP security crisis.

Impersonation occurs at the package-registry level too. Early 2026 saw a typosquatting campaign tracked under the name SANDWORM_MODE, which planted rogue MCP servers under names that looked like popular legitimate tools, aimed squarely at AI coding assistants, CybeDefend reported.

What separates this whole class of attack from a rug pull is simple: the legitimate server never gets touched. The attacker wins purely by exploiting what the agent assumes about naming and about shared context.

What both attacks share: tool poisoning as the common delivery mechanism

Both attack types run through tool poisoning, the same delivery mechanism, which explains why they produce similar outcomes. That means burying adversarial instructions inside a tool's description, its parameter schema, or the content it returns, all places the agent treats as trustworthy operational context rather than as data to scrutinize, as the Cloud Security Alliance's tool-poisoning research found.

The model can't filter this out on its own, and that's not a flaw specific to any one AI system. An agent can't reliably tell the difference between a tool description doing its normal job and a tool description carrying a hidden instruction, because both are written in the same natural language. Treating language as instruction and as data at the same time is the actual structural problem, not a bug in any particular model.

Attackers hide these instructions with tricks that look invisible on screen: Unicode homoglyphs, zero-width characters, malicious text tacked on after the legitimate description ends. A human skimming the tool card sees nothing wrong.

And the description field is just one entry point. Research from CyberArk, published under the name "Poison Everywhere," showed that parameters, error messages, and even a tool's returned output can all carry hidden instructions just as easily.

Invariant Labs ran a demonstration in April 2025 that shows how far this goes. A tool description carried hidden instructions that got truncated in the client's UI, so a human reviewer saw a short, clean line of text. The model read the full, untruncated version, and it directed the agent to read ~/.ssh/id_rsa and ~/.cursor/mcp.json, then smuggle both files out through a parameter that looked completely unremarkable.

Lab testing across more than 45 real-world MCP servers found attack success rates above 60% across the board, with the best-performing model in the test set hitting 72.8%, according to the Cloud Security Alliance's research note. Those aren't edge-case numbers. And the risk compounds: a prompt-injection payload buried in untrusted content can trigger a tool call, and that tool call can then land on a separate command-injection bug in the handler code. Two weaknesses, stacked, doing more damage together than either would alone.

The CVE record: from theoretical to confirmed harm at enterprise scale

None of this stayed theoretical for long. More than 30 CVEs got filed against MCP servers inside a single 60-day window in early 2026, and 13 of those, roughly 43%, followed command-injection patterns, according to the Practical DevSecOps report.

CVE-2025-6514, affecting the mcp-remote package, carries a CVSS score of 9.6. It's an OS command-injection flaw that lets an attacker achieve remote code execution just by getting a victim to connect to a malicious server. The package behind it had been downloaded more than 437,000 times before anyone disclosed the bug.

MCPoison, covered above as the defining rug-pull case, is CVSS 7.2 and is the clearest confirmed instance of the rug-pull pattern playing out in a production tool people actually use every day.

CVE-2026-33032, tracked under the name MCPwn and affecting the nginx-ui MCP integration, scores a 9.8. It's an authentication bypass that was actively exploited in the wild before a patch landed on March 15, 2026.

At least seven confirmed high- or critical-severity CVEs span MCP Inspector, LiteLLM, Cursor IDE, LibreChat, and Windsurf, per the Cloud Security Alliance's security-crisis note. That's not one vendor's problem. It's spread across the tools people actually reach for.

The widest-reaching finding came from OX Security: an architectural flaw sitting inside the official MCP SDKs for Python, TypeScript, Java, and Rust, exposing an estimated 200,000 vulnerable instances across a supply chain built on more than 150 million package downloads. Anthropic confirmed the behavior was intentional and declined to change the protocol's architecture in response, according to the same industry note.

The first confirmed malicious MCP server caught operating in the wild is the one tied to Postmark, which silently exfiltrated emails before anyone caught it, according to the OWASP MCP Top 10 project. And the damage doesn't stay contained to one server: when researchers modeled multi-server compromise, they recorded a 72.4% cross-server cascade rate, per the Practical DevSecOps report. Compromise one server, and there's a good chance it doesn't stop there.

Governments have started responding. A government advisory issued in mid-2026 named MCP security directly, and it called out tool poisoning, rug-pull attacks, and cross-server trust exploitation as priority risks. Its recommendations: pin versions, enforce OAuth 2.1, and run MCP execution inside air-gapped or sandboxed environments wherever the security bar is high.

One independent audit found that YARA-based MCP scanners produced a false-positive rate around 78%, per the Practical DevSecOps report. Headline percentages about "how much of MCP is vulnerable" swing wildly depending on the methodology behind them. The CVE record, filed one confirmed vulnerability at a time, holds up better as evidence than any scanner's aggregate score.

What defenders need to do: breaking the trust chain before the agent inherits it

Trust gets inherited once, at connection time, and never gets checked again after that. Any real defense has to work at connection time and keep working after.

Hash pinning tool definitions is the fix MCPoison exposed as missing. Tie approval to the actual content of a tool, its description, its schema, its command, not to its name. Any change to that content should force a fresh approval cycle, full stop.

Version pinning and allowlisting matter just as much. Treat an MCP server the same way a security team treats any other software dependency: pin to an explicit version, allowlist only approved servers, and treat every registry update as untrusted until someone reviews it. That single habit blocks both the rug-pull pattern and typosquatting campaigns like SANDWORM_MODE in one move.

Client software needs to flag changes. Willison called this out in April 2025, and Cursor's post-MCPoison fix, forcing re-approval on any config change down to a single character, is the template other clients should copy.

Isolation between servers has to be enforced directly, so a poisoned context on one server can't bleed into how the agent behaves toward a different one. And every piece of content a tool returns, descriptions, parameters, error messages, output, deserves treatment as hostile until proven otherwise, regardless of how much the server itself is trusted.

Authentication can't stay optional. The MCP HTTP spec, version 2025-06-18, calls for OAuth 2.1, and legacy token-passthrough setups need to go. The joint NSA and DoD advisory from June 2, 2026, states that authentication can't stay optional.

Static, one-time approval isn't enough on its own, since rug-pull attacks live specifically in the gap between the moment something gets approved and the moment it actually runs. Closing that gap means watching for intent drift, unexpected tool calls, and output routing that doesn't match what a tool was approved to do, continuously, not just once at onboarding.

Most organizations are missing governance. Only around 23% of organizations have a formal identity strategy for AI agents, and just a small share of agents that reach production carry full security approval, according to the Practical DevSecOps report. Everything listed above, hash pinning, version control, re-approval triggers, server isolation, OAuth enforcement, runtime monitoring, adds up to a governance program. It isn't a patch anyone applies once and walks away from. Enterprises running many MCP integrations at once need a control plane that enforces these rules at the level of every individual tool call, ties identity to each action through SSO and just-in-time credentials, watches for poisoning and intent drift as it happens, and keeps an audit log nobody can quietly edit after the fact. Asking each developer to hand-roll hash pinning and re-approval logic, integration by integration, is how gaps like MCPoison happen in the first place.