MCP server security risks fall into six groups: supply chain attacks and impersonation, tool poisoning and prompt injection, excessive permissions and token scope, local server compromise and command execution, remote server authentication and SSRF, and shadow MCP servers that nobody has reviewed. Each group has at least one documented real case or a specific warning in the MCP specification's security best practices, and each maps to entries in the OWASP MCP Top 10. This page is the overview; the linked guides go deeper on finding servers, real attacks and the checks to run.
Why MCP servers carry their own security risks
An MCP server gives an AI agent new tools: read these files, query this database, send this message. Two things make that different from an ordinary software dependency. First, a local server runs on the developer's machine with their account permissions; the MCP documentation warns that it can perform any file operation the user can. Second, the model reads each tool's description as instructions, so text inside one server can change what the agent does with every other tool it holds.
OWASP's MCP Top 10, a 2025 list in beta as of November 2026, is the most complete public catalog of these risks. The groups below follow it, with the MCP specification as the reference for what clients and servers are expected to do.
1. Supply chain attacks and impersonation
Most local servers are installed from npm or PyPI with a single command, often without a pinned version. That makes them a package supply chain like any other, with the same attacks: lookalike names, takeovers and malicious updates. OWASP lists this as MCP04, software supply chain attacks and dependency tampering.
The documented case is postmark-mcp, a package that borrowed the Postmark brand without any connection to the company. According to The Register's reporting on Koi Security's findings, the publisher shipped 15 clean versions, then added a line in version 1.0.16 that blind-copied every outgoing email to an address they controlled. Anyone running it unpinned received the change automatically. Our write-up on every malicious MCP server reported so far covers it in detail.
2. Tool poisoning and prompt injection
Because the model trusts tool descriptions and tool output, both are paths for an attacker's instructions. Tool poisoning, OWASP MCP03, hides instructions in a tool's description. Prompt injection via contextual payloads, MCP06, hides them in data the tool returns, such as a web page, an email or an issue.
Invariant Labs showed both in 2025. In one experiment, a server displayed a harmless tool at approval, swapped in a malicious description on its second launch, and made the agent leak WhatsApp chat history through a separate, trusted WhatsApp server. In another, a crafted GitHub issue in a public repository led an agent using the official GitHub MCP server to copy private repository data into a public pull request. The researchers were clear that the second case was not a flaw in the server's code; it came from what the agent was allowed to reach.
3. Excessive permissions and token scope
A server can only leak what it can reach. Filesystem servers given the whole home folder can read SSH keys and .env files. Tokens granted every scope a service offers let a single prompt injection reach every repository, channel or database behind them. OWASP lists this as MCP02, privilege escalation via scope creep, and MCP01, token mismanagement and secret exposure, covers the related habit of writing tokens straight into config files.
The MCP specification calls the fix scope minimization: start with a small, low-risk set of scopes and ask for more only when a privileged action needs them. It also lists the common mistakes: publishing every scope, wildcard scopes, and bundling unrelated privileges up front.
4. Local server compromise and command execution
A local server is a program the client starts from a command in a config file. The MCP specification describes three ways this goes wrong: a malicious startup command embedded in a client configuration, a malicious payload inside the server itself, and an insecure local server left listening on localhost that other software can reach through DNS rebinding. Its risks include arbitrary code execution with the client's privileges and data exfiltration. OWASP lists this as MCP05, command injection and execution.
The specification's mitigations are concrete. Clients that offer one-click setup must show the exact command, untruncated, and require approval. Local servers should use the stdio transport so only the client can reach them, or require a token if they use HTTP. Project-level config files make this sharper: Claude Code, for example, asks before using servers from a repository's .mcp.json in interactive sessions, but its documentation notes that non-interactive runs load them without asking.
5. Remote server authentication and SSRF
Remote servers move the code off the developer's machine, but the client still trusts what the server sends back. During sign-in, a malicious server can supply URLs that point at internal services or cloud metadata endpoints, which the MCP specification describes as server-side request forgery. It can also supply an authorization address designed to be run by the operating system. That is what CVE-2025-6514 was: JFrog found that mcp-remote, versions 0.0.5 to 0.1.15, passed such an address to a system command, allowing a malicious server to run code on the client machine. It was rated 9.6 and fixed in 0.1.16.
The specification's requirements here include rejecting dangerous URL schemes, never opening URLs through a shell, blocking private IP ranges for sign-in URLs, never accepting tokens that were not issued for the server itself, and per-client consent on proxy servers to prevent confused deputy attacks. OWASP groups the authentication side as MCP07, insufficient authentication and authorization.
6. Shadow MCP servers
The last group is the one that hides the others: servers running inside an organization that security does not know about. OWASP lists these as MCP09, shadow MCP servers. Developers add servers to coding agents in minutes, through user-level files on their laptops and project-level files in shared repositories, and none of it passes through procurement or a security review. A risk you cannot see cannot be checked against any of the five groups above. Our guide explains how to find MCP servers on developer machines for every major coding agent.
The six groups also stack. A shadow server is never reviewed, so nobody notices it is unpinned; an unpinned server receives a malicious update; the update poisons a tool description; and the poisoned agent uses an over-scoped token to reach data the task never needed. Breaking any link in that chain limits the damage, which is why the fixes are worth doing together rather than picking one. In practice, the cheapest links to break are the inventory and the pinned version, and the most valuable is the token scope, because it caps what any of the other failures can reach.
Two smaller OWASP entries round out the list. MCP08, lack of audit and telemetry, means there is no record of which tools an agent called. MCP10, context injection and over-sharing, covers servers that pass more data to the model than the task needs.
For risks that go beyond MCP to the agent itself, such as goal hijacking and rogue agents, see the OWASP agentic AI top 10.
Next step: check your own MCP server security risks
The way to act on MCP server security risks is to list every server you have, then review each one. Our MCP security checklist turns the six groups above into 12 checks. To see the whole picture at once, run a Discovery Scan, which inventories every agent and MCP server across your machines and repositories and scores each server it finds.