If you had asked a security team in early 2024 what an MCP server was, most would have had to look it up. Eighteen months later it is core agent infrastructure for thousands of enterprise deployments, and the vulnerability disclosure pipeline has caught up with that reality. The first quarter of 2026 saw more public CVEs against MCP server implementations than all of 2025 combined. That spike is a signal, and the shape of those disclosures tells us what to expect for the rest of the year.
The Volume Story
Numbers first. In the first three months of 2026, the public CVE database accepted over a hundred MCP-related entries — roughly a third targeting the reference protocol implementations, the rest covering individual servers. That is a substantial step up from the steady but small drip we saw through 2025. Three things drove the volume change. The protocol stabilized enough that researchers stopped chasing moving targets. Bug bounty programs started covering MCP servers explicitly. And, most importantly, the deployment footprint reached the size where automated scanners and security firms found it commercially worthwhile to point research at the ecosystem.
The volume increase is not by itself bad news. It looks like the same shape we have seen with every emerging infrastructure category — Kubernetes, container runtimes, serverless platforms — where a flood of disclosures reflects research catching up rather than the technology getting worse. What matters is what kinds of bugs are being found, and whether the ecosystem is set up to fix them quickly.
The Vulnerability Classes That Dominate
A few patterns account for most of the 2026 disclosures.
Authentication and authorization gaps are the largest category. Many MCP server implementations were written quickly and treated authentication as something the user would configure. In practice, default deployments often did not require authentication at all, and even when they did, scope checks on individual tools were missing or inconsistent. The result has been a steady stream of "exposed MCP server allows unauthenticated tool invocation" reports, often with serious downstream impact — file access, code execution, credential reads.
Path traversal and unbounded input handling in tool implementations is the second category. An MCP server that exposes file operations or shell-like tools is a high-value target. Many early implementations passed user input through to the underlying system call without sanitization, on the assumption that the caller — the agent — would not be adversarial. Indirect prompt injection broke that assumption, and the resulting CVEs have been well-represented in the first quarter.
Server-side request forgery and credential leakage through tool responses is the third. Tools that fetch URLs, query databases, or call internal APIs frequently leak sensitive information through error messages or unsanitized responses. When the agent forwards a verbose error to the user, the user — or an attacker — learns about the internal network topology, the database schema, or the secrets stashed in environment variables. The fix is usually trivial; the disclosure backlog suggests it has not been universally applied.
Protocol parsing bugs are the smallest of the four common categories but the most concerning when they appear. A malformed MCP message that crashes the server or causes it to misinterpret tool calls is bad. A malformed message that causes the server to execute the wrong tool with the wrong arguments is worse, and a few of those have surfaced. These bugs are the ones most likely to be wormable across the MCP ecosystem because the same protocol implementations are used widely.
Disclosure Norms Are Settling
A year ago researchers reported MCP bugs to the implementation maintainer, the protocol authors, the agent runtime that loaded the server, or sometimes none of the above. Coordination was poor. Two years later, three norms have emerged.
First, the MCP protocol stewards now run a coordinated disclosure process for protocol-level issues, with a private security mailing list, a 90-day default disclosure window, and a published advisory format. This is what every infrastructure ecosystem eventually does, and it is in place.
Second, individual server implementations are expected to publish a security policy in their repository — usually a SECURITY.md — pointing at a contact and a triage commitment. The expectation is far from universally met. In a recent informal survey of the top fifty most-pulled MCP server packages, fewer than half had a security policy. That is the gap that will close most slowly.
Third, the bug bounty layer has filled in faster than expected. The major model providers that ship MCP servers as part of their platform have folded MCP scope into their existing programs. A few independent platforms run dedicated MCP bounties. The economic incentive for researchers to look at MCP code is now real, and the volume of disclosures reflects that.
What Enterprises Are Getting Wrong
The most common mistake we see in 2026 is treating an MCP server like a library when it is, operationally, a service. Libraries get pinned, vulnerabilities tracked, dependencies enumerated. Services get deployed, configured, monitored, and patched on a schedule. MCP servers are usually deployed as services — they listen on ports, hold credentials, mediate access to resources — but tracked as if they were libraries, with no patch process, no inventory of what is running where, and no monitoring of the protocol traffic.
The second mistake is over-trusting first-party sources. Many enterprises pull MCP servers from public registries on the assumption that the maintainer is reputable. The maintainer often is. The hundredth contributor to a popular MCP server, the one whose pull request was merged last Tuesday and made it into the latest release, is a different question. The supply chain hygiene that applies to any open-source dependency applies here, and is more often missing.
The third mistake is missing inventory. When a CVE drops against a popular MCP server, the question every CISO asks is, "are we running it?" Teams that cannot answer in minutes are running their incident response from a position of ignorance. The fix is to enumerate every MCP server in the environment, its version, its deployment location, and its configuration, and to keep that inventory current.
What To Watch For The Rest Of 2026
We expect three things over the next nine months. The first is the emergence of a small number of "household name" MCP server CVEs — the kind that get covered in mainstream tech press because they affect a tool a million developers use. The second is the first authenticated wormable MCP exploit chain, where a compromised server can pivot to other MCP servers in the same agent's tool list. The third is the formalization of MCP scanning by traditional security vendors, with explicit MCP coverage in vulnerability scanners, SBOM tools, and policy engines. By the end of the year, treating MCP servers as untracked infrastructure will look as outdated as treating containers that way did in 2018.
How Safeguard Helps
Safeguard treats MCP servers as the production services they are. Every MCP server in your environment is enumerated in your AI bill of materials with version, source, hash, and tool surface, so when a new disclosure lands you know exactly which deployments are exposed and which agents call them. Continuous CVE matching against the MCP ecosystem feeds the same vulnerability inbox your team already uses. Policy gates can require authentication, signed releases, and minimum hardening configuration before an MCP server is allowed in production. The protocol traffic itself is observable through Safeguard's runtime telemetry, so anomalous tool calls — unauthenticated invocations, unexpected tool use, requests that match known exploit signatures — surface as findings the moment they occur. Disclosure norms are still settling in the MCP ecosystem; your inventory and patch posture should not be.