OWASP MCP Top 10 Security Risks

The list is a 2025 publication, currently in beta, led by Vandana Verma Sehgal and kept up on owasp.org under the MCP Top 10 project page. It's the newest member of the OWASP Top 10 family, built around one protocol surface instead of a whole class of software.

The risks run from MCP01:2025 through MCP10:2025, and that "2025" tag isn't decoration. This is a living document; expect revisions as the protocol and the attacks against it mature. Here's the full list, for orientation:

• MCP01 — Token Mismanagement & Secret Exposure
• MCP02 — Privilege Escalation via Scope Creep
• MCP03 — Tool Poisoning
• MCP04 — Supply Chain Attacks
• MCP05 — Command Injection & Execution
• MCP06 — Intent Flow Subversion
• MCP07 — Insufficient Authentication & Authorization
• MCP08 — Lack of Audit and Telemetry
• MCP09 — Shadow MCP Servers
• MCP10 — Context Injection & Over-Sharing

Read it as a map for closing gaps rather than a leaderboard for ranking them. Ranking MCP01 against MCP09 wastes time that should go toward closing both, and here's the part teams miss: these ten surfaces feed each other. A team that locks down tool poisoning (MCP03) but never counts the servers it's actually running (MCP09) still has an open door. Full stop. The urgency isn't theoretical, either: more than 30 CVEs targeting MCP servers, clients, and supporting tools got filed in January and February 2026 alone.

MCP01 — how credentials and tokens leak through the protocol layer

Nothing here is new. Hard-coded API keys, tokens that never expire, secrets sitting in model memory or protocol logs: security teams have fought this for a decade. What changed is the exit. A secret can now walk out through a context window, a debug trace, or an agent's own reply, read straight back to a user who never asked for it.

Here's the failure, and it repeats. A developer commits a key during testing. An MCP server reads that key from its config file at startup. Later, in some unrelated conversation, the assistant just says it out loud. Three things make this worse than an ordinary leak: tokens get hard-coded into client or server config instead of issued fresh each session, models recall prior conversations that happened to include credentials, and prompt logs sit around unredacted, a searchable archive of everything that's ever leaked.

The scale problem shows up in a single case. CVE-2025-6514, CVSS score 9.6, hit mcp-remote, a transport package with over 437,000 downloads. One credential flaw in one widely used library, multiplied across every project that pulled it in.

The fix gets skipped more often than it gets attempted. Issue short-lived, narrowly scoped tokens instead of long-lived ones. Scan code and logs for secrets on an ongoing basis. Put guardrails in place that catch outbound prompts before anything sensitive leaves the context window.

MCP02 — why agent permissions expand and almost never contract

Permissions granted to an MCP server move one way: out. Nothing forces a review or an expiry date, so a scope that made sense for a two-week pilot is often still live a year later, quietly attached to a production agent nobody's watching anymore.

Scope creep isn't abstract. It's what lets an agent modify a repository, reach into system controls, or pull data out, none of it signed off on, all of it technically allowed because nobody bothered to revoke the grant. The failure usually starts small: someone testing something needs write access to get it working, that access gets inherited wholesale when the project ships, and the review that should've happened never happens.

Most teams treat this as a technical problem, and that's exactly how they miss it. The deeper issue is governance: a matter of decisions and ownership more than configuration. Role-based access control for AI agents means making sure what an agent can do reflects a choice someone made on purpose, recently, not a leftover from six months back. Least-privilege scopes enforced at the gateway level, automatic expiry on anything marked temporary, periodic access reviews: that's the same hygiene that's been standard for human identities for years, finally pointed at agent identities too.

MCP03 — tool poisoning and the rug-pull problem

Tool poisoning hides adversarial instructions inside a tool's description, its parameter schema, or the content it returns. The agent treats that as trusted operational context rather than untrusted input, because that's exactly what it's built to do. MCP has no native mechanism to catch this. That's the whole problem in one sentence.

Three variants share one root cause: clients inherit trust from servers, and nothing re-checks that trust once it's granted. Tool description poisoning hides malicious instructions in the description field the agent reads at call time. Rug-pull attacks are sneakier: a tool gets approved when it's behaving well, then the server operator changes its function, its data access, or its permission needs later, and no re-consent ever fires, because MCP doesn't cryptographically pin or version tool descriptions. Tool shadowing lets a malicious server sitting in the same agent context override or impersonate a legitimate one.

Invariant Labs showed the stakes in April 2025. A single poisoned tool description exfiltrated private repository contents and message histories with zero user interaction. A companion demo put a malicious MCP server next to a legitimate WhatsApp MCP server, and the malicious one quietly read and exported a user's entire message history: no error on the user's part, no network exploit, just a poisoned tool doing exactly what it was built to do. Cloud Security Alliance research tested more than 45 real-world MCP servers in a lab setting and clocked attack success rates above 60% for tool poisoning.

Here's the gap that matters most on this whole list: users approve a tool once, at install, and almost never look at it again. Rug-pull attacks are built to exploit exactly that blind spot, which is why it's worth closing before anything else here. Pin tool versions and signed schemas at install time. Alert on any description drift after that first approval. Keep retrieved content separate from user instructions so the two never blend, and scope context windows tightly per task.

MCP04 — supply chain risk when any server can be a package

MCP servers get distributed like software packages, so the whole supply chain playbook applies: compromised packages, typosquatted server names, fake "official" connectors slipping into registries that don't vet submissions carefully.

2025 gave the ecosystem its first confirmed case: the Postmark MCP backdoor, the first malicious MCP server caught operating in the wild. That moved the risk from theoretical to documented. The mechanism is uglier than a simple malware drop, too: once a compromised server gets wired in, attacker-controlled metadata in its tool descriptions can shape how the LLM reasons, steering it toward attacker-intended operations that the host just carries out, no independent check involved.

