How secure are MCP servers? Risks and countermeasures

The honest answer up front: MCP is not an insecure protocol, but it shifts a large part of the security responsibility to you. Between April 2025 and April 2026 the ecosystem went from "theoretical concerns" to a series of documented incidents: a malicious server that stole emails, a critical RCE vulnerability with 437,000+ downloads, cross-tenant data leaks and full database exfiltration. In April 2026 the Center for Internet Security formally recognised MCP as "a new and distinct security boundary" in its MCP Companion Guide to CIS Controls v8.1. Anyone deploying MCP in a business context must therefore manage that boundary deliberately. Below you'll find the key attack patterns with real examples, followed by the measures that demonstrably work. New to MCP? First read what MCP is and how it works technically.

Why is MCP a different kind of risk than an ordinary API?

With a classic API integration, code executes what a developer has programmed. With MCP, the AI model itself reads the tool descriptions and tool results — and treats that text as instructions. Anything that flows through an MCP connection can therefore influence the agent's behaviour: an email, a support ticket, a database row or the description of a tool. A model cannot reliably distinguish "data" from "instructions"; at the model level there is no 100% fix for this problem. Mitigation is therefore architectural: you limit what a manipulated agent can do in the first place. Whoever understands this principle — the model follows text, regardless of where it comes from — understands ninety percent of MCP security.

What is prompt injection via tool results?

With indirect prompt injection, an attacker hides instructions in content the agent pulls in through a tool. The user asks something innocent; along the way the agent reads the malicious text and executes it. Prompt injection sits at number 1 in the OWASP Top 10 for LLM applications, and MCP drastically increases the number of supply channels.

The best-known example is the "Toxic Agent Flow" in the GitHub MCP server, demonstrated by Invariant Labs in May 2025. A developer asks their agent to "check the open issues". One public issue contains a hidden injection. The agent obeys, uses the same GitHub token to jump to the user's private repositories and leaks their contents — in the demo including salary data — via a public pull request. Crucially: this was not a bug in the server code — the tools weren't poisoned, the data was.

What are tool poisoning and rug-pull attacks?

With tool poisoning, the malicious instructions are not in the data but in the tool description itself — text the model reads but the human almost never sees. Invariant Labs demonstrated a simple "add two numbers" tool whose description secretly instructed the model to read ~/.cursor/mcp.json (containing API keys) and send it along as a parameter. To the user, a calculator; to the model, an exfiltration command. The core lesson: the human approves what they see, the model acts on what it reads. That gap is the entire attack class.

A rug pull goes one step further: the server behaves well at installation, gets approved, and then silently changes its tool definitions. MCP allows servers to update their tools without renewed consent, and most clients do not detect that change. In Invariant Labs' WhatsApp demo, a server posed as a "random fact of the day" tool and, on its second start, mutated into a tool that used the co-installed whatsapp-mcp to send the full message history to the attacker's number. Related to this is tool shadowing: a malicious server describes its tools in a way that intercepts the behaviour of a different, trusted server in the same agent.

What is the "lethal trifecta"?

The most useful mental model for decision-makers comes from researcher Simon Willison (June 2025). An agent becomes dangerous as soon as it has all three of these properties in one session: (1) access to private data — your mail, repositories, database; (2) exposure to untrusted content — web pages, tickets, emails an attacker can influence; (3) an exfiltration channel — sending mail, opening a PR, making an HTTP request. Two out of three is survivable; all three at once means whoever controls the untrusted content can read your private data and send it out. MCP makes it particularly easy to accidentally combine all three, because you freely mix tools from different vendors. Meta phrased the same idea as the "Agents Rule of Two": give a session at most two of the three properties.

The textbook case is the Supabase incident (July 2025). An agent was connected with the service_role key, which by design bypasses all Row-Level Security. An attacker hid instructions in a support ticket. The agent read the ticket (untrusted content), selected rows from a private table containing integration tokens (private data) and wrote them back into the support thread (exfiltration channel), where the attacker could read them in plain text. Cause: overly broad credentials plus prompt injection. Fix: read-only mode and scoped keys — in other words, breaking the trifecta.

Confused deputy and token theft

The confused deputy problem mainly affects MCP servers that act as a proxy for an external API. Such a proxy holds authority (a static OAuth client ID); an attacker tricks it into wielding that authority for the wrong party. The canonical scenario from the official MCP specification: the attacker registers a malicious client with their own redirect URL, sends the victim a link, and because the victim's browser still holds a consent cookie, the external auth server skips the consent screen — the authorisation code ends up with the attacker. The spec therefore explicitly forbids token passthrough: an MCP server must never accept tokens that were not issued to itself, and must validate the audience claim (aud) of every token.

Token theft is the second major credential threat. MCP servers often store long-lived, broadly scoped secrets — API keys, OAuth tokens, database keys, SSH keys — and those leak along multiple routes. CVE-2025-6514 in mcp-remote (CVSS 9.6, according to JFrog affecting 437,000+ downloads) let a malicious server steal API keys, cloud credentials and SSH keys via remote code execution. The MCP Inspector RCE (CVE-2025-49596) exposed developers' entire file systems. And via SSRF, a malicious server can point OAuth discovery URLs at the cloud metadata address 169.254.169.254 to harvest IAM credentials. The broader a token's scope, the greater the damage when it leaks.

Supply-chain risk and typosquatting

