MCP Attack Surface Mapping Before Deployment

MCP servers ship with a discoverable attack surface built into the protocol itself: exposed tool metadata, registry entries nobody really vetted, credential stores sitting in plaintext config files, authentication gaps the spec didn't originally require. Mapping that surface before a server goes into production is the difference between choosing your risk and finding out about it after someone else already did. Anthropic introduced MCP in late 2024, and by 2025 it had client support built into Claude, ChatGPT, Cursor, Gemini, Microsoft Copilot, and VS Code. The SDK crossed 150 million downloads across package registries, with more than 97 million monthly downloads in 2025, and somewhere north of 9,400 public servers were indexed across major registries by mid-2026. The real count, once private and enterprise-internal servers get added in, is probably three or four times higher than that.

On December 9, 2025, Anthropic handed MCP over to the Agentic AI Foundation under the Linux Foundation. Platinum members include Amazon Web Services, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI. That's not a signal of a passing experiment. That's a protocol settling in for the long haul.

Security did not keep pace, and it isn't close. The Cisco State of AI Security 2026 report found only 29% of organizations feel prepared to secure agentic AI applications, which leaves 71% running agents they can't properly monitor, audit, or respond to. Only 14.4% of agents reach production with full security approval. Just 23% of organizations have a formal AI-agent identity strategy. Adoption ran ahead of governance, and that gap is exactly why attack surface mapping has to happen before deployment, not after the fact.

How MCP's architecture creates three independently exploitable trust boundaries

MCP's design splits trust across three points, and each one can fail on its own, without any help from the other two.

The first sits between the LLM and the MCP client. The model reads tool descriptions and builds its own invocations from them, but it has no way to check whether those descriptions are accurate or whether someone tampered with them. It just trusts what it's given, full stop.

The second sits between the MCP client and the servers it talks to. The client is supposed to authenticate to servers and check their responses, but a lot of current setups do this poorly or skip it outright. The original MCP 1.0 spec didn't require authentication at all, and it had no way to scope permissions per operation. Connect an agent, and it got the full set of capabilities. All or nothing, no middle setting.

The third sits between MCP servers and whatever they touch downstream: file systems, databases, external APIs, cloud services. Servers act like agents in their own right, often with permissions far broader than the task in front of them actually requires.

The first cross-entity security study of the ecosystem, covering 67,057 servers across six public registries, found a two-stage version of this same problem. At the registry level, weak vetting lets adversarial or hijacked servers get listed in the first place. Post-integration, attacker-controlled tool metadata shapes how the LLM reasons and pushes it toward operations the host executes without checking. An attack on one boundary doesn't stay contained there. It moves through the whole pipeline, which is what makes this different from a normal API integration, where a bad endpoint stays a bad endpoint and doesn't infect the ones around it.

The November 2025 spec update (version 2025-11-25) finally formalized OAuth 2.1 as the authentication standard for remote servers. Adoption hasn't caught up though: only 8.5% of public servers actually use it. The spec matured faster than the servers running on it.

A March 2026 taxonomy from Shen, Toyoda, and Leung, called MCP-38, catalogs 38 distinct threat categories that fall out of this architecture. The rest of this piece covers the ones showing up most often in confirmed incidents and independent scans.

Tool poisoning: the attack class that exploits structural trust in tool descriptions

Tool poisoning means hiding malicious instructions inside tool metadata, the descriptions and parameter schemas, so they land in the model's context window and get treated as trusted, developer-authored content. Don't confuse it with prompt injection. Regular prompt injection rides in through user text, which most security stacks already scan for. Tool poisoning exploits metadata the model assumes came from the developer, not from an attacker, and that assumption is exactly the hole it climbs through.

Invariant Labs put out the first public proof-of-concept in April 2025. A single poisoned tool description exfiltrated private repository contents and message histories, no user interaction needed at all. Lab testing across more than 45 real-world MCP servers found attack success rates above 60%, and the best-performing model in testing hit 72.8%. Separately, a 2025 scan of open-source MCP servers found 5.5% carrying this exact issue, opening the door to over-privileged access. OWASP now tracks it formally as MCP03:2025 in its MCP Top 10.

Research out of NYIT (Huang, Huang, Tran, Milani Fard, March 2026) looked at seven major MCP clients and found five had no static validation of tool metadata whatsoever, none. Users generally can't see the full tool description while the agent is running, and even the approval dialogs that do show parameters often require horizontal scrolling to read them in full. Malicious content slips through easily. Add approval fatigue, the thing where a user clicks "allow" on the fifteenth prompt without reading a word of it, and the check turns into theater.

