MCP Has 97 Million Downloads. It Also Has a Security Problem Nobody Anticipated.
Thirty-plus vulnerabilities. Over three thousand exposed applications. Ninety-seven million downloads.
That's not a success story with a footnote. That's a threat surface growing faster than anyone's reviewing it.
The Model Context Protocol — Anthropic's open framework for connecting AI agents to tools, databases, and external services — grew by roughly 970x in SDK downloads during its first year of public availability. That number gets cited as proof of momentum. It is. But protocol adoption at that speed, in a design space that was built around one use case and is being deployed at scale in another, is exactly where the dangerous gaps open up.
What MCP Was Actually Designed For
Read the original MCP specification and you'll notice the recurring assumption: a single user, a local environment, a contained scope. The reference examples are things like Claude Desktop reading your local filesystem, querying your Obsidian vault, or browsing your browser history. The threat model is correspondingly lightweight — you're essentially the only actor, so the security surface is narrow.
That model made sense in November 2024 when Anthropic released the spec. Most early MCP users were developers experimenting in their own environments. The attack surface was: you, your tools, your machine.
The stateless design follows from this. Each request from an AI agent to an MCP server arrives with its own context. The server responds. The connection closes. No session state, no persistent authentication context, no cross-request tracking. This is clean architecture for a single-user productivity tool. It's a structural liability when the same protocol is being deployed as the middleware layer for production enterprise AI.
What the Security Analysis Found
StackLok — the firm behind the Sigstore supply chain security project — published a vulnerability analysis of the MCP ecosystem in early 2026. The findings were not exotic. Path traversal vulnerabilities. Server-side request forgery. Inadequate input validation in the tool schema layer. These are the same categories that appear in every ecosystem's security postmortem when developer tooling gets promoted to production before security review catches up.
Over thirty CVEs documented across the tooling layer. More than three thousand applications with exploitable weaknesses identified.
The MCP server ecosystem is heavily community-built. Many of the servers running in production were written in a weekend to demonstrate a proof of concept and accumulated users before they accumulated security review. There's no formal verification process for publishing an MCP server. The spec provides patterns. Adoption outpaced the culture of checking whether those patterns were being followed.
The 970x growth figure is what makes the timing rough. When something grows that fast, the security infrastructure of an ecosystem cannot keep pace with usage. The typical pattern — build, secure, scale — becomes build, scale, then discover what was missing.
The Prompt Injection Problem Is Different
Infrastructure vulnerabilities in MCP servers are real and fixable. The path traversal bugs will get patched. The authentication gaps will close. What's structurally harder is the intersection of MCP with prompt injection attacks.
MCP servers expose tools. Tools have natural-language descriptions that the AI model reads to understand how to invoke them. If an attacker can influence the content that flows through those descriptions — via a document the agent is processing, a webpage it's browsing, a database entry it queried — they can potentially redirect the agent's behavior. The model reads an injected instruction and acts on it as though it were a legitimate tool directive.
This isn't theoretical. Demonstrations against deployed systems using multiple frontier models have shown the attack working in practice. The defense is structurally uncomfortable: MCP's value proposition depends on the AI being able to interpret flexible, natural-language tool descriptions. Making those descriptions more rigid reduces the attack surface but also reduces the protocol's usefulness. Leaving them open leaves a manipulation vector that no amount of patching closes.
Anthropic's spec acknowledges the trust boundary problem. The guidance is clear. Enforcement is the gap — the spec can't enforce how tool descriptions get written across ten thousand community-built servers.
The Stateful Production Gap
Here's the concrete problem. An MCP server sitting between an orchestrating agent and your company's internal APIs is not a local tool. It's middleware with access to live systems. If that server is running an older spec without transport-level authentication — which the spec only added in recent versions — credentials can leak across requests. If the server has write access to a database, and the agent processing it is also processing untrusted external content, you've built a path from untrusted input to database mutations.
This isn't a theoretical risk profile. The architecture of most production MCP deployments today — agent calling server, server calling API, no persistent audit trail, minimal authentication — is structurally similar to the early web service integrations that produced the first generation of API security incidents. We know how that played out.
The teams shipping MCP servers are primarily developer-experience and AI product teams. Security review is being backfilled into a protocol that had no time to develop a security culture before the ecosystem exploded. That's not a criticism of those teams — it's a description of what happens when the pace of adoption outstrips the pace of hardening.
If you're building on agent-based architectures, the MCP security posture is worth treating as unsettled, not assumed. And if you're running the LLM stack underneath those agents, the threat model needs to extend to every protocol layer sitting above it.
What Actually Needs to Happen
The vulnerability categories StackLok documented have fixes. Patch path traversal bugs. Implement transport-level auth. Validate tool schema inputs. These are engineering problems with engineering solutions.
The harder work is cultural. MCP needs the equivalent of what OWASP did for web application security: a clear, actionable framework that community server authors can follow without being security experts. The spec itself needs security guidance promoted from optional reading to load-bearing requirement.
Anthropic has been moving in this direction. Transport-level authentication landed in recent spec versions. Some major server implementations have started formal security review processes. The trajectory is right.
But trajectory and current state are different things. Right now, in mid-2026, the security posture of the average production MCP deployment sits somewhere between "not reviewed" and "recently patched." For the specific environments MCP was designed for — local tools, developer experiments, single-user contexts — that's probably acceptable.
For production multi-agent systems touching customer data, company credentials, and live infrastructure? The math on ninety-seven million downloads means the blast radius of an unpatched vulnerability is not contained to developers testing in their basements.
The protocol earned its adoption. The security culture needs to earn it too.
Photo by Tima Miroshnichenko via Pexels