MCP Server Impersonation and Rug-Pull Attacks

MCP server impersonation and rug-pull attacks are not old supply-chain problems with a new label on them. They come straight out of choices you find baked into the protocol's design. MCP hands tool selection to the model itself at the moment it runs: an agent reads a plain-language tool description and acts on it with the same trust it gives a system instruction written by the people who built it. Whoever writes that description controls what the agent does next. The Cloud Security Alliance's analysis names this as the shared root cause behind three distinct attack types, tool description poisoning, rug-pull attacks, and tool shadowing, and points out that MCP currently has no built-in way to catch or block an injected instruction hiding in those fields.

Four gaps in the protocol open the door to impersonation and rug-pulls, and ordinary supply-chain defenses were never built to stop them. Authentication is optional, so today nobody has to check who is connecting to a production MCP server. Authorization and role-based access control are absent from the spec, leaving no standard way to limit what a caller is allowed to do once it's in. Session-to-identity binding has no defined mechanism either, so a session can outlive or drift from the identity that first approved it. Approval happens once, at first connection, and after that nothing in the protocol watches for changes to a tool's definition.

The NSA's May 2026 Cybersecurity Information Sheet made the point directly: dynamic tool invocation, implicit trust between agent and server, and shared context across agentic AI systems running MCP are not problems you fix by patching one endpoint. If a trust assumption is wrong at any single stage of that chain, it can turn into an exploitable hole somewhere downstream. That's the frame for everything that follows: rug-pulls and impersonation aren't clever hacks layered on top of a sound system. So when natural language is both the content an agent reads and the instruction it obeys, impersonation and rug-pulls are what you get.

How rug-pull attacks exploit the one-time approval gap

First you earn trust, then you spend it: that's how a rug-pull attack works. The server shows off a set of harmless, useful tools at first connection, earns the user's approval, and only afterward changes what those tools actually do, what they're described as doing, or how they behave, with no prompt back to the user and no re-check by the client.

This attack occurs in two distinct forms, and teams often see both at once. In the first, the manifest itself changes: the server hands over a clean, legitimate list of tools on the first connection, earns approval, and then on some later session or some later call, swaps in an altered version, descriptions carrying hidden prompt-injection instructions, parameter fields widened to accept arbitrary filesystem paths, or tool names designed to impersonate a trusted server already connected. The client doesn't ask again because, as far as it's concerned, approval was already granted for "this server." In the second form, the manifest never changes. The malicious behavior sits dormant inside the tool's actual code, waiting on a trigger, a call counter, a timestamp, a specific argument value, or a signal from a remote command server, before it activates. When it triggers, it can exfiltrate data, feed poisoned output back to the model, or reach into other connected tools through shadowing.

In April 2025, Invariant Labs published a proof-of-concept that chained both forms into one demonstration. A server presenting itself as a simple "random fact of the day" tool swapped its interface on the second load, replacing it with a poisoned description that instructed the agent to call a separately connected, legitimate whatsapp-mcp server and forward the user's chat history to an attacker's phone number. The user never re-approved anything, and the WhatsApp server itself was never touched or modified in any way. The attack isn't tied to one specific client either: it succeeds against any MCP client that caches an earlier approval and has no way to detect that a manifest has drifted from what it originally saw. The WhatsApp server stayed clean throughout, because the entire exploit ran through the attacker's own server, which used tool shadowing to borrow a trusted server's credentials and reach.

Since then, this threat class has moved from proof-of-concept to something confirmed in production. CVE-2025-54136, carrying a CVSS score of 7.2 and affecting Cursor IDE, was catalogued in August 2025. The Cloud Security Alliance's analysis traces the root cause directly: Cursor never re-validated a tool's definition after the user's initial approval of an MCP configuration, so a server could change what a tool actually did while keeping the approval status it earned on day one. Research outside the vendor world has reached the same conclusion from a different angle: an arXiv paper formally classifies rug-pull as a primary MCP threat class and proposes cryptographic signing of tool definitions along with immutable versioning as a way to close the gap, a sign that the threat has moved well past being a hypothetical.

Rug-pulls are hard to catch through the audit trails teams already keep, and the reason is simple. The model can see tool descriptions, but they rarely appear in the client's interface, so an injected instruction never appears on screen during ordinary use. Because the malicious action runs inside a tool the user already approved, the audit log shows just what it's supposed to show: the expected tool name being called, with no record of the mutated instruction buried inside its description. And because of tool shadowing, one compromised server can reach every credential sitting behind every other connected server, filesystem access, source control, payment processing, without any of those other servers ever being touched.

Server impersonation and the registry attack surface

You approve a rug-pull before it attacks your trust, but impersonation attacks your trust before you ever grant it. It works because MCP registries have no cryptographic way to prove a package is what it claims to be: an attacker publishes something that looks and acts like a trusted provider's server, and since the protocol includes no attestation step, the client has no automatic way to tell the real thing from a copy. Authentication is also optional in the first place, so the registry itself becomes part of the attack surface rather than a safeguard against one.

The 2026 Oura MCP clone shows the straightforward version of this: developers pulled a trojanized package down from a poisoned registry entry, with nothing in the system set up to verify where it actually came from. The more serious confirmed case in the wild is the postmark-mcp backdoor from September 2025, which stands as the first documented malicious MCP server to operate in production rather than a lab. The package shipped fifteen clean versions, 1.0.0 through 1.0.15, before it turned malicious, and that deliberate trust-building run let it pass every ordinary review when it mattered. Once it flipped, the leak included email contents such as passwords, internal invoices, customer records, and authentication tokens, all silently BCC'd to an address the attacker controlled. That fifteen-version sequence is impersonation and rug-pull working together: the package passes inspection precisely because its early behavior is clean, then mutates once wide adoption makes the payoff worth the risk.

