The MCP Security Crisis: What We Found Hunting Vulnerabilities Across the Ecosystem
By Akav Labs | AgentSentry Research
The Model Context Protocol is quietly becoming the nervous system of enterprise AI. In the span of a few months, every major infrastructure company shipped an MCP server — Microsoft, MongoDB, Auth0, Cloudflare, ClickHouse, Upstash. Enterprises are connecting these servers to their LLM agents and pointing them at production databases, CI/CD pipelines, and authentication systems.
Nobody audited them first.
We spent several days doing systematic security research across the MCP ecosystem. What we found was not a collection of isolated bugs. It was the same classes of vulnerability, reproduced across vendor after vendor, suggesting that the ecosystem shipped fast and security thinking came later. This post documents the attack patterns we identified, the methodology we used, and what we believe needs to change.
We are not naming specific vendors or CVE numbers in this post. Coordinated disclosure windows are active. When those windows close, the full technical advisories will be published. What we can share now is the methodology and the vulnerability classes — which we believe are present across far more MCP servers than the ones we examined.
Background: What MCP Actually Is
For readers who haven't worked with it directly: the Model Context Protocol is a specification from Anthropic that standardizes how LLM agents communicate with external tools and data sources. An MCP server exposes a set of "tools" — functions the agent can call to read data, write data, or trigger actions. The agent decides which tools to call based on what it's trying to accomplish.
The security model is implicit. The agent trusts the tools. The tools trust the agent. The data those tools return flows directly into the agent's context window, where it influences future decisions. There is no sandbox. There is no mandatory validation layer. There is a thin set of protocol-level hints — like destructiveHint, which signals whether a tool should trigger a user confirmation — but these are advisory, not enforced.
This architecture has a fundamental property that security engineers need to internalize: the attack surface is not just the tools themselves, it is everything those tools can read. If a tool fetches a web page, a database record, a pull request description, or a log file, that content enters the agent's context. If an attacker controls that content, they can influence the agent's behavior. This is prompt injection, and it is the master key that makes every other MCP vulnerability exploitable.
The Methodology
We approached this the same way a red team approaches an unfamiliar codebase: systematically, starting broad and narrowing to confirmed exploitability.
Phase 1 — Discovery and triage. We identified official MCP servers from high-value vendors: companies with enterprise customer bases, active bug bounty programs, and MCP implementations that touched sensitive operations. Database servers, CI/CD integrations, identity providers, infrastructure management tools. We cloned each repo and ran automated static analysis — semgrep with custom rules targeting MCP-specific patterns, bandit for Python targets, manual grep for credential handling, URL construction, and query parameterization.
Phase 2 — Pattern identification. Static analysis produces signal, not findings. We reviewed every flag manually, looking for patterns that would be exploitable in a realistic agent deployment. We specifically looked for: unsanitized parameters being interpolated into queries or commands, credential material being returned in tool responses, read-only flags that didn't actually restrict dangerous operations, and missing or incorrect destructiveHint annotations.
Phase 3 — Live verification. This is where many security research workflows stop short, and where we made a deliberate rule for ourselves: no advisory without a confirmed live PoC. We spun up local instances of every target — Docker containers for database servers, real accounts for cloud services, local npm installs for MCP framework libraries. Every finding was tested against a running instance before any disclosure was filed. One finding that looked strong on static analysis failed to reproduce on the current default configuration. We closed it rather than file a finding we couldn't prove.
Phase 4 — Disclosure. GHSA private reporting where available, MSRC portal for Microsoft targets, direct email for vendors without a formal channel. Every disclosure included the vulnerable code location, a reproduction script, and expected output.
The Vulnerability Classes
Across the servers we examined, the same classes of vulnerability appeared repeatedly. We describe them here as patterns, not as vendor-specific findings.
Pattern 1: The destructiveHint Mislabel
The MCP specification includes a destructiveHint field in tool definitions. When set to true, compliant MCP clients — Claude Desktop, Cursor, VS Code Copilot — are supposed to prompt the user before executing the tool. When set to false, the tool executes silently.
We found multiple instances where a tool that performs a genuinely destructive or sensitive operation was annotated with destructiveHint: false. In one case, the mislabeled tool was the only write operation in an entire codebase that creates executable code — every other write operation was correctly annotated. The inconsistency was not random noise. It was a specific tool, doing a specific sensitive thing, with the wrong annotation.
The exploitability of this pattern depends on prompt injection as a prerequisite. If an attacker can influence what content an LLM agent reads — through a malicious web page, a poisoned database record, a crafted pull request description — they can instruct the agent to call the mislabeled tool. Because destructiveHint: false, the MCP client never warns the user. The operation executes silently.
The fix is straightforward: audit every tool's destructiveHint annotation against what the tool actually does. Any tool that creates, modifies, or deletes data — or that triggers an action with real-world consequences — should be annotated true.
Pattern 2: The Read-Only Bypass
Several MCP servers expose a "read-only mode" — a configuration flag or runtime setting that is supposed to restrict the agent to non-destructive operations. The security model relies on this flag to make the server safe for deployment in contexts where the agent shouldn't be able to modify data.
We found multiple cases where the read-only flag did not restrict all dangerous operations. The common failure mode: the flag was implemented by blocking a specific list of write operations, rather than by allowing only a specific list of read operations. The difference matters enormously. A blocklist approach fails when there are operations that aren't writes in the traditional sense but still have dangerous effects — functions that execute arbitrary code, commands that flush entire databases, queries that exfiltrate sensitive data by design.
One particularly clean example: a Redis MCP server marked a command execution tool as readonly: true in its metadata. The tool accepted and executed EVAL (arbitrary Lua code execution) and FLUSHALL (destroys the entire database). Neither is a "write" in the key-value sense, but both are obviously destructive. The read-only flag provided false assurance to anyone who trusted it.
The correct implementation of read-only mode is an allowlist, not a blocklist. Define exactly which operations are permitted in read-only mode. Reject everything else.
Pattern 3: The Elicitation Bypass
The MCP protocol includes an elicitation mechanism — a way for the server to pause tool execution and ask the user a confirmation question. This is a more flexible version of destructiveHint: instead of just flagging a tool as destructive, the server can ask a specific question before proceeding.
We found an implementation where the elicitation function included a fallback: if the MCP client didn't support elicitation (which most clients don't, including Cursor and VS Code), the function returned true and proceeded anyway. The safety mechanism failed open silently. On the majority of MCP clients in production use, the confirmation never happened.
This is a subtle but important failure mode. The code appears to implement a safety check. It does implement a safety check — but only for clients that support the feature. For everyone else, it's a no-op that returns the permissive answer. A developer reading the code would see the elicitation call and reasonably conclude that dangerous operations are gated behind user confirmation. They would be wrong.
Pattern 4: Operator and Query Injection
Multiple database MCP servers accepted raw query parameters that were passed through to the underlying database engine with insufficient validation. The specific mechanisms varied by database: SQL injection via unparameterized query strings, NoSQL operator injection via unsanitized aggregation pipelines, GraphQL injection via string interpolation in query construction.
The NoSQL operator injection case was particularly interesting because it involved operators that execute server-side JavaScript — $where, $function, and $accumulator in MongoDB's aggregation framework. These operators don't just retrieve data; they execute arbitrary JavaScript in the database engine's context. A filter meant to block dangerous aggregation stages checked for $out and $merge (the write operators) but not for the JavaScript execution operators. The check demonstrated awareness that stage filtering was necessary — the wrong stages were filtered.
The GraphQL injection case involved a helper function that was used in some query paths but not others. One function supported parameterized variables; another didn't. A specific tool used the non-parameterized version, interpolating user input directly into the query string. The other tool using the parameterized version worked correctly. The inconsistency was invisible without reading both functions and tracing which one each tool called.
Pattern 5: Credential Exposure via Tool Response
We found at least one case where an MCP tool's stated purpose was to return an API credential to the LLM context. The tool description itself noted that this credential was "not needed" by the server. The credential was returned anyway, making it available to any prompt injection payload that triggered the tool call.
This is a design-level failure rather than an implementation bug. The tool should not exist. Credentials should not flow through the LLM context under any circumstances — they should be used by the server on the client's behalf, not returned to the agent. Any architecture that puts credentials in the LLM's context window should be treated as a potential exfiltration path.
Pattern 6: Spotlighting Coverage Gaps
Microsoft's research team published a technique called "spotlighting" — wrapping tool responses in XML delimiters that clearly mark data as untrusted content, separate from instructions. The idea is to make it harder for prompt injection payloads embedded in data to influence the agent's behavior. Microsoft explicitly recommends this technique in their published guidance on LLM security.
We examined a Microsoft-maintained MCP server and found that spotlighting was implemented in 3 of 91 tools — a 3.3% coverage rate. The 97% gap included exactly the tools most likely to contain attacker-controlled content: pull request descriptions, work item fields, wiki pages, code search results, comments. The tools that were protected were lower-risk read operations. The tools that were unprotected were the ones an attacker would target.
There is a particular irony in finding a spotlighting coverage gap in a server maintained by the team that published the spotlighting technique. It suggests that even when security guidance exists and is understood by the team, the operational challenge of applying it consistently across a large tool surface is significant.
What This Means for the Ecosystem
The pattern across these findings is not that individual developers made careless mistakes. The pattern is that MCP server development is happening faster than MCP security thinking, and the protocol itself does not make secure implementation the path of least resistance.
destructiveHint is advisory. Elicitation support is optional. There is no mandatory input validation layer. There is no standardized way to mark content as untrusted before it enters the agent's context. The protocol gives developers the building blocks for a secure implementation, but it does not prevent an insecure one.
Several things need to change at the ecosystem level:
Standardized security testing for MCP servers. Before an official MCP server ships, it should go through the same kind of review that would be applied to any API handling sensitive operations. The vulnerability classes described in this post are not exotic. They are the same classes that appear in any API security audit. Standard tooling exists to find them.
Mandatory PoC verification before disclosure. This is a lesson we learned ourselves during this research. Static analysis is hypothesis generation. Live verification is confirmation. A finding that looks like a critical vulnerability in source code may not be exploitable in the default configuration. File findings you can prove, not findings you believe.
Spotlighting as a default, not an optimization. Any tool that returns user-controlled content should wrap that content in untrusted-data delimiters. This should be the default behavior in MCP server frameworks, not a technique developers have to know about and apply manually.
Read-only mode as an allowlist. Any MCP server that exposes a read-only configuration should define read-only as an explicit allowlist of permitted operations, not a blocklist of prohibited ones.
What's Next
We are continuing this research. The advisories filed during this research are under coordinated disclosure. When the disclosure windows close — beginning in July 2026 — we will publish the full technical details: vendor names, CVE numbers, PoC scripts, and fix recommendations.
In the meantime, if you are operating an MCP server in a production environment, the questions worth asking are: Do you know which of your tools have incorrect destructiveHint annotations? Does your read-only mode use an allowlist or a blocklist? Does any tool return credential material in its response? Are the tools that read user-controlled content applying any form of untrusted-data marking?
These are not hard questions to answer. They are easy to overlook when you are moving fast.
AgentSentry by Akav Labs is a transparent MCP gateway that applies enforcement policies to agent tool calls before they reach your MCP servers. If you are interested in the research or want to discuss your MCP security posture, reach out at akavlabs@pm.me.
Akav Labs is a security research organization focused on AI agent security. The AgentSentry platform provides runtime protection for MCP deployments. All vendor disclosures in this research were handled under coordinated disclosure principles.
© 2026 Akav Labs — akav.io