Most MCP servers are community projects you install with a single npx or pip line and that run with your full user permissions. That is classic npm/PyPI supply-chain risk, but with your AI agent's credentials attached. The flagship incident is postmark-mcp (September 2025), according to Snyk the first malicious MCP server caught in the wild. The attacker built trust with fifteen clean versions; version 1.0.16 added a single line of code that BCC'd every outgoing email — password resets, invoices, internal memos — to the attacker. Around 1,600 downloads before removal. The lesson: a trusted package can turn malicious in a single point release.

Typosquatting amplifies this risk. According to the 2026 UpGuard study (18,000 Claude Code configurations, four registries), 10–16% of all MCP servers in the registries examined are typosquats or lookalikes, and for every official brand server there are 3 to 15 unverified imitations — for example, nine different "HubSpot" servers were in circulation, only one of them genuine. Registry hygiene varies enormously: from 57 heavily moderated servers in the GitHub MCP Registry to 17,000+ largely unmoderated servers on MCP.so. Hosting platforms themselves are targets too: in the Smithery breach (October 2025), a path traversal leaked a token that controlled 3,000+ hosted servers. Which sources you can trust is covered in trusted sources.

Which measures actually work?

No single measure is sufficient on its own; the working pattern in 2026 is layered defence — scanner plus gateway plus credential management plus human oversight. The checklist:

1. Allowlists via an MCP gateway. Maintain a private registry of approved servers and have a gateway enforce it: if a server is not on the list, the connection is never established. On managed devices, your MDM pushes a non-overridable allowlist.
2. Read-only and minimal scopes. Choose read-only modes where available and use scoped keys instead of admin or service_role keys. Start with a minimal scope and only escalate when a privileged action genuinely requires it.
3. Human-in-the-loop. The MCP specification states that a human must always be able to intervene in tool calls. Require approval for consequential actions — paying, emailing, deleting, publishing — but not for every read, or approval fatigue sets in.
4. OAuth hygiene. Audience-bound tokens, no token passthrough, per-client consent and separate upstream tokens, in line with the official spec.
5. Sandboxing. Run servers in containers with a read-only root filesystem and only targeted mounts to the directories they genuinely need; strip dangerous syscalls with seccomp/AppArmor.
6. Egress control. Put untrusted servers on an isolated network without outbound routes, or behind an egress proxy that blocks internal and metadata destinations. This neutralises both SSRF and the trifecta's exfiltration channel.
7. Logging and tool pinning. Centralise audit logs in the gateway and hash the installed tool definitions (for example with mcp-scan): any change raises an alarm — the direct defence against rug pulls.

Scanners such as mcp-scan (Invariant Labs/Snyk) and Cisco's mcp-scanner detect poisoning and injection patterns before deployment, but are no guarantee: an April 2026 AppSecSanta audit across 33 servers and 433 tools produced useful but noisy results. So always combine pre-deploy scanning with runtime enforcement. More practical configuration advice is on tips & tricks.

How do you vet an MCP server before allowing it?

For businesses, the approval process matters more than any individual tool. Work with tiered approval: admit fully vetted servers directly, run borderline cases only in a sandbox, and require an explicit sign-off before adding anything to the allowlist. Screen tool descriptions for poisoning before a server reaches development environments, pin versions and monitor for changes after installation — the postmark lesson. The official MCP registry supports namespace verification, where publishers prove ownership via GitHub, DNS or HTTP; always give verified namespaces priority.

Finally: security and compliance are two sides of the same coin. Anyone giving MCP servers access to personal data or financial systems will also face the GDPR, NIS2 and the AI Act. How those obligations relate to MCP is covered in MCP and EU regulation. Sectors such as banking & fintech and legal & compliance are also subject to stricter requirements than average.

Frequently asked questions

Are MCP servers safe to use?

MCP itself is a neutral protocol; its security depends on which servers you allow and what permissions you grant them. Treat every third-party MCP server as untrusted code with your credentials attached, and use allowlists, least privilege and human approval for sensitive actions.

What is prompt injection in MCP?

Prompt injection means an attacker hides instructions in content the AI model reads through a tool — for example a GitHub issue or support ticket. The model follows those instructions as if they came from the user. According to OWASP, prompt injection is the number 1 risk for LLM applications.

What is the lethal trifecta?

The lethal trifecta (Simon Willison, June 2025) is the combination of three properties in a single agent session: access to private data, exposure to untrusted content, and a channel to send data out. All three at once makes an agent exploitable; remove at least one of the three.

What is a rug-pull attack on MCP servers?

A rug pull is an MCP server that behaves well at installation and later silently changes its tool definitions into malicious instructions. Most clients do not detect that change. Tool pinning (hashing tool definitions, for example with mcp-scan) catches this.

Have there been real MCP security incidents yet?

Yes. Among others the postmark-mcp backdoor (September 2025, the first malicious MCP server in the wild), CVE-2025-6514 in mcp-remote (437,000+ downloads, CVSS 9.6), the Supabase database leak and the Asana cross-tenant leak that affected around 1,000 customers.

How do I check whether an MCP server is trustworthy before allowing it?

Assess four dimensions: authentication method (OAuth over static API keys), the publisher's reputation (official vs. personal account), compliance documentation (a genuine SOC 2 audit) and the blast radius if it is compromised. Also scan the tool descriptions for poisoning and pin the version.

Which measures protect against unsafe MCP servers?

Layered defence: an allowlist of approved servers, read-only modes and minimal OAuth scopes, human-in-the-loop for consequential actions, sandboxing in containers, egress control on outbound traffic and central logging through an MCP gateway. No single measure is sufficient on its own.

Last updated: 2026-07-06