How MCP Servers Get Attacked and What Stops It

Model Context Protocol has become the default way AI agents talk to tools, databases, and outside APIs, and that convenience has quietly opened up a set of attack paths that most security teams have never had to think about. This piece maps those paths one by one, matched against the defenses that actually close each gap, because bolting old application-security habits onto MCP leaves most of the surface untouched.

The scale involved is not small. MCP SDKs are pulling roughly 97 million downloads a month, more than 10,000 public servers are active, and every major AI client, ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, Visual Studio Code, now speaks the protocol natively. It went from a niche spec to the connective tissue of enterprise AI in under 18 months, and governance never caught up. What makes this dangerous isn't stored data sitting in a database somewhere. MCP servers hold live tool privileges, active credentials, and write access to production systems. A compromised server is a foothold with execution authority. It's a foothold with execution authority.

The structural properties of MCP that create novel attack surfaces

A tool description gets reviewed once, at connection time, by a human or an approval workflow, and that asymmetry is at the root of nearly every MCP attack. After that, tool responses flow straight into the model's context window at runtime, and nothing checks them with the same rigor. The front door gets a background check. Everything that walks through the mail slot afterward does not.

Trace the actual data path and the gap gets clearer. User input goes to the AI model, which is built to interpret intent rather than sanitize input. From there it reaches the MCP client, which the protocol spec does not mandate to perform rigorous input validation. Only then does it hit the MCP server and whatever external system sits behind it. Three hops, and real inspection happens at maybe one of them.

That's not an accident born of sloppy implementation. The MCP specification was not designed with defenses against tool poisoning, rug-pull redefinition, or cross-server tool shadowing in mind. Those are default conditions of the architecture, present in a correct implementation of the spec as written. They're default conditions of the architecture, present in a correct implementation of the spec as written.

The scale of that gap became concrete in April 2026, when OX Security disclosed a systemic flaw sitting inside every official MCP SDK, a flaw that had already propagated into countless downstream projects built on top of them. The estimate of around 200,000 vulnerable instances was traced through more than 150 million package downloads. That's a default in the reference implementation itself, copied faithfully by everyone who built on top of it. It's a default in the reference implementation itself, copied faithfully by everyone who built on top of it.

Tool poisoning and prompt injection: how the agent's context window becomes the attack surface

The mechanism is almost embarrassingly simple once it's spelled out. A malicious MCP server writes hidden instructions into a tool's description, or into the data a tool returns, and the language model reads that text as trusted input, because from its position, the server's chosen wording and an attacker's injected command look the same.

Invariant Labs put a name to this in April 2025: Tool Poisoning Attacks. Their proof-of-concept showed that instructions buried in an MCP tool description cause the agent to execute them silently, as though they came from the user or the system prompt. Whoever controls the description controls a hidden channel into the model's behavior, and the risk multiplies in any client configured to auto-approve tool calls without a human in the loop.

This isn't a lab curiosity. An academic study by Hasan and colleagues scanned 1,899 live MCP servers and found tool poisoning present in about 5.5% of them. A separate scan by AgentSeal, covering 1,808 servers, found some kind of security finding in 66% of them, a much broader net that catches more than poisoning alone. The two numbers measure different things, so they shouldn't be read as the same claim twice. But together they rule out the idea that this is theoretical. OWASP has already folded the pattern into its MCP Top 10, filed alongside rug pulls and tool shadowing as an established class, not an edge case.

Rug pulls, tool shadowing, and cross-server exfiltration: attacks that span the session

Tool poisoning is the opening move. What happens after connection is where things get genuinely strange.

A rug pull works by silent redefinition: a server presents one set of tool descriptions at connect time, gets approved, and then quietly changes those descriptions later in the session. The agent has no built-in mechanism to notice, and neither does the user, because the review that mattered happened once, at the start, and nothing re-checks it.

Tool shadowing is a related but distinct move. A malicious server poisons its own tool descriptions, not to attack itself, but to plant instructions aimed at a second, legitimate server the agent also has connected. The agent ends up using a trusted server as an unwitting relay, following instructions that originated from the untrusted one.

