Visibility & Shadow AI

Threat Explainer

Mcp Security Vulnerabilities

MCP Security Vulnerabilities: Complete Threat Inventory

Researchers tracking the Model Context Protocol ecosystem have cataloged over 50 known vulnerabilities, with 13 rated critical, and public repository scans have surfaced large volumes of leaked secrets inside MCP server configurations. These are not theoretical risks. They are active attack surfaces running inside enterprise AI stacks right now.

Obsidian Editorial Team

Security Research

Obsidian Security

May 15, 2026

May 19, 2026

Key Takeaways

The MCP vulnerability landscape has grown faster than any security review process can match, with critical-rated flaws spanning tool poisoning, command injection, and unauthenticated server connections.
Most MCP vulnerabilities are not exploited in isolation. Attackers chain two or three classes together to escalate from a single malicious tool description into full credential theft or data exfiltration.
Patching MCP vulnerabilities is structurally harder than patching traditional software because there is no central registry, no mandatory review process, and no clear owner when a community-maintained server introduces a flaw.
Security teams cannot defend what they cannot see. The prerequisite for any MCP security posture is a complete, classified inventory of every server your agents connect to.
Effective authority, not theoretical configuration, is the measure that matters. Knowing an MCP server exists is not the same as knowing what it can actually do inside your environment.

The MCP Vulnerability Landscape in 2026

Security teams managing AI agent deployments face a question they cannot currently answer: how many MCP servers are running in your environment right now, and how many have been reviewed for security?

The Vulnerable MCP Project, a community-driven effort to catalog known MCP security issues, has tracked over 50 discrete vulnerabilities across publicly available MCP server implementations. Thirteen of those vulnerabilities carry critical severity ratings. The project continues to grow because MCP server adoption is growing faster than any centralized security review process can match. Developers publish new servers daily. Enterprises adopt them the same week. Security teams find out months later, if at all.

The scale of secret leakage compounds the problem. Public repository scans have surfaced significant volumes of exposed credentials, API keys, and authentication tokens embedded directly in MCP server configurations committed to GitHub. These are not edge cases. They are a pattern that reflects how quickly MCP servers were built and deployed without security review as a standard step.

This is now a procurement and supply chain issue, not just a developer hygiene issue. When an enterprise deploys an AI agent that connects to a community-maintained MCP server, that server becomes part of the enterprise's effective attack surface. The 2025 Salesloft-Drift compromise demonstrated exactly this dynamic: a third-party integration carrying stolen bearer tokens affected over 700 Salesforce environments. MCP connections follow the same trust model. The agent trusts the server. The server can lie.

A new class of systemic vulnerability disclosed in 2026 made the scope clearer. Design flaws in STDIO-based MCP implementations, present in reference implementations and widely adopted tools, enabled remote command execution across the ecosystem. Multiple CVEs were filed against major AI frameworks as a result. Several scenarios required zero clicks to trigger. The blast radius of a single vulnerable MCP server, connected to agents running with broad SaaS permissions, is not a small number. CVE-2025-6514 in mcp-remote, with a CVSS score of 9.6 and over 437,000 package downloads at the time of disclosure, is one of the highest-profile examples.

The Six Core MCP Vulnerability Classes

Security teams need a working taxonomy before they can assess exposure. The six classes below represent the primary categories of MCP security vulnerabilities observed across disclosed CVEs, the Vulnerable MCP Project, and enterprise incident patterns in 2025 and 2026.

The Six Classes

1. Tool Poisoning A malicious or compromised MCP server returns tool descriptions that instruct the agent to take actions the user never intended. The agent reads the description as authoritative and executes. Because tool descriptions are processed at the model layer, the agent has no independent mechanism to verify whether the instruction is legitimate.

2. Prompt Injection via Tool Descriptions and Responses Tool descriptions and server responses are text. That text is processed by the underlying language model. An attacker who controls the server content can embed instructions inside tool metadata or response payloads, redirecting the agent's behavior mid-session. This is distinct from direct prompt injection by a user. The injection arrives from the infrastructure layer, not the human layer.

3. Command Injection MCP servers that pass agent-supplied input to shell commands or system calls without sanitization are vulnerable to classic command injection. The STDIO design flaws disclosed in 2026 fall into this class. An agent sends a request, the server passes it to an operating system call, and an attacker who controls the input can execute arbitrary commands on the server host.

4. Path Traversal File system MCP servers that allow agents to read or write files are frequently vulnerable to path traversal when input is not validated. An agent that can request ../../etc/passwd from a file server that does not enforce directory boundaries has effectively been handed read access to the host operating system.

5. Hardcoded Credentials in MCP Configurations Developers building MCP servers embed API keys, database passwords, and OAuth tokens directly in configuration files. Those files get committed to version control. The thousands of secrets found in public repositories represent this class. The credential is not stolen through an attack. It is simply read from a public source.

