The MCP Security Crisis: What We Found Hunting Vulnerabilities Across the Ecosystem

try { if(localStorage) { let currentUser = localStorage.getItem('current_user'); if (currentUser) { currentUser = JSON.parse(currentUser); if (currentUser.id === 3854119) { document.getElementById('article-show-container').classList.add('current-user-is-article-author'); } } } } catch (e) { console.error(e); } AKAVLABS Posted on Apr 28 The MCP Security Crisis: What We Found Hunting Vulnerabilities Across the Ecosystem #agents #llm #mcp #security 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…

This excerpt is published under fair use for community discussion. Read the full article at DEV Community.