Common MCP Server Security Threats

OWASP ranks prompt injection first on its Top 10 for LLM Applications, and that ranking was established before MCP meaningfully changed what a successful injection can actually accomplish. In a text-only system, a successful injection produces malicious output. In an agentic system connected through MCP, it triggers automated actions through live tools, and the difference between those two outcomes is not marginal. One gives you a bad sentence. The other gives you a function call executed against real infrastructure.

The mechanism is indirect prompt injection. An attacker embeds instructions inside content the agent will read during normal operation: a support ticket, a document, a web page, a database record. The agent fetches that content as part of its assigned task, interprets the embedded instructions as legitimate operational directives, and executes them. Security practitioners will recognize the confused deputy problem immediately. What they have not fully reckoned with is the deployment scale. LLMs cannot distinguish between a user's instruction and an attacker's instruction embedded in retrieved content; they process anything that arrives as plausible tokens in a plausible context, and MCP hands them the means to act on it.

The Supabase incident in mid-2025 makes this concrete. An agent running inside Cursor had been granted privileged service-role access to Supabase. Attackers embedded SQL instructions inside support tickets. The agent read the tickets, executed the embedded instructions, and exfiltrated sensitive integration tokens through a public thread. No authentication boundary was crossed. The attacker simply left instructions where the agent would find them.

HackerOne logged a 540% surge in prompt injection reports. That number describes disclosure velocity, the rate at which the security community is encountering this class of attack in real systems, not how frequently the attacks themselves occur in the wild. Input sanitization helps at the margins, but the actual fix requires architectural decisions about trust: which content sources the agent treats as data versus instruction, and which tool calls require human confirmation regardless of what the agent is told. In an agentic context, prompt injection is a code execution primitive wrapped in natural language. Treating it as anything less is a category error.

Tool Poisoning, Rug-Pull Attacks, and Tool Shadowing as Supply Chain Threats Against Agent Capability

These three attack patterns share a root cause. MCP clients inherit trust from servers at install time and, absent additional controls, maintain that trust indefinitely without re-verification. The agent keeps calling what it believes is a sanctioned tool, and there is frequently no mechanism in place to tell it otherwise.

Tool descriptions, parameter schemas, and response content are treated by the agent as operational context, not as user input subject to scrutiny. They function more like configuration. Adversarial instructions embedded at this layer bypass whatever attention an operator applies to user-facing inputs, because most operators are not auditing schema definitions for injected directives. The Cloud Security Alliance has confirmed there is no native MCP mechanism to detect or prevent these injections.

Invariant Labs demonstrated the practical consequence in April 2025: a single poisoned tool description exfiltrated private repository contents and message histories without any user interaction. Benchmarking across more than 45 real-world MCP servers found attack success rates exceeding 60%. When five MCP servers were connected to a single agent, Palo Alto Networks Unit 42 measured a 78.3% attack success rate. More servers, more exposure, and not in a linear way.

Rug-pull attacks exploit a specific gap in MCP's trust model: most clients verify tool definitions at install time only. There is no re-alert when definitions change after approval. A malicious or compromised server can silently alter a tool's behavior post-deployment, and the agent will continue treating it as trusted because, technically, it was approved. In September 2025, an unofficial Postmark MCP server with roughly 1,500 weekly downloads was modified to add a BCC field to its send_email tool. Every outgoing email was silently copied to an attacker-controlled address. Users with auto-updates enabled leaked content with no awareness the tool had changed beneath them. The vector was the update mechanism itself, not an intrusion into the client environment. An approval granted once became permanent without anyone deciding it should be.

Tool shadowing extends the problem across trust boundaries. When multiple servers share an agent context, a malicious server's tool description can manipulate how the agent behaves with tools from other servers it has independently approved. You can vet each server individually and still be exposed, because the agent's trust model is flat across its entire connected context. One compromised server in the mix can redirect what every other server in that context does.

OWASP codified all three as MCP03:2025 in its MCP Top 10. The implication is that the threat model has to cover every server update cycle, not just the initial deployment decision.

Remote Code Execution Through MCP: How Injection Vulnerabilities Reach the Host OS

Remote code execution through MCP is not a novel attack class. Command injection, deserialization of malicious payloads, abuse of eval-like functions: these are known vectors with known histories. What MCP has done is re-introduced them at scale inside a new integration layer that developers are treating as plumbing rather than as an attack surface. That framing is the vulnerability.

CVE-2025-6514, discovered in the mcp-remote package, carried a CVSS score of 9.6 and affected versions with over 437,000 downloads at the time of disclosure. The mcp-remote proxy blindly trusted server-provided OAuth endpoints. A malicious server returned an authorization_endpoint containing shell commands. The proxy passed that value directly to the system shell. JFrog described this as the first confirmed full RCE on a client OS when connecting to an untrusted remote MCP server. The mechanism was not sophisticated; it was simply an absence of validation.

CVE-2025-49596 in MCP Inspector scored 9.4. Authentication between the Inspector client and its proxy was entirely absent, meaning unauthenticated requests launched MCP commands over stdio. Two high-severity CVEs, both reducible to the same oversight: someone forgot to verify who was asking.

OX Security's disclosure in April 2026 exposed something more structurally significant. The STDIO transport in Anthropic's core MCP SDK allows direct configuration-to-command execution without sufficient input sanitization. Cursor, VS Code, Windsurf, Claude Code, and Gemini-CLI were all affected. The aggregate download exposure from a single root-cause design decision ran into nine figures. Anthropic confirmed the behavior is intentional, with sanitization designated as the developer's responsibility. That framing is honest. It also means no patch is coming, because the vulnerability is structural.

Three additional CVEs against Anthropic's Git MCP server, assigned as CVE-2025-68143, 68144, and 68145, are chainable into RCE via prompt injection and allow access to git repositories and directory creation beyond the initially configured scope.