6. Unauthenticated Server Connections Many MCP server implementations ship with no authentication requirement on the agent-to-server connection. Any agent, or any process that can reach the server's network address, can issue tool calls and receive responses. In enterprise environments where n8n workflows or Cursor instances connect to local or remote MCP servers without auth, this creates an open channel for lateral movement.

Vulnerability Class Summary Table

Vulnerability Class	Mechanism	Real-World Prevalence	Defensive Difficulty
Tool Poisoning	Server returns malicious tool descriptions that redirect agent behavior	Moderate, growing with third-party server adoption	High: requires runtime tool call monitoring
Prompt Injection via Tool Descriptions	Injected instructions in server responses processed by the model layer	Moderate	High: model-layer processing bypasses input filters
Command Injection (STDIO)	Unsanitized input passed to shell or system calls	High: systemic flaw in reference implementations, multiple CVEs filed	Medium: patchable but requires server-side remediation
Path Traversal	Directory boundary bypass in file system servers	Moderate	Medium: input validation fix, but requires server update
Hardcoded Credentials	Secrets embedded in config files committed to version control	Very High: large volumes of exposed credentials in public repos	Low: detectable via secret scanning, but requires rotation
Unauthenticated Server Connections	No auth mechanism on agent-to-server channel	High: common in community servers and local deployments	Medium: requires auth layer implementation per server

How These Vulnerabilities Get Exploited in Practice

Knowing the individual classes matters less than understanding how they combine. Attackers do not use a single vulnerability in isolation. They chain them.

Attack Chain: From Malicious Tool Description to Credential Exfiltration

Consider a developer who adds a community-maintained MCP server to their Cursor environment to enable database queries. The server is publicly available, widely used, and has never been formally reviewed. Here is how the chain runs.

Step one: Tool poisoning. The MCP server returns a tool description that includes an embedded instruction directing the agent to also send the contents of the local .env file to an external endpoint whenever a query is executed. The developer sees a normal database query interface. The agent sees an additional instruction.

Step two: Hardcoded credentials. The .env file contains API keys for the organization's Salesforce instance and an AWS access key. These were placed there following standard developer practice. They are now exposed.

Step three: Unauthenticated server connection. Because the MCP server connection carries no authentication, the attacker who controls the server receives the credentials without triggering any authentication alert. No login event fires. No anomaly appears in the identity provider logs.

The developer ran a legitimate query. The agent executed an action chain that included three vulnerability classes. The blast radius now includes every system those credentials can reach.

This is the pattern that makes MCP security vulnerabilities different from traditional software vulnerabilities. The agent is not compromised. The agent did exactly what it was told. The problem is that the instruction came from infrastructure the organization trusted without verifying.

For security teams managing AI agent governance, this chain illustrates why theoretical configuration is insufficient. Knowing that an MCP server is connected to an agent does not tell you what that server is instructing the agent to do at runtime.

Why MCP Vulnerabilities Are Hard to Patch

Security teams accustomed to CVE-driven patch cycles will find MCP vulnerabilities structurally different. Four factors make remediation harder than it looks.

No central registry. There is no authoritative catalog of MCP servers equivalent to the National Vulnerability Database for traditional software. The Vulnerable MCP Project is community-maintained. Disclosure is voluntary. An enterprise using 40 MCP servers has no single source to query for known vulnerabilities across all of them.

Community-maintained servers with inconsistent review. The majority of MCP servers in active enterprise use were built by individual developers or small teams and published without a security review process. There is no mandatory security audit before a server appears in a marketplace or package registry. The server that looked safe last quarter may have accepted a pull request last week that introduced a command injection flaw.

Agent-side responsibility ambiguity. When a vulnerability exists in an MCP server, the question of who is responsible for remediation is genuinely unclear. The server developer may have abandoned the project. The enterprise that deployed it may not know which teams own which agent connections. The AI platform vendor who built the agent framework takes the position that server security is the customer's responsibility. This ambiguity is not a policy failure. It is a structural feature of the decentralized MCP ecosystem.

Patching requires updating every agent connection. When a vulnerable MCP server is patched, every agent that connects to it must be updated to use the patched version. In environments where MCP sprawl has agent connections growing quarter over quarter, the operational lift of coordinating that update across hundreds of agent configurations is significant. Many organizations discover they do not have a complete list of which agents connect to which servers. You cannot update connections you do not know exist.

This is where shadow AI detection becomes operationally relevant. Shadow MCP servers, servers connected to agents without IT or security awareness, cannot be patched because they are not known. The visibility gap precedes the remediation gap.

Defensive Posture Against MCP Vulnerabilities

The organizations that manage MCP security vulnerabilities most effectively share one starting point: they know what they have. Every other control depends on that foundation.

Build a Complete MCP Server Inventory

You cannot govern what you cannot see. The first defensive action is building a complete inventory of every MCP server connected to every agent in your environment. That inventory must include the server name, the agent or agents that connect to it, the authentication mechanism in use (or the absence of one), and whether the server is sanctioned by IT and security or operating as a shadow connection.