What makes this worse than a single leaked package is how MCP servers tend to be built. One server often holds OAuth tokens for several downstream services at once, so if an attacker compromises that one server through impersonation, they get everything connected to it in a single move. An April 2026 disclosure from OX Security found roughly 200,000 vulnerable MCP instances spread across IDEs, internal company tools, and cloud services, giving a sense of how often this setup exists in practice. It's 200,000 points where an unverified registry entry and an unauthenticated server combine into the same exposure.

Impersonation doesn't stop at data theft, either. CVE-2025-6514, carrying a CVSS score of 9.6, shows how impersonation reaches code execution: the mcp-remote package allowed arbitrary OS command execution via crafted authorization_endpoint URLs returned during the OAuth flow by a malicious MCP server, affecting any host using mcp-remote to connect to remote MCP servers. That case matters because the injection point wasn't a tool description.

Token passthrough and confused-deputy OAuth

Getting a rug-pulled or impersonated server into an agent's execution path is just where it starts. What turns that single foothold into something much larger is token passthrough combined with confused-deputy OAuth: this is the mechanism that converts one compromised connection into lateral movement across every service the agent can reach.

Token passthrough happens when an MCP server takes a token you handed over for one service and reuses it to call a different downstream API, so the server becomes a deputy that carries your legitimate credentials into actions you never actually authorized. The NSA flags this specific mechanism as the single highest-priority point to stop in the entire threat chain, ahead of other mitigations. Confused-deputy OAuth works on a related but distinct principle: a server holding broad, ambient permissions, with no check on individual actions, gets manipulated by an attacker who never logs in directly but instead controls what the model reasons about, redirecting the server's existing elevated access toward unauthorized ends. CVE-2026-13341, affecting Kong Konnect, shows this running at production scale: indirect prompt injection drove the MCP server to make unintended API requests using authority it already legitimately held, a confused-deputy exploit playing out inside live enterprise infrastructure rather than a research lab.

Credential aggregation is what makes the math behind this so lopsided. It's the actual reason impersonation attacks go after MCP servers specifically instead of targeting individual API integrations one at a time. The damage also doesn't only travel downward through a stack of credentials. The Asana cross-tenant incident from June 2025 showed it moving sideways instead: a tenant isolation flaw in an MCP-connected deployment let data contamination cross organizational boundaries, affecting as many as a thousand enterprises from a single flaw. Token passthrough, confused-deputy authority, and credential aggregation together explain why these attacks call for structural controls on the protocol itself, not just a stronger wall around the perimeter.

Adversarial tool descriptions and standard defenses

Rug-pull payloads and poisoned tool descriptions are built, deliberately, to slip past the review and audit habits that security teams already rely on. Ordinary application security testing doesn't catch them. The Cloud Security Alliance's analysis documents the specific techniques: hiding adversarial content using Unicode homoglyphs, zero-width space characters, or simply appending malicious instructions after legitimate description text in a way that looks completely ordinary on screen. The model processes the instructions sitting inside the payload, but a human reviewer never sees them in the interface. Even setting obfuscation aside entirely, tool descriptions generally don't appear in client interfaces during normal operation at all, so a user has no way to see what instructions their agent is actually running on once the tools have loaded.

Audit logs don't help close that gap, because the action happens inside a tool you already approved. The log shows the expected tool name being invoked, exactly as it should, and it shows no trace of the mutated instruction sitting inside that tool's description. When a human actually looked at something, the approval happened before the mutation ever occurred.

Lab testing shows how often this evasion actually works. The CSA's benchmarking data recorded attack success rates above sixty percent across more than 45 real-world MCP servers, with the best-performing agent model reaching 72.8% in testing.

Local transport adds a further blind spot, one that gateway-style defenses were never built to see. Local stdio MCP sessions run entirely on the endpoint, outside the network inspection boundary that gateway and proxy controls assume exists, even when that session touches regulated data and privileged tools. The risky action happens where policy enforcement has no visibility. None of this is still being treated as a hypothetical by the security community: OWASP has formally codified tool poisoning as MCP03:2025 in its MCP Top 10 project, grouping it with rug pulls and tool shadowing as attacks on the capability supply chain. That classification is a signal that these are catalogued, confirmed attack patterns rather than edge cases worth a footnote.

Protocol-level gaps and compliance obligations in 2026

The structural gaps documented across tool poisoning, rug-pulls, impersonation, and OAuth abuse have stopped being a problem confined to security engineering teams. As of 2026, several regulatory frameworks have extended their scope to cover precisely the conditions these attacks rely on: optional authentication, undefined authorization, one-time approval with no re-validation, and credential aggregation across connected services. That shift changes what "secure enough" means for any organization running MCP in production.

An unauthenticated server, an unverified registry entry, or a tool description that can mutate after approval is more than a technical exposure now. It's a condition regulators now expect organizations to have identified and controlled for. The burden of proof shifts from "did the vendor get hacked" to "did the organization verify that these specific protocol-level weaknesses could not exist in its deployment." The defenses that actually close the exposure, cryptographic signing of tool definitions, mandatory re-approval on manifest change, scoped tokens instead of ambient authority, provenance verification at the registry level, are becoming the baseline a compliant deployment has to meet.