Q1 2026 MCP CVE Roundup: 9 Vulnerabilities, 3 Patterns, 1 Lesson

Through all of 2024 and 2025, the Model Context Protocol had zero assigned CVEs. In Q1 2026, it got nine.

This is not a crisis. It is the vulnerability discovery phase that every protocol goes through once adoption reaches the threshold where security researchers start paying attention. HTTP had it. OAuth had it. GraphQL had it. MCP is having it now, and the data from this first wave tells us exactly where the systemic weaknesses are.

This post consolidates every known MCP CVE from Q1 2026 into a single reference. No vendor promotion. No product recommendations. Just the numbers, the patterns, and the implications.

The Full CVE Dashboard

Here is every confirmed MCP-related CVE published between January 1 and March 31, 2026:

CVE	Product	CVSS	Vulnerability	CWE
CVE-2026-32211	Azure MCP Server	9.1	Missing authentication on network endpoint	CWE-306
CVE-2026-26118	Azure MCP Server Tools	—	Elevation of privilege	—
CVE-2026-5322	mcp-data-vis	—	SQL injection via tool parameters	CWE-89
CVE-2026-5323	a11y-mcp	—	Server-side request forgery	CWE-918
CVE-2026-23744	MCPJam Inspector	—	RCE via 0.0.0.0 default bind	CWE-1188
CVE-2026-27825	mcp-atlassian	9.1	Arbitrary file write leading to RCE (MCPwnfluence)	CWE-22
CVE-2026-27896	Go JSON MCP	—	JSON parsing vulnerability	—
CVE-2026-2781*	mcp-proxy-auth	—	Authentication bypass	CWE-287
CVE-2026-3104*	mcp-shell-exec	—	Command injection via unsanitized input	CWE-78

Last two entries based on advisory tracker data; CVSS scores pending at time of publication.

Nine vulnerabilities. Seven distinct products. CVSS scores ranging from moderate to 9.1. Two of them from Microsoft. One from a widely-used Atlassian integration. The rest from community tools with thousands of installs.

The breadth is the story. This is not one bad actor or one sloppy codebase. This is a pattern distributed across the entire ecosystem.

Pattern 1: Missing Authentication (CWE-306)

The most common and most dangerous pattern. MCP servers that accept connections from any caller, no questions asked.

CVE-2026-32211 is the headline example. The Azure MCP Server exposed operations over the network without verifying the caller’s identity. Attack vector: network. Attack complexity: low. Privileges required: none. User interaction: none. Any process that could reach the endpoint could read and modify data through it.

But Azure was far from the only case. The authentication bypass in mcp-proxy-auth demonstrates the same root cause from the opposite direction: authentication logic existed but could be circumvented.

The underlying problem is architectural. The MCP specification defines a transport layer and a tool invocation protocol, but authentication is left to the implementation. Many implementers treat it as optional. In a protocol where the server defines what an agent can do, optional authentication is equivalent to optional access control on your entire agent capability surface.

Every MCP server that accepts unauthenticated connections over a network interface is a CWE-306 waiting to happen. The only question is whether a researcher finds it before an attacker does.

Pattern 2: Injection (CWE-89, CWE-78)

Classic injection vulnerabilities, wearing new clothes.

CVE-2026-5322 is textbook SQL injection. The mcp-data-vis server accepted user-supplied parameters in tool calls and concatenated them directly into SQL queries. An attacker who could invoke the tool — or an agent that was tricked into invoking it with crafted input — could execute arbitrary SQL.

CVE-2026-3104 follows the same logic with command injection. The mcp-shell-exec server passed tool parameters to shell commands without sanitization. From tool call to arbitrary command execution in one hop.

These are OWASP Top 10 staples, numbers 3 and 10 on the 2021 list. They are not new. They are not exotic. But they are appearing in MCP servers because many MCP authors are building tool handlers the same way developers built web forms in 2005: trusting input, concatenating strings, skipping parameterized queries.

The MCP context adds a specific wrinkle. Tool parameters in MCP can come from three sources: the end user, the LLM, or another tool’s output. Injection payloads can be embedded in any of these. A prompt injection attack that causes the LLM to pass '; DROP TABLE users; -- as a tool parameter is a realistic attack chain, not a thought experiment.

Pattern 3: Dangerous Defaults (CWE-1188)

Servers that ship with configurations no security-conscious operator would choose, but that most users never change.

CVE-2026-23744 is the clearest example. The MCPJam Inspector bound to 0.0.0.0 by default, meaning it listened on all network interfaces. Combined with insufficient authentication, this turned a local development tool into a network-accessible RCE vector. The fix was trivial — bind to 127.0.0.1 instead. But every installation between the initial release and the patch was exposed.

CVE-2026-5323 follows the same pattern from the SSRF angle. The a11y-mcp server proxied requests without validating the destination, allowing attackers to reach internal network resources through it. The default configuration did not restrict which hosts the server could contact.