Enterprises that have gone through this exercise consistently find servers they did not know existed. Patterns observed across enterprise inventories show MCP connections multiplying rapidly inside developer tools with no centralized tracking, and agent populations significantly larger than internal estimates suggested before the inventory exercise began.

Classify Sanctioned vs. Unsanctioned Connections

Not all MCP servers carry equal risk. A sanctioned server that has been reviewed, uses authenticated connections, and is maintained by a known vendor carries different risk than a community-maintained server connected to an agent by a developer who found it on GitHub. Classifying connections by sanctioned status gives security teams a prioritized remediation queue rather than an undifferentiated list of servers to review.

Monitor Agent-to-Server Tool Calls at Runtime

Configuration review tells you what servers exist. Runtime monitoring tells you what they are actually doing. Monitoring tool calls at runtime surfaces the gap between theoretical configuration and effective authority. A server that appears benign in configuration review but is issuing unexpected tool calls at runtime is exhibiting exactly the pattern that tool poisoning and prompt injection attacks produce.

For teams evaluating AI agent security monitoring options, the key capability question is whether the tool shows you what agents are configured to do or what they actually did. Those are different answers, and only one of them catches active exploitation.

Apply Vendor Evaluation Before New MCP Server Adoption

Before connecting a new MCP server to any agent with access to sensitive data, apply a minimum evaluation checklist: Does the server require authentication? Is the source code available for review? Is the project actively maintained? Has it been reviewed against the Vulnerable MCP Project catalog? Is there a disclosed vulnerability history?

This evaluation does not need to be exhaustive for every server. It needs to be consistent. The organizations with the worst MCP security posture are not those that failed a deep review. They are those that had no review process at all.

Enforce Least Privilege on Agent Connections

An agent that connects to an MCP server should hold only the permissions required for its specific workflow. Most agents in enterprise SaaS environments are over-permissioned. When a vulnerable MCP server is exploited, the blast radius is a direct function of the permissions the agent carries. Reducing agent permissions reduces the damage ceiling before the vulnerability is discovered.

A Current Inventory Problem, Not a Future Risk

The MCP vulnerability landscape in 2026 is not a future risk. It is a current inventory problem. Security teams that know which MCP servers their agents connect to, which of those connections are authenticated, and what those servers are actually instructing agents to do at runtime are in a fundamentally different position than teams ghost chasing theoretical configuration risks.

The six vulnerability classes described here, tool poisoning, prompt injection, command injection, path traversal, hardcoded credentials, and unauthenticated connections, do not require novel attack techniques to exploit. They require only that an attacker find a community-maintained server with no security review and wait for an enterprise agent to connect to it.

The defensive path is sequential. Build the inventory. Classify the connections. Monitor the tool calls at runtime. Enforce least privilege before the next server is added. Probabilistic agents operating across a decentralized MCP ecosystem require deterministic guardrails. Configuration review is not a substitute for runtime truth. Runtime guardrail enforcement is generally available on Microsoft Copilot today, with expanded platform coverage on the roadmap.

To see how Obsidian maps MCP server connections, classifies sanctioned versus unsanctioned servers, and surfaces agent-to-server tool call activity across your environment, explore the AI agent security platform.

Frequently Asked Questions

What is the most common MCP security vulnerability in enterprise deployments?

Hardcoded credentials in MCP server configurations are the most prevalent class by volume. Large volumes of exposed secrets have been found in public MCP server repositories. Unauthenticated server connections are a close second in terms of enterprise prevalence, particularly in n8n workflows and developer tool environments like Cursor.

How does tool poisoning differ from prompt injection in MCP servers?

Tool poisoning occurs when a malicious or compromised server returns a tool description that redirects agent behavior. The attack arrives through the tool registration mechanism. Prompt injection via MCP occurs when an attacker embeds instructions inside server responses or tool metadata that the underlying language model processes as directives. Both exploit the agent's trust in the server, but they operate at different layers of the MCP interaction model.

Can traditional vulnerability scanners detect MCP security vulnerabilities?

Traditional scanners can detect some classes, particularly hardcoded credentials and known CVEs in server dependencies. They cannot detect tool poisoning or prompt injection because those vulnerabilities are expressed in the content of tool descriptions and server responses, not in code patterns or binary signatures. Runtime monitoring of tool calls is required to surface those classes.

Who is responsible for patching a vulnerable community-maintained MCP server?

Responsibility is genuinely ambiguous. The server developer may have abandoned the project. The enterprise that deployed it owns the risk but may not have the ability to patch the server directly. The AI platform vendor takes the position that server security is outside their scope. In practice, the enterprise security team is responsible for identifying vulnerable servers, removing or replacing them, and ensuring agent connections are updated. This is why inventory and classification are prerequisites, not optional steps.

What should security teams do before deploying MCP at scale?

Build the inventory first. Before expanding MCP usage across business units or agent platforms, establish a sanctioned server list, define an evaluation checklist for new server adoption, confirm that all connections require authentication, and implement runtime monitoring for agent-to-server tool calls. Deploying at scale without these controls in place means the blast radius of the first exploited server will be proportional to the scale of the deployment.