Scale rules out manual review here. A May 2026 pull of the official MCP Registry API counted 9,652 latest server records and 28,959 total server and version records. Nobody's checking that volume by hand, not realistically. CVE-2025-6514, the same mcp-remote flaw from MCP01, belongs in this section too: an OS command injection bug that enabled remote code execution the moment a client connected to a malicious server. Call it a supply chain vector as much as a credential one.

Sign components. Track SBOM and AIBOM provenance so origin is verifiable. Run CI scanning that blocks any server from reaching an agent until it passes. Every server added without a registry entry is an identity the organization can't account for, and those are exactly the identities that get exploited first.

MCP05 — command injection at the shell, and why MCP servers make it worse

Command injection is an old bug wearing new clothes. An agent builds a shell command, a script, an API call, or a code snippet out of untrusted input, whether that's a user prompt, retrieved context, or a third-party data source, and hands it straight to a shell or an eval-style function without checking it first.

MCP just makes the blast radius bigger. Local MCP servers routinely get access to the file system, developer tools, environment variables, package managers, and cloud CLIs, so a successful injection doesn't just compromise an app; it can compromise the whole machine. The 2026 CVE data backs this up directly: 43% of the 30-plus CVEs filed in January and February 2026 were shell injection flaws, the single largest category by a wide margin, not close.

Two named cases show the range. CVE-2026-32211 in Azure MCP Server traced back to a missing authentication layer, and CVE-2025-54136, nicknamed MCPoison, hit Cursor IDE and enabled persistent code execution. Use parameterized queries instead of string-built commands. Validate input strictly before anything touches a shell. Sandbox execution for tool calls, and ban raw shell string concatenation outright, anywhere in a tool's implementation. No exceptions.

MCP06 — how hidden instructions in tool outputs hijack agent behavior

This risk sits one step downstream of tool poisoning. Instead of manipulating a tool's description before it's ever called, an attacker buries instructions inside the data the tool returns: a document, a retrieved record, a piece of content the agent reads as part of doing its job. The agent treats that content as context and ends up acting on the attacker's intent instead of the user's.

Wiz Research calls the underlying condition the "lethal trifecta": untrusted input, access to sensitive data, and the ability to take action, all present at once. MCP environments hit all three routinely, which is what makes this risk so hard to shake. The GitHub MCP vulnerability from 2025 is the clearest real-world case: crafted content sitting in a repository triggered indirect prompt injection, pulling private data out of other users' sessions.

OWASP already ranks prompt injection as the top risk for LLMs generally, and inside MCP the stakes climb higher, because injection here can trigger automated, multi-step actions that a plain text-generation model could never pull off on its own. Treat every piece of tool output as data, never as instruction. Write system prompt rules that explicitly override any command buried in returned content, and require human approval before any destructive or irreversible action fires.

MCP07 — missing or weak authentication between agents, tools, and servers

MCP merges reasoning and control flow into one shared semantic context, which means trust boundaries aren't enforced by design the way they are in more established protocols — unless someone builds them in by hand.

The practical result: multiple agents, users, and services trade data and trigger actions with weak identity checks, or none at all. CVE-2025-49596, found in MCP Inspector before version 0.14.1, needed no authentication whatsoever between components, letting a malicious actor run stdio commands directly. The Zuplo survey from late 2025 puts a number on how widely this gets felt: 50% of MCP builders name security and access control as their top challenge, and 38% say security concerns are actively holding back further adoption.

Put OAuth 2.1 or mutual TLS on every inter-agent and agent-to-tool connection, and enforce authorization checks server-side on each request. Never assume trust carries over from an earlier session just because that one happened to check out fine.

MCP08 — operating AI agents without audit trails or telemetry

A 2026 survey found more than half of all agents running in production have no security oversight or logging attached to them, none at all, and only 24% of organizations say they have full visibility into which of their AI agents are talking to which other agents. That's most of the fleet running blind. It should worry anyone signing off on agent deployments.

Without telemetry, an incident leaves no trace. There's no record of what the agent touched, which tools it called, or what data came back, so a postmortem investigation just can't happen, and whatever caused the breach is free to repeat itself the next day. A log read after something breaks explains what happened after the fact; a system that lets a team step in while it's happening stops the damage before it spreads. The gap between those two is the whole ballgame.

Palo Alto's Unit 42 found that in an environment with five connected MCP servers, a single compromised server reached a 78.3% attack success rate. Without telemetry watching that connected surface, a compromise like that spreads and nobody notices until it's everywhere. Log every tool call along with its inputs and outputs. Tune real-time alerting to catch odd access patterns, and keep audit records immutable and isolated from the agent's own write access, so a compromised agent can't go back and edit its own trail.

MCP09 — MCP servers that the organization doesn't know it's running

Shadow MCP servers show up the same way shadow IT always has. A team needs a tool, the formal approval process is slow or doesn't exist, so someone just stands up a server on their own. No registry entry gets made, no policy covers it, and there's no audit trail pointing back to it when something breaks.

Here's what most security teams get wrong: banning this outright doesn't remove the risk, it just hides it. A hard no pushes the work somewhere less visible, and the organization ends up carrying the same risk plus a loss of visibility stacked on top of it. A governed, reasonably fast path to standing up an approved server cuts down shadow MCP usage far better than a blanket ban does, because it gives people a legitimate route instead of pushing them around the rules. Docker's State of Agentic AI research lands on the same conclusion: faster governance beats stricter refusal at shrinking shadow infrastructure, every time.