Invariant Labs demonstrated exactly this chain in April 2025, using a novelty server billed as a "random fact of the day" generator. Buried inside its tool description sat hidden instructions that told the agent to reach into WhatsApp message history through a separate, legitimate whatsapp-mcp server the same agent had connected, and then leak that history out as what looked like ordinary outbound traffic. End-to-end encryption on WhatsApp itself was irrelevant. The exfiltration happened above the encryption layer entirely, through legitimate agent access that the messaging protocol has no way to see or stop.

The blast radius matters more as agents connect to more servers at once. In sessions running five concurrent MCP servers, a cascade rate of 72.4% was recorded once a single server was compromised, so the damage from one poisoned connection does not stay contained to that connection. It moves.

Session hijacking, OAuth weaknesses, and the authentication gap at scale

Some of the worst-rated MCP vulnerabilities on record live in the authentication layer. CVE-2025-6514, found in mcp-remote, let attackers plant a malicious authorization_endpoint that injected OS commands through unsanitized URL input during the OAuth handshake, achieving remote code execution on the client machine itself. It carries a CVSS score of 9.6 and affected more than 437,000 installed environments, a flaw in the identity handshake deployed at scale. That's a flaw in the identity handshake, deployed at scale. That's a flaw in the identity handshake, deployed at scale.

MCP's sampling feature, which lets a server request LLM completions back through the client, opens another channel the spec doesn't fully anticipate. Without safeguards around it, a malicious server can use that channel for purposes well outside its intended scope.

Then there's infrastructure hygiene, which sounds boring until it isn't. MCP servers hosted behind tunnel services like ngrok are vulnerable to subdomain hijacking: once a tunnel session ends, an attacker can register that same subdomain and quietly intercept whatever traffic arrives next, traffic that assumes it's still talking to the original server.

A plainer problem produces all of it: the model cannot distinguish an instruction's source from its content. Servers lacking proper transport security expose OAuth tokens, API keys, and session metadata to anyone positioned to intercept network traffic. Trend Micro's initial internet scan found 492 servers sitting exposed with zero authentication of any kind, no encryption, no client verification, nothing standing between an anonymous request and the tools behind it.

Supply chain compromise and secrets sprawl: the registry as an attack vector

Registries are where MCP's supply chain problem becomes visible, because a registry is just a place where trust gets assumed by default.

The clearest case so far: postmark-mcp on npm, disclosed September 25, 2025 by Koi Security and covered by Snyk. A malicious version, version 1.0.16, silently BCC'd every email the server processed to an outside domain. It pulled around 1,500 downloads, and Koi Security estimated close to 300 organizations had already wired it into real production workflows before the disclosure. That's the first publicly documented malicious MCP server of its kind in the ecosystem, and it likely won't be the last, given how the registry model works.

The OpenClaw/ClawHub agent-skill ecosystem tells a similar story at larger scale. Antiy CERT confirmed 1,184 malicious skills circulating in it. Snyk's ToxicSkills audit went deeper, examining 3,984 skills and finding that 13.4% carried at least one critical security issue.

Endor Labs looked at the code itself, across 2,614 MCP implementations, and the pattern is structural rather than incidental: 82% used file operations prone to path traversal, 67% used APIs tied to code injection, and 34% used APIs susceptible to command injection. These are recurring code patterns baked into how MCP servers tend to get written, not isolated bugs that a patch cycle quietly resolves.

Secrets sprawl compounds all of it. GitGuardian found 24,008 secrets sitting in MCP-related config files on public GitHub repositories, and 2,117 of them were still valid, live credentials, publicly visible, waiting.

Cloud-layer escalation: when MCP compromise becomes infrastructure compromise

An exposed MCP server used to mean an exposed dataset. Trend Micro's research shows it now means something closer to an exposed cloud account, because the servers themselves are becoming a direct vector into infrastructure. A later scan by Trend Micro found the count of exposed servers had nearly tripled, up to 1,467.

What's actually sitting on those exposed hosts is the alarming part. Trend Micro found an "execute_sql" tool live on 70 of them, a "Graphiti Agent Memory" implementation on 39, and at least three servers exposing patient medical records through a "progress_note" feature, unauthenticated, reachable from the open internet.

