Dora NodaIn the first sixty days of 2026, security researchers filed more than 30 CVEs against Model Context Protocol software — servers, clients, SDKs, and the proxy tooling in between. For a protocol that only launched in November 2024, that is not a rough patch. It is a security reckoning arriving roughly one year into production adoption, and it landed hardest on exactly the layer teams inspect the least: not the tools agents call, but the proxies, registries, and SDK plumbing that carry those calls.
If you are about to ship a deploy/rollback MCP server — tools that push code, restart services, and touch production on an agent's behalf — this wave is your threat model, pre-written. Here is what broke, where it broke, and the supply-chain discipline that falls out of it.
Thirty CVEs in sixty days: the breakdown
The headline number comes from early-2026 trackers that counted 30+ filed CVEs across January and February 2026, spanning the server, client/host, and SDK layers. But the count matters less than the distribution. Categorized by attack vector, the wave looks like this:
| Attack type | Share of the wave | What it means |
|---|---|---|
| Shell / command injection | ~43% | Servers passing unsanitized input straight to os.system, subprocess(shell=True), or child_process.exec |
| Tooling infrastructure flaws | ~20% | Bugs in MCP clients, inspectors, and proxy tools — not in any server's tool code |
| Authentication bypass | ~13% | Servers with no auth at all, or auth implemented incorrectly |
| Path traversal | ~10% | File-serving tools escaping their root directory |
Two things make this table worse than it looks. First, over half the CVEs reduce to web-security fundamentals — unsanitized shell input and unjailed file paths — that the rest of the industry learned to enforce twenty years ago.
Second, the distribution did not shift as the ecosystem matured. An April 2026 rescan of 1,808 MCP servers found 66% still had at least one finding, with the same 43/20/13/10 split. A separate scan of 2,614 public server implementations found 82% vulnerable to path traversal and 67% exposing APIs open to code injection. The wave was not a burst of exotic zero-days. It was the bill coming due on a protocol the industry shipped before securing.
Anatomy of the worst one: CVE-2025-6514
The single worst CVE in the wave predates it by half a year — and that is precisely the point. CVE-2025-6514, disclosed by JFrog Security Research in July 2025, is a CVSS 9.6 remote-code-execution flaw in mcp-remote.
That package is the bridge proxy that lets local-only MCP clients (Claude Desktop, Cursor, Windsurf at the time) reach remote MCP servers over HTTP — plumbing that sits in front of nearly every hosted setup.
The mechanism is worth understanding in detail, because it is the archetype of the whole plumbing-layer problem:
- During connection setup,
mcp-remoteperforms OAuth discovery against the remote server and reads theauthorization_endpointURL from the server's metadata. - Versions 0.0.5 through 0.1.15 passed that URL — fully attacker-controlled when connecting to a malicious or compromised server — into the
openpackage, which shells out to launch a browser. - Shell metacharacters smuggled into the URL (
$(...), backticks, PowerShell subexpressions) executed as OS commands on the connecting machine.
Full command control was demonstrated on Windows via PowerShell subexpression injection, with narrower but still dangerous control on macOS and Linux. JFrog called it the first documented case of full remote code execution against an MCP client in a real-world scenario.
The fix — version 0.1.16, released June 17, 2025 — stopped shelling out to attacker-influenced strings. But at disclosure the package had roughly 437,000 downloads, and every one of those installs had been one untrusted-server connection away from compromise.
Note what this CVE is not: it is not a bug in any tool implementation. No tool description was poisoned, no prompt was injected. The vulnerable component was the proxy everybody puts in front of every MCP server and then forgets about — and the attack surface was a trust decision (auto-open whatever URL the remote end hands you) baked into connection setup itself.
The wave lived in the plumbing, not the tools
CVE-2025-6514 would be a cautionary anecdote if it stood alone. It does not. Four independent data points from the same period all point at the same layer:
1. One in five CVEs was tooling infrastructure. The 20% slice of the breakdown — clients, inspectors, proxies — means the plumbing contributed roughly as many CVEs as auth bypass and path traversal combined. The components teams audit least produced a fifth of the findings.
2. The registries shipped without authentication. As of February 2026, 41% of servers in the official MCP registry had zero authentication (518 servers scanned). An Astrix survey of roughly 20,000 servers found only 8.5% using OAuth, with 53% still relying on static API keys.
Trend Micro, meanwhile, found 492 MCP servers exposed directly on the internet with no authentication at all. The discovery layer — the thing that tells your agent which servers exist and how to reach them — was, in early 2026, largely a public, unauthenticated directory.
3. Chained CVEs turned popular servers into RCE. The Atlassian MCP server (mcp-atlassian) drew CVE-2026-27825 (CVSS 9.1) and CVE-2026-27826 (CVSS 8.2), chainable into unauthenticated remote code execution on local networks.
The pattern repeats across the corpus: a widely-installed integration server, an auth or injection flaw in its shared request handling, and suddenly every agent host running it is reachable.
4. The stdio transport itself became a systemic RCE surface. A May 2026 systemic advisory on MCP's stdio transport counted 7,000 vulnerable servers on public IPs and 150M+ downloads of affected packages, with same-day disclosures against database-targeting servers (Apache Doris, Alibaba RDS, Apache Pinot MCPs) showing SQL execution, metadata exfiltration, and instance takeover. When the transport is the vulnerability, no amount of careful tool code saves you — every server speaking that transport inherits the flaw.
The through-line: the early-2026 wave was concentrated in proxies, registries, SDKs, and transports. Teams that reviewed their tool implementations and called it done were auditing the wrong layer.
Then the guidance caught up
Regulatory and standards bodies do not move fast, which makes the spring of 2026 notable: the guidance arrived within months of the wave, and it reads as a direct response to it.
On May 20, 2026, the NSA's Artificial Intelligence Security Center published its first Cybersecurity Information Sheet dedicated to MCP — "Model Context Protocol: Security Design Considerations for AI-Driven Automation" (U/OO/6030316-26, 17 pages). Its core finding is structural: MCP's security posture is, in the sheet's words, "highly dependent on implementation discipline rather than protocol guarantees."
Authorization in MCP is optional. There is no protocol-defined RBAC model. Audit logging exists only where implementations bother to produce it, inconsistently. The sheet's recommendations map almost one-to-one onto the wave's lessons: zone components so a compromised server cannot reach everything, vet servers with scanner tooling before deployment, log every invocation with cryptographic hashes of results, and route traffic through filtering egress proxies.
In parallel, the OWASP MCP Top 10 (v0.1 beta) gave the wave a taxonomy: token mismanagement (MCP01) and insufficient authentication (MCP07) at the top, with tool poisoning (MCP03), supply-chain attacks (MCP04), command injection (MCP05), and shadow MCP servers (MCP09) covering the rest of the observed failures. And Gartner projected in April 2026 that by 2028, a quarter of enterprise GenAI applications would see five or more minor security incidents per year, up from 9 percent in 2025 — tying the increase explicitly to MCP.
None of this guidance is hypothetical. Every recommendation has a CVE behind it: zoning answers the lateral-movement chains, vetting answers the 41%-unauthenticated registries, invocation logging answers the inconsistent-audit gap, and egress filtering answers the malicious-server-connect pattern that CVE-2025-6514 weaponized.
The deploy-server supply-chain checklist
Here is the artifact the wave owes you. If your MCP server exposes deploy, rollback, restart, or any other production-mutating tool, treat the proxy/registry/SDK layer as its own supply chain — with the same rigor you already apply to tenant workload images. Each row names the practice, what to pin or verify, and which slice of the wave it kills:
| # | Practice | Concrete bar | Kills this CVE class |
|---|---|---|---|
| 1 | Pin the gateway/proxy version | mcp-remote-class bridges pinned to fixed versions (≥0.1.16 for that CVE), upgraded deliberately, never floating | Tooling infrastructure (20%) |
| 2 | Vet servers before they are callable | Every server scanned (path traversal, injection, auth) before it joins your registry; rescan on update | Command injection (43%), path traversal (10%) |
| 3 | Run an authenticated registry | No callable server without auth; OAuth over static keys; unregistered servers uncallable | Auth bypass (13%), shadow servers |
| 4 | Zone the components | Deploy tools in their own network zone; a compromised docs-search server cannot reach deploy endpoints | Lateral movement / chained RCE |
| 5 | Log every invocation, hashed | Who, what, which identity, on whose behalf, when — plus a cryptographic hash of the result | Post-incident blindness |
| 6 | Egress-filter all MCP traffic | Clients reach servers only through an inspecting proxy; no direct connects to untrusted servers | Malicious-server-connect (the 6514 pattern) |
| 7 | Per-tenant, scoped credentials | No shared keys across tenants; deploy tools get short-lived, least-privilege tokens | Token mismanagement (MCP01) |
Row 1 deserves emphasis because it is the cheapest and the most skipped: "which gateway version fronts the deploy tools" should be a line in your bill of materials, reviewed the way you review a base-image tag. The 437,000 downloads sitting on vulnerable mcp-remote versions were not careless about their tools. They were careless about their plumbing.
The wave is the threat model now
The early-2026 MCP CVE wave ended the era of implicit trust in agent plumbing. The protocol will keep maturing — structured audit events, standard discovery, richer auth profiles are all on the roadmap — but none of that retroactively secures the proxy already sitting between your agents and production. Until the standards land, the seven-row checklist above is your MCP security posture: pin it, vet it, zone it, log it, filter it, scope it, and re-verify on every update.
The teams that internalize this fastest will be the self-hosters, for a simple reason: when you own the machines, "which version of the gateway is running" is a question you can actually answer — no vendor ticket required.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. If your agents are going to deploy, give them infrastructure you can audit. Star the repo on GitHub or deploy your first app today.
