MCP Server Identity Spoofing and Impersonation Attacks

MCP server identity spoofing works because of a design choice, not a bug. Model Context Protocol servers get approved by name and description, never by a verified identity that sticks around and gets rechecked. So the server an agent trusted when a human clicked "approve" might not be the thing answering requests an hour, a week, or a month later. Six distinct attack patterns fall out of that one gap: typosquatting, tool shadowing, rug pulls, and three separate flavors of identity spoofing at the host and OAuth layers.

Start with the basic handshake, because everything else builds off it. A client asks a server what tools it has. The server answers in plain text descriptions. The host then drops those descriptions straight into the model's context as trusted input, no filter, no separation between "this text describes what the tool does" and "this text tells the model what to do." That's the core problem: metadata doubles as documentation and as an attack surface, and the protocol has no way to tell those two jobs apart.

Early versions of MCP shipped with no authentication at all. The March 2025 spec (version 2025-03-26) added an OAuth 2.1 authorization framework for remote servers, and the November 2025 update (2025-11-25) refined it further. That's real progress, but most servers running today were built and deployed before either update existed. So the practical result is that the identity an agent trusted at approval time and the identity actually operating at invocation time can quietly diverge, and nothing in the protocol forces a recheck.

This isn't mainly a code-execution problem. It's an identity governance problem. MCPManager, Usercentrics' AI data-access governance layer, is built for exactly this kind of problem. A server holding a trusted name holds standing access to whatever permissions that name was granted, indefinitely, until someone notices otherwise. SlashID's analysis frames it well: MCP servers behave like non-human identities with standing access, which means managing them looks a lot less like managing a plugin list and a lot more like managing a fleet of privileged service accounts.

How the ecosystem's verification gap turns the naming flaw into a practical attack surface

Four major registries host MCP servers today, and their security postures could not be more different.

GitHub runs a curated collection of 57 official entries from established providers. It's the gold standard for verification, and also the smallest by a wide margin. Smithery holds over 3,500 servers with open community contributions; a sample of 847 servers found only 8% carrying an "official" badge, meaning 92% are unverified. A registry that launched in late 2025 lists roughly 1,000 servers and currently has no formal verification property at all. And MCP.so, the largest of the four with over 17,000 servers, uses "featured" and "official" labels with criteria vague enough that it functions as the ecosystem's least governed tier.

UpGuard's research found between 3 and 15 unverified lookalike servers for every legitimate brand name, roughly 10 to 16% of all servers examined. Registration endpoints at most registries take submissions without checking who's actually submitting them. "Local" server types often get waved through with no authentication requirement whatsoever, treated as low-risk by default.

A study covering 67,057 servers across six public registries found conditions ripe for hijacking and invocation manipulation across the board. The researchers' scanning tool, MCPInspect, flagged 833 vulnerable servers and 18 with descriptions that were outright suspicious. Separately, the State of MCP Server Security 2025 report found only 18% of deployments use any access scoping for tool permissions, and 53% expose credentials through hard-coded values sitting in config files.

Put it together and the picture is stark: a fast-growing ecosystem where most servers go unverified, most deployments are barely scoped, and the server's name is often the only trust signal a user or an agent ever checks.

Typosquatting and name-collision impersonation: exploiting the moment of installation

The mechanism is simple enough to explain in one sentence. An attacker registers a server with a name identical or nearly identical to a legitimate one, and anyone installing from a public registry is relying on that name and description alone, with no cryptographic check behind it.

There are two moments this gets exploited. First, at deployment: a person browsing a registry picks a server by name, the same way anyone picks a package off npm. Second, at runtime: the MCP host itself selects among available servers using textual identifiers, which means the identical attack surface reopens later in the lifecycle, invisible to the end user entirely.

A proof-of-concept from early 2026 shows exactly how narrow the margin is. Researchers targeted a widely used server and built a clone with a single-character name change — a doubled letter. They demonstrated how easily a near-identical server name could be registered without triggering registry defenses.

A quieter variant swaps separators or casing instead of letters: google-drive-connector versus google_drive_connector. To a human skimming a list, the difference barely registers. To the automated tool-selection logic inside an agent, it may not register at all.

Multi-tenant environments make this worse. When multiple organizations register servers with overlapping or similar names, and there's no central namespace authority keeping them apart, collision risk compounds fast.

What makes typosquatting durable as an attack category is that it needs no exploit of the protocol whatsoever. It exploits naming conventions and a completely reasonable human assumption: that a familiar-looking name belongs to the familiar server.

Tool shadowing: hijacking agent behavior without ever appearing in the interaction log

Tool shadowing works differently, and it's arguably more dangerous precisely because it doesn't require impersonation at all. A malicious server sits in the environment and injects a tool description that changes how the agent behaves toward a completely different, trusted service. The attacker's own tool is never invoked. Every visible action the agent takes still runs through the trusted server.

That's what makes shadowing structurally distinct from a lookalike attack. The attacker doesn't need the agent to call their tool. They only need their injected description to land inside the model's context, once, and the damage is done from there.

Research confirms that injected tool descriptions alone can be enough to hijack behavior toward a trusted server, meaning data can leak or actions can get manipulated through tools the user believes are perfectly safe. Combine that with a rug pull (the next section covers exactly how), and a malicious server can steer an agent without ever showing up in the user-facing log. Only the trusted tool names appear in what the user actually sees.

Research into MCP servers in the wild found 5.5% carrying tool poisoning vulnerabilities. Separately, a study of 1,899 open-source MCP servers found 33% allow unrestricted network access, a different sample but a condition that makes any shadowing attack that does land a lot more damaging.