Trend Micro, working through the Zero Day Initiative, disclosed a cluster of critical cloud-facing MCP vulnerabilities that all land near the top of the severity scale: ZDI-CAN-28042 in a Microsoft product, CVSS 9.8, alongside CVE-2026-5059 and CVE-2026-5058 in aws-mcp-server, both also rated 9.8. Every one of them allows an attacker to bypass security controls and run unauthorized commands inside the cloud environment itself.

The attack chain reads like this: discovery of an exposed server, exploitation of its missing authentication, theft of exposed credentials, and lateral movement across connected cloud services. Each step is enabled by the last.

The governance gap that amplifies every technical vulnerability

None of the preceding sections would matter as much if organizations were watching closely. Most are not. A formal identity strategy covering AI agents exists at only 23% of organizations. Only 14.4% of agents that get built ever reach production with full security approval attached. Only 24% of enterprises have a dedicated team responsible for AI security governance specifically.

Gartner projects that 15% of enterprise generative AI applications will experience at least one major security incident per year by 2029, up from 3% in 2025, and that by 2028 a quarter of enterprise breaches will be traced to AI agent abuse. Those figures reflect a trajectory tied to how broadly tools like MCP are being adopted.

AI has introduced a new, high-volume class of digital users, in the form of autonomous agents, and the SSE and SASE platforms built to secure traditional users and endpoints were never designed with that kind of user in mind. They watch for people clicking links and downloading files. They were not built to watch an agent negotiate a tool call.

Researchers, meanwhile, are well out ahead of enterprise defenses. Security researchers have logged a sharp surge in prompt-injection vulnerability reports as the attack class has matured. The people paid to break these systems have already mapped territory that most governance programs haven't started walking.

Defense layer one (authentication, transport security, and eliminating unauthenticated exposure)

Fixing this starts with the boring stuff, and boring is not an insult here. TLS on every MCP transport path, full stop, with no plaintext HTTP endpoints tolerated anywhere in a production deployment. That single rule would have closed off the 492 exposed servers Trend Micro found in its first scan.

The November 2025 MCP specification formalized OAuth 2.1 as the authorization standard for remote MCP servers, which matters because the base spec still marks authorization as OPTIONAL. The Cloud Security Alliance's Agentic MCP Security Best Practices whitepaper treats OAuth 2.1 as the authentication floor for any production deployment. Given the CVE-2025-6514 numbers, that floor is not optional in practice even where it's optional on paper.

Tunnel hygiene deserves its own line item. Production MCP servers should not sit behind ephemeral tunnel services like ngrok, where subdomain reassignment after a session ends creates an opening for interception that has nothing to do with the server's own code.

And the pattern Trend Micro documented, an internet-facing MCP server with zero client authentication, should get treated the way a security team treats an open database port: a critical misconfiguration demanding immediate remediation, not a design choice someone made deliberately and should be allowed to keep.

Defense layer two (tool integrity verification and runtime response scanning)

Authentication stops the wrong people from connecting. It does nothing about a legitimate, authenticated server that turns hostile mid-session, which is exactly the rug-pull pattern described earlier.

Hash-pinning closes that gap directly. Capture a digest of each approved tool description at connection time, and alert or block outright the moment that digest changes during the session. A rug pull depends on the agent never noticing the swap. Hash-pinning makes the swap visible the instant it happens.

Static scanning of tool descriptions at connect time catches a different slice of the problem, hidden instructions embedded in the text before the agent ever acts on it. Useful, but not sufficient by itself, because it only ever looks at the moment of connection.

The harder requirement, and the one most deployments skip, is runtime scanning of every response a tool returns, for the life of the session. Treat inbound tool output the way a browser treats raw HTML from an untrusted site: assume it might carry something hostile until proven otherwise. The GitHub MCP server incident showed why this matters. The poisoning there sat entirely inside returned data, not inside any tool's metadata or description. A defense that only checks descriptions at connect time would have missed it completely.

Taken together, these two defense layers cover different failure points along the same pipeline mapped earlier: authentication and transport security block the unauthorized connection, while tool integrity and runtime scanning catch the authorized connection that goes bad afterward. Neither one alone closes the loop. MCP's architecture created the gap between connect-time trust and runtime execution, and closing it requires defenses built for that specific gap, not general-purpose tools retrofitted to fit a shape they were never designed for.