MCP Security Vulnerability Classes and Mitigations

Model Context Protocol turned one year old in late 2025, becoming, in that span, the plumbing for how AI agents talk to enterprise systems. That speed is the story. Anthropic shipped MCP in late 2024, every major LLM provider had adopted it by mid-2025, and by December the protocol's SDKs were pulling 97 million downloads a month with more than 10,000 public servers running in the wild. It has since moved to the Agentic AI Foundation, a Linux Foundation project co-founded with Block and OpenAI and backed by Google, Microsoft, AWS, Cloudflare, and Bloomberg, which means MCP is no longer one company's bet. It's shared infrastructure now, the kind nobody gets to unilaterally patch or walk back.

The thing that makes MCP different from a normal API isn't philosophical, it's structural. In a regular API, your application code decides what function to call and with what arguments; a developer wrote that logic and it doesn't change unless someone ships new code. In MCP, the LLM makes that call. It reads a tool's description, decides the tool is relevant, and picks the parameters, all based on text it's treating as trustworthy context. The model is the decision surface. That single architectural fact is why traditional API security, built around validating inputs and outputs at a fixed boundary, doesn't map cleanly onto this problem. The attack surface now includes the metadata the agent reads to reason, the credentials it carries between systems, and every downstream server it's allowed to touch.

Scale makes the exposure worse, not better. Enterprises running production agents typically wire up somewhere between 8 and 16 MCP servers, each exposing 20 to 60 tools, which turns a single agent into a decision-maker sitting on top of a few hundred possible actions it didn't write and can't fully audit. Team8's CISO Village Survey found 70% of enterprises already run AI agents in production, with another 23% planning to deploy in 2026. Gartner expects 40% of enterprise applications to be wired into task-specific agents by the end of 2026, up from under 5% in 2025. None of this is speculative anymore. The governance gap is live, and it's growing faster than the tooling meant to close it.

The deployment reality security teams are working with in 2026

Most MCP servers were never meant to be enterprise infrastructure, and it shows. Clutch Security found that 86% of MCP servers run locally on developer machines, with only 5% actually deployed in production environments. That's not a rounding error; it's the entire category being built by developers who wanted something to work on their laptop by Friday, not something a security team could stand behind.

Authentication tells the same story. Real authentication remains the exception rather than the baseline, with OAuth adoption among MCP servers staying strikingly low across the ecosystem. Researchers have found MCP servers sitting exposed on the open internet with no authentication at all, just reachable, just waiting. Formal identity strategies for AI agents remain the exception across the ecosystem, and only a fraction of agents make it to production with full security sign-off. The rest ship anyway.

The vulnerability data is worse than the hygiene data. Enkrypt-style scanning research cited in trade coverage found critical vulnerabilities in roughly a third of the servers examined: a developer grabbing a random MCP server off the shelf has close to a one-in-three chance of installing something with a critical flaw baked in before writing a line of integration code. A 2026 disclosure surfaced up to 200,000 vulnerable MCP instances spread across IDEs, internal tooling, and cloud services. Separately, 88% of organizations in an enterprise security survey reported confirmed or suspected AI agent security incidents in the prior year. IBM's X-Force 2026 Threat Intelligence Index clocked a 44% jump in AI-accelerated attacks over the same stretch. The environment is not holding still while governance teams figure out policy.

Every vulnerability class covered below is active right now, hitting production systems that were never architected to be production systems.

Prompt injection: why input validation cannot solve an attack that targets the model's reasoning

Indirect prompt injection, sometimes called cross-domain prompt injection, is what happens when malicious instructions get buried in a document, a webpage, an email, or a tool response, and the model reads that content and treats it as an instruction from the actual user. It's the digital equivalent of someone slipping a note into your mail that says "ignore your boss, do this instead," except the mail carrier reads the note out loud and your assistant follows it without asking who wrote it.