The stealth property here is the whole danger. A standard audit log answering "which tools got called" gives no signal at all that a poisoned description shaped what those calls actually did.

Rug pulls: post-approval mutation and why one-time consent breaks down

A rug pull starts with good behavior. The server acts exactly as advertised, earns approval, and then, sometime later, changes: different tool descriptions, different data access, different permission requirements, all without triggering any new consent prompt.

Most MCP hosts bind trust to a tool's name, not to its actual content. So when the underlying behavior shifts, the approved name stays put, and the host keeps treating the now-different server as though nothing happened.

CVE-2025-54136, tracked as MCPoison, is Check Point's formal demonstration of exactly this. Cursor kept blindly trusting config keys it had already approved, even after the command sitting behind those keys had been swapped out entirely.

The update mechanics make this worse than it sounds. Package managers like npm, pip, and Cargo don't auto-update by default, updates need an explicit command. But tool descriptions are just text. A malicious update needs no compiled binary, leaves no obvious trace in a changelog, and can slip through with nobody the wiser.

The clearest real-world case so far: an unofficial Postmark MCP server, downloaded roughly 1,643 times total, got modified in September 2025 to quietly add a BCC field to its send_email function. Every outgoing email started getting copied to an attacker-controlled address. Anyone running the modified server began leaking email content with zero indication anything had changed. It's the first confirmed malicious MCP server found in the wild, and it demonstrates the gap perfectly: the identity an organization approved was a snapshot in time, and the server running weeks later was a different thing wearing the same name tag.

Identity spoofing at the host and OAuth layers: where the protocol's authentication gaps get exploited

Host-layer spoofing works by forging or altering identity metadata so the host misreads who's actually making a request, or at what privilege level. A normal request gets dressed up to look like it came from an administrator, and the host executes commands it should have blocked outright.

DNS rebinding is a related but separate route in. An attacker compromises a DNS record so a trusted domain now points at a malicious IP address. The agent resolves what it believes is the legitimate domain and connects straight to the attacker's infrastructure instead. The trust here was never actually tied to the server's behavior, only to the domain name, and that's exactly the assumption getting exploited.

OAuth introduces its own version of the problem through what's called a confused deputy attack. MCP proxy servers acting as gateways to third-party APIs can be manipulated by combining a static client ID with dynamic client registration: an attacker tricks a user into granting an authorization code, redirects that code to the attacker's own server instead, and walks away with access tokens while impersonating the user.

Token passthrough is a related anti-pattern, and it's explicitly banned in the spec for good reason. It happens when an MCP server forwards a client's access token straight to a downstream API without ever checking that the token was meant for that server in the first place. Doing this quietly bypasses rate limiting, audience validation, and audit controls all at once.

The clearest disclosed example is the GitHub MCP server's "Toxic Agent Flow," reported by Invariant Labs on May 26, 2025. A specially crafted GitHub Issue could hijack a user's agent and pull data straight out of private repositories, on a server with broad real-world use. Invariant Labs was direct about what this meant: the issue was architectural, not a bug sitting in one server's code. That framing matters, because it means the vulnerability class doesn't go away with a single patch.

Replay injection rounds out the list. A previously valid interaction gets reused maliciously, so replaying an already-approved fund transfer request causes the host to issue the transaction again, with no new prompt to the user at all.

Every one of these vectors, different as they look on the surface, exploits the same assumption: that whoever presents valid credentials or a recognized name right now is the same entity that earned that trust a moment ago.

What the attack taxonomy reveals about where defenses actually need to sit

Six attack types, one root cause. Trust in MCP gets bound to a static identifier, a name, a label, an approval record from some point in the past, rather than to a verified identity that gets rechecked continuously and scoped tightly.

One-time consent stops functioning as a security control the moment tool behavior, server content, or DNS resolution can all shift after approval. Re-verification has to attach to versioned, signed server definitions, not to a display name that never changes even when everything behind it does.

Treating tool metadata as automatically trustworthy is the control-plane failure that makes both tool poisoning and shadowing possible in the first place. Policy enforcement needs to govern what a server is actually allowed to invoke, not the words it happens to use describing itself.

The finding that only 18% of deployments implement any access scoping, and that 53% expose credentials through hard-coded values, aren't side notes. They describe a deployment culture still treating MCP like an ordinary plugin system, when what it actually demands is inventory, scoped permission, and audit, the same discipline applied to any fleet of privileged non-human identities.

Registry diversity turns this into a governance problem no single team can solve just by picking a "safer" registry. Any enterprise connecting to servers in an unverified tier needs its own enforcement layer sitting between the registry and the agent, full stop.

Real-time visibility matters here specifically because rug pulls and shadowing attacks are built to look exactly like normal operation. An audit log read after the fact, the way the Postmark BCC backdoor was eventually discovered, is a postmortem. It's not a safety net. The actual control value comes from catching behavioral drift while it's happening, not from reconstructing it afterward.

A centralized MCP gateway, one with a real server registry, enforced access controls, and observability running in real time, addresses this exact structural gap across the whole taxonomy. It turns "what servers are approved, at what version, with what permissions" into a governed state that can be inspected at any moment, instead of a one-time decision left to quietly drift. That's the model a centralized MCP governance approach is built around, applying rigorous identity and access governance to the problems the MCP layer introduces.

For enterprise teams, blocking MCP outright just pushes adoption into ungoverned paths anyway, off the record and out of sight. The organizations moving fastest without getting burned are the ones that built a governed path first, because the guardrails are exactly what let them say yes to production with confidence instead of hoping nothing changes underneath them.