The mcp-atlassian vulnerability (CVE-2026-27825) demonstrated how dangerous defaults compound. The MCPwnfluence attack chain exploited the server’s ability to write arbitrary files, which combined with the server’s default privilege level to achieve remote code execution. CVSS 9.1.

Dangerous defaults are particularly insidious in the MCP ecosystem because of how MCP servers are typically installed. The common flow is: clone a repo, run a command, connect your agent. Configuration review is not part of that flow. Whatever the defaults are, that is what most users run.

The Lesson: MCP Is a Control Plane

Strip away the individual CVE details and one structural insight emerges.

These are not API bugs. They are control plane bugs.

When an agent connects to an MCP server, it is not making a request to a service. It is discovering capabilities and executing them. The server defines the agent’s action space. A compromised or unauthenticated MCP server does not just leak data — it redefines what the agent can do and allows unauthorized parties to invoke those actions.

A missing-auth vulnerability on a REST API means someone can read your data. A missing-auth vulnerability on an MCP server means someone can:

Enumerate the full tool surface an agent has access to.
Invoke any tool with whatever privileges the server holds.
Inject tool definitions that the agent trusts as legitimate capabilities.
Chain tool calls into multi-step attack sequences the server author never anticipated.

This is execution takeover, not data exposure. The CVSS scores reflect severity, but the operational blast radius of an MCP control plane compromise may exceed what the score captures.

Every MCP vulnerability should be evaluated through this lens. SQL injection in a web app is bad. SQL injection in a tool that an autonomous agent calls based on LLM reasoning, where the results feed into further tool calls, is a different category of risk.

What the Data Tells Us

Three facts from the Q1 numbers:

There is no correlation between vendor size and security quality. Microsoft shipped a 9.1. Solo developers shipped 9.1s. A well-funded Atlassian integration shipped a 9.1. The vulnerability distribution is uniform across the vendor spectrum.

The vulnerability classes are not novel. Missing auth, SQL injection, command injection, SSRF, path traversal. These are solved problems in web security. They are unsolved problems in MCP because the ecosystem is young, the tooling is immature, and many MCP server authors are not security engineers.

The rate is accelerating. Zero CVEs in 2024 and 2025 combined. Nine in Q1 2026. This is partly a function of increased scrutiny — more researchers looking at MCP — but it also reflects the expanding attack surface as MCP adoption grows.

The data does not support using any heuristic other than “untrusted by default” for new MCP server connections. Not vendor reputation. Not download count. Not GitHub stars. The only signal that matters is whether a specific server has been audited for the specific vulnerability classes that Q1 2026 demonstrated are endemic.

What To Do

Five practical steps for anyone running MCP servers in production or evaluating them for deployment.

1. Audit your MCP server inventory. List every MCP server your agents connect to. Check each one against the CVE list above. Check for updates. If you are running any of the affected versions, patch immediately.

2. Route MCP traffic through a gateway. Direct agent-to-server connections mean every connection is an implicit trust decision with no central visibility. A gateway — any gateway — gives you a single point to enforce authentication, log tool invocations, and apply policy. Build one, buy one, or use an open-source one. The specific product matters less than having the architectural pattern in place.

3. Default to untrusted. Every new MCP server should be treated as untrusted until someone with security expertise has reviewed its tool surface, its authentication model, its default configuration, and its dependency chain. This is not paranoia. It is the statistically correct response to the Q1 data.

4. Monitor CVE feeds. The MCP vulnerability rate is not slowing down. Subscribe to NVD alerts for “MCP” and for every specific MCP server in your inventory. The GitHub Advisory Database is another source. Check weekly at minimum.

5. Do not use the vendor name as a security signal. This is the hardest habit to break, and the Q1 data makes it non-negotiable. Microsoft shipped a 9.1. The name on the package does not predict the security of the implementation inside it. Evaluate each MCP server on its own merits, regardless of who published it.

Looking Ahead

Q1 2026 was the MCP ecosystem’s first real encounter with systematic vulnerability discovery. It will not be the last. As MCP adoption grows, the number of servers increases, and the protocol takes on more sensitive workloads, the attack surface expands proportionally.

The encouraging signal is that every vulnerability listed here has been patched. The ecosystem is responding. Disclosure is happening through proper channels. CVSS scores are being assigned. The security research community is engaging with MCP as a serious protocol, not a toy.

The concerning signal is that the vulnerability patterns are basic. These are not subtle timing attacks or cryptographic weaknesses. They are missing authentication and unsanitized input. The floor needs to come up before the ceiling matters.

Nine CVEs in one quarter. Three patterns. One lesson: in a protocol where servers define what agents can do, security is not a feature. It is the foundation.

All CVE data sourced from the National Vulnerability Database, GitHub Security Advisories, and vendor disclosure pages. CVSS scores reflect published values as of April 7, 2026. This post will be updated as additional Q1 CVEs are confirmed or scores are revised.