Input validation, the standard defense in traditional web security, doesn't touch this problem, because the exploited component isn't the application layer, it's the model's reasoning. Sanitizing what a user types does nothing when the malicious payload arrives later, through a tool response the model has already decided to trust. OWASP ranks prompt injection as LLM01, the number one risk on its LLM vulnerability list, and reports document a dramatic surge in prompt-injection bug reports across major vulnerability platforms.

The clearest demonstration came in April 2026, when researcher Aonan Guan and a team from Johns Hopkins University hijacked Claude Code, Gemini CLI, and GitHub Copilot using nothing more exotic than GitHub PR titles and related repository content. The agents read pull request data as legitimate task context, followed the instructions buried inside it, and exfiltrated GitHub Actions secrets straight into PR comments, issue comments, and git commits, in plain sight, no external server required. Anthropic, Google, and Microsoft paid modest bounties. None of them published a formal advisory or a vulnerability tracking entry. A separate 2025 case involving Supabase's Cursor agent showed the same pattern from a different angle: the agent, running with privileged service-role access, processed support tickets containing user-supplied SQL, and researchers showed it could be tricked into reading sensitive integration tokens into a support thread the original ticket submitter could see.

OWASP's Top 10 for Agentic Applications, released in December 2025 with review from NIST, Microsoft's AI Red Team, and AWS, formalized this as ASI01: Agent Goal Hijack. The fixes belong upstream of the model, not inside it. Tool responses need runtime content inspection before they ever enter the model's context, the same scrutiny currently reserved for user input. Agents that read untrusted external content should never simultaneously hold write access or credentials to sensitive systems, that pairing is how a support ticket becomes a data breach. Sensitive actions triggered by agent reasoning, file writes, outbound network calls, credential use, need a human approval gate. And every tool input and output needs to be logged, so that when something goes wrong, the injected instruction can actually be reconstructed after the fact instead of guessed at.

Tool poisoning: when the attack is in the metadata the agent trusts to make decisions

Tool poisoning is a different animal from prompt injection, even though the two get lumped together. Prompt injection exploits what the model reads. Tool poisoning exploits what the model is told a tool does, before it ever runs the tool. The server-side description of a tool's capability, the metadata an agent relies on to decide what to call, gets authored by someone the agent never actually agreed to trust. That's a supply-chain problem wearing a UX problem's clothes.

The root cause is a timing gap. Tool descriptions typically get reviewed once, at connect time. After that, tool responses flow straight into the model's context with no equivalent check. A timing gap in when tool descriptions are reviewed produces this: malicious instructions buried in that metadata are invisible to the human operator while being fully legible to the model. Research cited by deepsense.ai found academic analysis of thousands of MCP servers turned up eight distinct vulnerability types, with 5.5% showing MCP-specific tool poisoning.

The MCPTox benchmark, first published in late 2025 and updated in early 2026, tested 45 live MCP servers against 353 real tools and found attack success rates above 60% for many popular agents, peaking at 72.8%. The o1-mini model hit that 72.8% figure. Counterintuitively, more capable models sometimes performed worse, because better instruction-following made them more obedient to poisoned metadata, not less. Following instructions well is a virtue right up until the instructions are the attack. Claude-3.7-Sonnet was the standout on the defensive side, showing notably stronger resistance to poisoned tool calls than most other models tested.

Named vulnerabilities give this category teeth. CVE-2025-54136 (MCPoison) and CVE-2025-54135 (CurXecute) established the pattern by exploiting the connect-time-versus-runtime trust gap from two different angles. CVE-2025-6514, affecting mcp-remote versions 0.0.5 through 0.1.15, scored a 9.6 on CVSS for OS command injection. JFrog's Or Peles disclosed it on July 9, 2025, describing it as the first documented case of full remote code execution on a client operating system triggered by connecting to an untrusted remote MCP server. The affected package had logged more than 437,000 downloads by the time of disclosure. Figma's MCP server carried its own remote code execution flaw via command injection, tracked as CVE-2025-53967.