An analysis of 2,614 MCP implementations found that 82% use file system operations prone to path traversal, 67% use APIs related to code injection, and 34% are susceptible to command injection. This is not primarily a CVE story. It is a code quality story. The attack surface was created at deployment and existed before any specific attacker arrived.

Authentication Gaps and Exposed Servers as Entry Points Into Internal Systems

A recent audit of 518 production MCP servers found that 41% have no authentication at all. Not misconfigured. Absent. Among servers that do require credentials, an Astrix audit of more than 5,200 servers found that 53% rely on static API keys or personal access tokens, only 8.5% use OAuth, and 79% pass keys via environment variables: long-lived, hard to rotate, and easily leaked.

Trend Micro identified 492 confirmed production instances in July 2025 running with no client authentication or traffic encryption, describing them as open gateways to sensitive corporate data. A follow-up scan found that number had nearly tripled to 1,467, with attacker capability having expanded from data access to compromising the cloud infrastructure hosting the servers. A Censys scan of the public internet found roughly 12,520 publicly exposed MCP services, with approximately 40% unauthenticated.

The NeighborJack vulnerability, documented by Backslash in June 2025, identified hundreds of MCP servers configured by default to bind to 0.0.0.0, exposing them to the internet whenever no additional firewall was in place. This was not an attacker modification. It shipped that way.

The compounding problem is inventory. Organizations that have yet to catalogue their deployments do not know which of those 12,520 publicly exposed services are theirs. RBAC and authentication for AI agents are not restrictions on capability; they are the mechanism by which what AI can access becomes an intentional decision rather than an accident of deployment.

DNS Rebinding Attacks Against Locally Running MCP Servers

The implicit assumption about locally running MCP servers is that local means private. That assumption does not hold.

Under DNS rebinding, an attacker manipulates DNS resolution to make the victim's browser treat an attacker-controlled domain as localhost, bypassing the browser's same-origin policy. From that position, the attacker's site can directly invoke MCP tools on the local server, without triggering a browser warning, without generating a CORS error, and without the developer seeing anything unusual in their environment.

Early 2025 research found that MCP's official SDKs across TypeScript, Python, Rust, and Go had disabled DNS rebinding protection by default on localhost deployments, or removed it entirely. A malicious website can reach a local MCP server, call its tools, and exfiltrate data with no visible indication to the developer.

The practical exposure in enterprise environments is significant precisely because IDE-integrated MCP servers running inside Cursor or VS Code operate locally. A developer visiting a compromised site during a working session exposes every tool and data source their agent has access to. The server never appears in a network scan. It does not show up in any internet-wide exposure audit. It is still an attack surface, and the inventory problem extends to developer workstations, which is exactly where most organizations stop looking.

Over-Permissioned Access and the Blast Radius Problem in Agentic Systems

Over-permissioning is distinct from authentication failure, and the distinction matters more than most deployment checklists reflect. A server can require valid credentials and still grant far more access than any specific task requires. Authentication answers who is asking. Scoping answers what they should be allowed to do. Most MCP deployments address the first question and leave the second unasked.

AI agents often operate with broad, persistent access to multiple systems simultaneously, and that breadth is precisely what makes them useful. It is also what makes a single compromised or manipulated agent consequential across an entire environment. Prompt injection and tool poisoning are dangerous in isolation; they become a categorically different problem when the agent they target has write access to production databases, can send email on behalf of users, and can modify code in active repositories. The blast radius is not a function of the attack. It is a function of what was already configured before the attacker arrived.

MCP has no native mechanism for least-privilege enforcement. Permissions reflect what the developer configured at the time, not what the specific task actually requires. The Supabase incident illustrates this precisely: the injection succeeded in part because the agent held privileged service-role access far broader than its operational scope demanded. The attacker did not need to escalate privileges; that work had already been done for them during setup.

Gartner forecasts that 25% of enterprise GenAI applications will experience five or more minor security incidents per year by 2028, up from 9% in 2025. The trajectory is driven partly by agentic deployments where access is wide and monitoring is thin. Over-permissioning is rarely negligence in the conventional sense; it is more often the consequence of a governance layer that simply does not exist yet, one that would make access scoping a standard deployment step rather than something someone gets to eventually.

Real-time observability changes the calculus in a specific way worth naming. Knowing what an agent accessed after an incident is a postmortem capability. Catching it during execution requires active monitoring of tool calls as they happen. Audit logs reviewed after the fact are a fundamentally different capability.

What Ungoverned MCP Deployment Has in Common Across All These Threat Categories

Every threat described here shares a structural precondition: the server was deployed without a registry entry, without enforced authentication, without access scoping, and without real-time observability. The vulnerability did not appear when an attacker found it. It was created at the moment of deployment.

Prompt injection lands because agents read untrusted content with trusted-tool access and no one is watching the calls. Tool poisoning and rug pulls persist because there is no continuous verification of tool definitions after initial approval. RCE exploits succeed because server configurations are never audited for input sanitization before going live. Authentication gaps exist because no registry entry forces the question of how a server authenticates before it is deployed. DNS rebinding and over-permissioning each remove a layer of containment that otherwise limits the damage from every other threat on this list.

Between January and February 2026 alone, researchers filed more than 30 CVEs against MCP servers, clients, and infrastructure. Reactive patching is not a viable posture at that rate. The surface is expanding faster than individual vulnerabilities can be addressed one at a time, and anyone planning a security strategy around patch cadence is already behind.

A central registry, enforced access policies, and real-time observability of tool calls are not overhead imposed on agentic AI. They are the preconditions for production deployment that can withstand scrutiny. The threats are concrete, the precondition is consistent, and the response is not a patch.