None of this stays theoretical for long. In April 2025, researchers demonstrated a WhatsApp MCP integration where a poisoned tool description let an attacker pull entire message histories, just by inserting hidden instructions that quietly redirected how the agent used the legitimate integration.

Before any server goes live, every tool description and parameter schema needs a human eye on it, checking for instructions that don't belong there. Server reputation doesn't matter here, and treating a well-known name as a shortcut past this check is exactly the mistake that keeps producing incidents. Treat the metadata as untrusted, full stop, no exceptions for the servers everyone already trusts.

Rug pull attacks: when trust is bound to a name rather than to content

A rug pull works like this: a server passes review, gets added to mcp.json, runs clean for weeks or months. Then an update quietly changes the tool's description, behavior, or underlying code. Most hosts wave the update through without re-prompting the user, because trust got attached to the tool's name, not to what it actually does day to day.

The mechanism hides inside routine software hygiene. Common package managers can be configured to auto-update by default. A malicious change doesn't need a new compiled binary or a suspicious installer behind it. One added line in a docstring is enough to turn a trusted tool hostile overnight.

Rug pulls sit alongside tool shadowing as attacks on the capability supply chain. CVE-2025-54136, nicknamed "MCPoison," hit Cursor with a CVSS score of 8.8, disclosed in July 2025. It confirmed something uncomfortable: once a tool definition gets approved in a production AI development environment, that approval doesn't survive later server-side changes. Approval is a temporary state, not a lasting contract. It's a snapshot, and the rug pull is just what happens when nobody checks whether the snapshot still matches reality.

Mapping this before deployment means knowing which servers are version-pinned and which auto-update, then building a re-approval process that fires when a tool description changes, not one that only fires when a version number ticks up.

Tool shadowing and cross-server attacks: poisoning a server you never directly invoke

Tool shadowing skips the direct route entirely. A malicious server injects instructions into the agent's shared context that alter how it behaves when talking to a completely different, trusted server. The user never has to invoke the bad tool. The bad tool just has to be sitting in the same session.

Mechanically, it works because the agent treats every tool description it sees as equally authoritative, regardless of which server it came from. A poisoned description on Server A can carry hidden instructions that redirect or corrupt output coming from Server B, and the agent complies because nothing in its reasoning process flags the difference between the two.

In November 2025, Anthropic's own official Git MCP server turned up with a path validation bypass, an argument injection flaw, and unsafe repository initialization. Chained with a filesystem server, those flaws could be strung together into remote code execution or unauthorized file changes, triggered through prompt injection. The reasoning is straightforward: most research attention goes to server-side flaws, but cross-server attacks start on the client side, exactly where validation is weakest and least scrutinized.

Pre-deployment mapping needs to list out every pair of servers that could plausibly share an agent session, and treat that pairing as its own attack surface, not just an extension of single-server risk.

Confused deputy and credential exposure: how over-privileged servers become pivot points

The confused deputy problem is old, but MCP gives it new legs. An MCP server executes actions with its own elevated privileges instead of checking what the requesting user is actually allowed to do. A user with no database admin rights asks the agent to run a query; the server, which does have admin rights, just runs it anyway. No check happens in between the two.

Compounding this, MCP servers often hold credentials and API keys that every connecting client inherits, whether it needs that access or not. Every client that connects to that server inherits whatever privileged access those credentials unlock, whether it needs it or not.

CVE-2026-13341, affecting Kong Konnect, showed this at production scale: an indirect prompt injection against the Kong Konnect MCP server made it execute unintended API requests. Then there's CVE-2026-33032 in nginx-ui, CVSS 9.8, where an MCP endpoint was missing authentication for command execution entirely, not partially, entirely. Over 2,600 exposed instances were vulnerable to full nginx service takeover.

Independent analysis of MCP implementations has found widespread use of file operations prone to path traversal and APIs tied to code and command injection risk. Before any of this reaches production, every server needs a written record of what credentials it holds and at what privilege level, followed by least-privilege scoping applied before launch, not retrofitted after something breaks in production.

Supply chain vectors: name-squatting, shadow servers, and dependency confusion

Name-squatting is exactly what it sounds like: an attacker publishes a server with a name close enough to a legitimate one that people install the wrong thing without a second look. OWASP tracks the broader pattern, unsanctioned internal servers, as shadow MCP servers, basically the MCP version of shadow IT. Dependency confusion works a similar angle: a malicious package resolves ahead of the intended internal one and gets pulled into a build automatically, no attacker interaction needed after the initial upload.