OWASP's beta MCP Top 10 for 2026 codifies all of this: tool poisoning is MCP03, supply chain and dependency tampering is MCP04, command injection and execution is MCP05. The countermeasures follow directly from the diagnosis. Tool descriptions should be treated as untrusted by default unless the server sits on an approved registry, as the MCP protocol's own security guidance recommends. Servers need approval by publisher, version, transport, and deployment path, and unapproved dynamic tool additions should be blocked. Packages should be pinned to specific versions and hashes or signed artifacts, and execution should happen in isolated environments with minimal filesystem and network reach. Every tool-definition change, every server upgrade, needs to trigger an alert. Treat it as a security event, not routine maintenance.

Rug pulls and supply-chain poisoning: what happens when a trusted tool becomes a weapon after approval

A rug pull is what happens after everyone's stopped watching. MCP tool registrations typically get approved once, at install, and rarely get re-verified after that. A malicious or compromised server can quietly change its own tool definitions post-approval, and most MCP clients won't re-alert when that happens, because the check that mattered already ran and passed.

There are three flavors. Tool poisoning at install time means the definition was malicious from day one. A rug pull update, terminology Simon Willison popularized, means a previously safe tool gets weaponized later, after trust has already been extended. Tool name collision means a malicious server registers a name close enough to a legitimate one that the LLM picks the wrong tool, the software equivalent of a scammer opening a shop next door with a nearly identical sign.

These aren't hypotheticals: in September 2025, a malicious npm package called postmark-mcp silently BCC'd every email it processed to an attacker-controlled address before anyone noticed. In September 2025, a malicious npm package called postmark-mcp silently BCC'd every email it processed to an attacker-controlled address before anyone noticed. In February 2026, Snyk disclosed "Clinejection," where an attacker published a malicious version of the Cline CLI to npm; it stayed live for a period before discovery, and because npx doesn't cache, it fetches fresh code on every single execution, every agent that ran npx during that window pulled the poisoned version, no exceptions. In March 2026, Datadog Security Labs traced a LiteLLM compromise back to Trivy, the security scanner embedded in LiteLLM's own CI/CD pipeline, which attackers used to compromise maintainer access and push poisoned versions 1.82.7 and 1.82.8. Version 1.82.8 planted a.pth file, which executes automatically on every Python interpreter startup with no import statement required, while 1.82.7 hid its payload inside proxy_server.py, triggered on import. The scanner meant to catch the attack became the delivery mechanism for it.

Zoomed out, the ecosystem numbers get uncomfortable. Antiy CERT confirmed 1,184 malicious skills inside the OpenClaw/ClawHub agent-skill ecosystem, and Snyk's ToxicSkills audit of a large sample of skills found 13.4% carried at least one critical security issue. Then there's slopsquatting: attackers registering package names that LLMs are known to hallucinate, seeding them with malware, and waiting for an agent to confidently install something that was never real to begin with.

The fix has to assume compromise happens after approval, not just before it. Tool definitions need continuous re-verification at runtime, diffed on every connection rather than checked once at install. Package manager invocations, especially npx, need to be pinned to exact versions and hashes rather than allowed to fetch fresh from a registry inside an agent's execution path. A governed allowlist of approved servers and versions, enforced at the gateway rather than left to individual developer judgment, closes the door that discretion keeps leaving open. And there needs to be a fast kill switch, a way to revoke one server or one tool without taking down every other agent workflow that happens to share infrastructure with it.

Confused deputy and cross-server attacks: how agents become the vector between systems they should never connect

Confused deputy attacks don't require any single server to be broken. A malicious MCP server embeds instructions in its own tool metadata, but the target isn't that server, it's a second, legitimate server the same agent also happens to be connected to. The agent, acting as deputy to both, follows the injected instruction and reaches into the trusted server's access on the attacker's behalf, and neither server ever sees the lateral movement, because from each server's point of view, the agent is just doing its job.