The first confirmed malicious MCP server in the wild showed up in September 2025: a fake npm package called postmark-mcp, dressed up as a legitimate email integration tool. It had a hidden backdoor that silently BCC'd every outgoing email to an attacker-controlled address. Any outgoing email the organization sent was silently copied to an attacker-controlled address. Koi Security estimated around 300 organizations had already integrated it into real workflows by the time it was caught, and the package was pulling about 1,500 downloads a week at the point of discovery.

Don't treat the registry layer as a safe starting assumption either. The cross-entity study of 67,057 servers across six registries found conditions ripe for server hijacking baked directly into how those registries operate. Independent scans back this up with grim consistency: Independent scans of the roughly 7,000 internet-exposed MCP servers catalogued by early 2026 found widespread critical vulnerabilities across a substantial share of those servers.

Before integrating anything, provenance needs verification against a maintained registry. Any server without a confirmed organizational owner should get treated as untrusted, no exceptions carved out for convenience.

STDIO transport and RCE by architectural design

Some of this risk is a feature that made it through, not a bug that slipped through. It's a design choice, baked in from the start. OX Security's April 2026 report, "The Mother of All AI Supply Chains," describes a systemic remote code execution flaw in Anthropic's MCP SDK: the STDIO interface carries a systemic remote code execution flaw present across the Python, TypeScript, Java, and Rust SDKs. The flaw shows up across the Python, TypeScript, Java, and Rust SDKs alike, all four.

CVE-2025-6514 hit mcp-remote, versions 0.0.5 through 0.1.15, CVSS 9.6. JFrog Security Research found it, published July 9, 2025, affecting a package with over 437,000 downloads behind it. It was the first confirmed case of full RCE landing on a client's operating system, triggered simply by connecting to an untrusted remote MCP server, nothing more. Fixed in v0.1.16, for anyone still running an older build.

CVE-2025-49596 hit Anthropic's own MCP Inspector, CVSS 9.4, via a combination of browser and DNS rebinding plus a 0.0.0.0 binding issue. Patched in v0.14.1 on June 13, 2025. Then there's the pair CVE-2025-66414 and CVE-2025-66416, affecting the TypeScript SDK before 1.24.0 and the Python SDK before 1.23.0 respectively: DNS rebinding protection wasn't turned on by default for HTTP-based servers, meaning a malicious website could exploit rebinding to slip past the same-origin policy and call tools on a user's behalf without asking. Separately, Trend Micro's 2025 research turned up CVE-2025-53110 and CVE-2025-53109 in the Filesystem MCP Server, a directory containment bypass at CVSS 7.3 and a symlink bypass at CVSS 8.4.

A normal application-layer review won't catch any of this. Transport configuration, STDIO binding scope, whether DNS rebinding protection is actually switched on, SDK version, all of it needs its own checklist line before deployment, separate from everything else, not folded into a general security pass.

Multi-agent pipelines and toxic flow propagation across chained MCP processes

Chain enough agents together and one agent's output becomes the next one's input. Malicious content dropped anywhere in that chain doesn't stay put where it landed. It propagates, and it can trigger unauthorized actions, leak data, or hijack control flow several steps downstream from wherever it first entered the system.

The MCP-38 taxonomy from March 2026 names two of the patterns behind this: parasitic tool chaining and dynamic trust violations. Combined, the semantic attack surface these create has no real counterpart in classical software security. It doesn't show up in the OWASP Top 10, and standard LLM security frameworks skip it too, since it's a problem specific to how agents hand trust off to each other, not a problem either field was built to catch.

CVE-2025-54135, nicknamed "CurXecute," is the clearest demonstration of the full chain in action, start to finish. Disclosed by AIM Security on August 1, 2025, it affected Cursor prior to version 1.3, CVSS 8.6. A crafted Slack message, processed through a Slack MCP server the user had already approved, carried a prompt injection payload. That payload directed Cursor to rewrite its global configuration file, ~/.cursor/mcp.json, and insert a new server entry pointing at attacker-controlled code. Because Cursor auto-executed new MCP server entries without asking again, the payload ran on the very next IDE interaction. No further clicks, no second approval, nothing standing in the way of it.

Cursor got the report on July 7, 2025, and shipped version 1.3 on July 29, twenty-two days from disclosure to patch. The chain here runs from an external data source, through a server the user had every reason to trust, straight into the configuration file governing every other server on the system. That's the entire attack surface this piece has walked through, compressed into a single incident.