The clearest public example is the WhatsApp MCP rug-pull demonstration from April 2025. A trivia game MCP server carried hidden instructions in its tool description, aimed not at itself but at a separate, legitimate whatsapp-mcp server wired into the same agent. The agent was instructed to pull WhatsApp message history through the trusted server and leak it disguised as ordinary outbound traffic. End-to-end encryption, the thing WhatsApp is famous for, did nothing here, because the exfiltration happened above the encryption layer entirely, riding on the agent's own legitimate access. Encryption protects the pipe. It has no opinion about who's allowed to be holding the bucket.

This category is structurally different from tool poisoning because the vulnerability doesn't live in any one server's configuration, it lives in the shared context an agent carries between servers that were each authorized independently and never expected to be weaponized against each other. Check Point Research's disclosure on Claude Code shows the same deputy pattern one layer down, inside the IDE. CVE-2025-59536, rated 8.7 on CVSS, is a configuration injection flaw allowing MCP consent bypass, where project code could execute before a developer even accepted the trust dialog. A related flaw, tracked separately as GHSA-ph6w-f82w-28w6, let a malicious Hook planted in a repository's.claude/settings.json achieve remote code execution once a developer opened the project, with hook commands running with no per-command approval after the initial trust dialog was accepted. A second issue in that same disclosure showed that two settings inside.mcp.json could override safeguards and auto-approve every MCP server on launch without asking the user anything.

Fixing this means treating every MCP server connected to an agent as if it might one day try to talk to its neighbors. Scope isolation between servers connected to the same agent should prevent one server's tool call from triggering or influencing another server's execution path. Tokens need audience validation, so each server only receives credentials scoped to itself rather than an ambient set of agent-wide permissions, a principle NIST's agent identity concept paper lays out directly. Cross-server operations, especially anywhere one server's output feeds directly into another server's input, need explicit user consent before they run. And repository-level policy enforcement has to govern which configuration files are even allowed to set MCP trust settings, because right now, a single settings file committed to a repo can quietly override an org's entire security posture.

SSRF, command injection, and path traversal: the infrastructure-layer vulnerabilities that MCP inherits and amplifies

None of this is new in the abstract. Server-side request forgery, command injection, and path traversal are decades-old vulnerability classes, the kind every application security course covers in week one. What's changed is who's driving the car. In a traditional web app, an attacker needs to find and exploit the flaw directly. In an MCP deployment, an LLM with tool access can be talked into triggering the exact same flaw on the attacker's behalf, through nothing more than a well-crafted piece of text it was told to treat as trustworthy.

An SSRF vulnerability in a traditional API sits behind a fixed set of endpoints a developer wrote and can audit. In an MCP server exposing a tool that fetches URLs or reads files, the LLM decides what URL to fetch or what path to read based on its own reasoning over untrusted content. The same class of bug is now reachable through natural language rather than through a crafted HTTP request. Command injection and path traversal follow the same logic: the vulnerability class is old, but the trigger mechanism is new, an agent's own decision-making process, one that nobody spent the last twenty years hardening against.

The mitigations here aren't exotic; they're the same infrastructure discipline that should have applied all along, just applied with the knowledge that an LLM, not a developer, is now the one calling the shots. Tool implementations need strict allowlisting of reachable hosts and file paths rather than relying on the model to reason its way into safe boundaries. Execution needs sandboxing with minimal filesystem and network privileges, so a successful injection has as little to reach as possible. And every one of the vulnerability classes covered here traces back to the same root fact: MCP moved the decision-making from application code, which a developer wrote and can review, into a model's reasoning, which reads context it can't fully verify and acts on it anyway. That's the tradeoff enterprises signed up for when they wired agents into production. The mitigations that work are the ones built into a governed layer sitting between the agent and the systems it touches.