Loading…
Between January and February 2026, researchers filed 30+ CVEs against MCP. April added MCPwn, Azure MCP SSRF, and the Anthropic Git RCE chain. The triage list and what the AEPD now requires.
Thirty CVEs in sixty days. 437,000 downloads of one vulnerable package. 150 million downloads across 200+ open-source projects affected by one or more disclosed issues. 7,000+ publicly accessible vulnerable servers. Up to 200,000 vulnerable instances. Those are the numbers the Vulnerable MCP Project, Practical DevSecOps, and Ox Security's disclosures aggregate to as of 18 April 2026.
If you ship agents that call tools, you probably added Model Context Protocol support sometime between March 2025 and February 2026. That adoption wave has now collided with a security-researcher wave at roughly half a CVE per day. This piece is the patch-list-and-structure read; the architectural framing lives in securing MCP servers. Here is what to triage today, what April added to the list, the architectural pattern under all of them, and the regulatory layer the AEPD just made explicit.
The heyuan110 retrospective and the Vulnerable MCP Project database together give the cleanest snapshot of the surface.
The MCP Security 2026 retrospective names the underlying pattern bluntly: "the root causes were not zero-days — they were missing input validation, absent authentication, and blind trust in tool descriptions." Most of the 30+ CVEs are bugs that a security review would have caught at the 10th server, not the 10,000th.
Ranked by exploitability against a typical 2026 MCP deployment. Names and CVSS scores from the Vulnerable MCP Project.
1. CVE-2025-6514, mcp-remote OS command injection (CVSS 9.6, fixed). Client-side RCE from a malicious MCP server. The package has 437,000+ downloads and the Vulnerable MCP Project calls this "the first documented instance of full RCE on the client OS from a remote MCP server." Disclosed 9 July 2025; fixed in versions after 0.1.15. If you have not upgraded, do that this hour.
2. CVE-2026-23744, MCPJam Inspector unauthenticated RCE (CVSS 9.8). Inspector binds to 0.0.0.0 by default with no authentication. Any network-adjacent attacker can hit the listener and execute arbitrary code. Affects MCPJam inspector ≤ 1.4.2. Disclosed 1 February 2026.
3. CVE-2026-33032, Nginx-ui MCP auth bypass (MCPwn, CVSS 9.8). The /mcp_message endpoint is missing the AuthRequired() middleware that its paired /mcp endpoint has. Two HTTP requests, no credentials, complete Nginx server takeover via the 12 destructive MCP tools the endpoint exposes. Fix shipped in 2.3.4 on 15 March 2026; Recorded Future flagged active exploitation on 15 April 2026 against ~2,600 publicly exposed instances on Shodan.
4. CVE-2026-26118, Azure MCP server SSRF (CVSS 8.8). Server-side request forgery in Azure MCP Server tools that accept user-provided URL parameters. An authorised attacker submits a malicious URL instead of a standard Azure resource identifier; the MCP server makes the outbound request, possibly attaching its managed identity token. The attacker walks away with permissions across every resource the managed identity authorises. Patched in Microsoft's March 2026 Patch Tuesday on 10 March 2026.
5. CVE-2025-68145 / 68143 / 68144, Anthropic mcp-server-git RCE chain. Three flaws in the official Anthropic Git MCP server: missing --repository path validation (68145), git_init accepting arbitrary paths (68143), git_diff and git_checkout passing user-controlled arguments to GitPython (68144). Chained with the Filesystem MCP server, an attacker writes a malicious .git/config and triggers RCE through prompt injection. Reported by Cyata in June 2025; Anthropic released the 2025.12.18 fix; The Register and The Hacker News disclosed publicly on 20 January 2026. The git_init tool was removed entirely.
6. CVE-2026-25536, MCP TypeScript SDK cross-client leak (CVSS 7.1). When a single McpServer instance is reused across multiple clients (e.g. behind an HTTP reverse proxy), responses leak across client boundaries. Affects versions 1.10.0–1.25.3. Pin past 1.25.3 if you serve multiple clients from one instance.
7. CVE-2025-54136, Cursor "MCPoison" trust bypass. Trust-on-first-use without re-validation: an MCP server is approved once, a later update to its tool descriptions does not re-prompt the user, malicious instructions get injected silently. Ox Security found that nine of eleven tested MCP marketplaces fell to variations on this pattern. Fix on the client side requires content-hash-based re-approval at minimum monthly.
There are 43 more in the database. These are the seven where a single afternoon patches the worst exposure.
Three things landed in April 2026 that change how the wave reads compared to the February snapshot.
MCPwn moved from research to active exploitation. CVE-2026-33032's fix shipped four weeks before exploitation began. That is the typical lag for a CVSS 9.8 with public PoCs. Pluto Security's Shodan scan caught roughly 2,600 publicly exposed instances at exploitation onset. If you operate Nginx-ui anywhere, the upgrade is overdue, not optional.
The Azure MCP SSRF patch is the first major-cloud MCP vulnerability with a Microsoft Patch Tuesday lifecycle. That matters because it is the first time MCP entered the standard enterprise patch cycle that ops teams already run. The Azure managed-identity exposure is also the worst privilege-escalation surface in the wave: a successful exploit grants the attacker every permission the MCP server's managed identity has been granted.
The Anthropic mcp-server-git chain shows the disclosure-to-fix lifecycle in a vendor that takes the protocol seriously. Cyata reported in June 2025; Anthropic shipped the fix in December and disclosed in January after fix uptake. Six months from report to public disclosure for a chained RCE is not fast for active exploitation but is fast for responsible disclosure. The decision to remove git_init entirely (instead of fixing it) is the right pattern: when a tool is too dangerous to safely sanitise, deprecate it.
The April additions sit on top of what was already the worst 60 days of MCP security disclosure history. The cumulative read is that the protocol's rapid adoption in 2025 outran the security-review capacity by an order of magnitude, and the gap is being closed by researchers in public rather than by vendors in private.
The most consequential disclosure of the wave is not a single CVE. It is a disclosure of a protocol-level choice and Anthropic's stated response.
Ox Security disclosed in April 2026 that MCP's STDIO transport design executes commands regardless of whether the resulting process starts successfully. Per Ox: "Pass in a malicious command, receive an error — and the command still runs. No sanitization warnings." The behaviour is embedded in the official Anthropic SDKs in Python, TypeScript, Java, and Rust. Anthropic's stated position, per Ox's writeup, is that "the STDIO execution model represents a secure default and that sanitization is the developer's responsibility" — a position rooted in the Unix tradition where the calling process owns input validation.
The "by design" stance puts the STDIO behaviour in an awkward place. It is not a CVE against the protocol itself; it is a design choice that operates as a footgun when developers treat STDIO as "just a local transport." Ten downstream CVEs have been filed against individual projects that got bitten by it. The structural risk is asymmetric: as long as the SDK does not validate, every new MCP server developer is one missing-validation check away from a CVE.
I think Anthropic's response is defensible in a narrow Unix-tradition sense, but the footgun thesis is the one to read the ecosystem from. The real-world effect is 10+ downstream CVEs and counting, until either the SDK behaviour changes or an enforced-validation layer becomes standard in the libraries developers actually pull from npm and PyPI.
The auto-approval pattern is the second protocol-level footgun. MCP clients ship with auto-approval as a convenience option; tool-poisoning benchmarks succeed 84.2% of the time when it is on. The convenience is real and the security cost is bigger than the convenience. Default-off auto-approval, with explicit per-tool approval gates for write-capable operations, is the correct posture for any production deployment.
The OWASP MCP Top 10 project entered Phase 3 beta in early 2026, led by Vandana Verma Sehgal. It is not yet a final release but it is the most structurally useful map of the attack surface right now.
Mapping the wave onto this list, the concentration is obvious: MCP05 dominates, MCP07 follows, MCP01 and MCP04 carry the supply-chain and managed-identity failures. The EchoLeak research from Microsoft 365 Copilot, walked in your AI agent has access to production data, is the clearest MCP10 case.
By time horizon, in the order to actually do them.
The next 60 minutes. Audit your installed MCP server and SDK versions; confirm mcp-remote is past 0.1.15; check that MCP Inspector and MCPJam Inspector bind to 127.0.0.1, not 0.0.0.0; confirm Nginx-ui is on 2.3.4 or later; confirm Azure MCP servers have Microsoft's 10 March 2026 patch; confirm the Anthropic mcp-server-git is on 2025.12.18 or later. Three terminal commands and one cloud console check.
This week. Pin every MCP server version in source control; treat MCP server configuration like a lockfile. No @latest. No unpinned registry refs. Run mcp-scan (free) or Cisco MCP Scanner / Snyk Agent Scan / SecureClaw against your installed set. Re-verify every approved MCP server's tool descriptions; if your client caches approval state (Cursor, Claude Code, Windsurf), the MCPoison class means the descriptions you approved may not be the ones running today. Disable auto-approval anywhere it's still on. Rotate any shared credentials touched by an MCP server.
This sprint. Implement permission boundaries: separate read-only tools from write-capable tools; gate write-capable tools behind explicit confirmation. Add audit logging for every tool invocation (tool name, parameters minus secrets, originating agent, user, timestamp). MCP08 is the genuine gap in most production deployments. Establish a publisher-trust policy with three tiers (first-party / trusted publisher / unvetted) and sandbox unvetted at minimum. Subscribe to the Vulnerable MCP Project feed; it is the best single source for the wave's continuation.
If you do exactly one thing, make it disabling auto-approval for write-capable tool calls and shipping a content-hash-based re-approval check on every MCP server connection. Together those two address MCP03 (tool poisoning), MCP07 (auth), and the MCPoison class (CVE-2025-54136). Three CVE classes, one afternoon of work.
This is what most MCP-security writeups miss. The Spanish data protection authority's 18 February 2026 agentic AI guidance (an 81-page document, summarised by Osborne Clarke and Freshfields) names MCP specifically as the kind of "interoperability standard" that "multiplies the number of interfaces at which personal data may be accessed, shared or transformed." That sentence places every MCP-connected agent processing personal data under GDPR scrutiny.
The implications for your DPIA, in operational terms.
Your processing record needs an MCP server inventory. Each connected MCP server is, in GDPR terms, an additional processing surface. The AEPD treats persistent agent memory as a regulated processing surface; MCP server-side state and tool descriptions sit in the same category. Document each server with: name, publisher, tools exposed, data classes the tools can access, retention behaviour, last vulnerability scan date.
Every CVE that processed personal data is a potential Article 33 / 34 trigger. A successful exploit of CVE-2026-26118 against an Azure MCP server connected to a customer database is, in GDPR terms, an unauthorised disclosure. The 72-hour clock under Article 33 starts when the controller becomes aware. The first 72 hours runbook covers the operational shape; the MCP-specific addition is that the agent's audit log (MCP08) is the evidence base for the breach scope assessment, and most production deployments do not have one.
The contractual layer matters. If you call an MCP server operated by a third party, you have a sub-processor relationship under Article 28(2). The vendor due-diligence checklist you already use needs an MCP-specific addendum (see AI vendor evaluation due diligence). At minimum: disclosure obligation on critical CVEs in their MCP surface, sub-processor lock policy on any further MCP servers they wire in, and a contract right to audit their MCP scan posture.
The regulatory layer is not theoretical. The AEPD's framework will be cited by other EU DPAs through 2026. The EDPB has a working group on agentic AI that the AEPD guidance is the most detailed input to. If you ship MCP-connected agents in the EU, the agentic-AI legal framework now references the protocol by name.
The wave's continuation depends on two trends moving in opposite directions. The optimistic read: researchers have now surveyed the largest exposed surface, the bug density will drop, and the ecosystem matures into something with a stable security posture by the end of Q3 2026. The pessimistic read: agent mode, Copilot Studio, third-party MCP marketplaces, and the standard's adoption into enterprise stacks like Azure are all expanding faster than the security-review capacity, and the cumulative count keeps climbing.
I am genuinely uncertain which read holds. The April additions (MCPwn moving to active exploitation, Azure MCP entering Patch Tuesday, the Anthropic Git chain) argue for the pessimistic read, because they are not in the same locations as the January-February wave. The wave is broadening, not deepening. That suggests new exposed surfaces produce new CVEs at the same rate as the older surfaces stabilise.
The operational answer is the same under either read. Treat MCP security as a recurring sprint commitment, not a one-time hardening. Pin versions. Audit Inspector bindings. Rotate credentials. Disable auto-approval. Subscribe to the database. And update the DPIA to acknowledge what the AEPD now names: the protocol multiplies the surfaces at which personal data is accessed, shared, or transformed.
Pick three: pin MCP server versions in source control, disable auto-approval for write-capable tools, and add audit logging for every tool invocation. Those three address the largest CVE classes (supply chain, tool poisoning, MCP08 silent gap) and the GDPR documentation gap simultaneously. Everything else in the triage queue is useful; those three are where one sprint of work collapses the worst of the wave's exposure for your deployment.
The MCP specification is strict. Most implementations skip the MUST-level requirements. The 30+ CVEs filed in the first 60 days of 2026 live in that gap. A field guide to the four attack classes that matter, with named CVEs and what to actually do.
Five concentric rings of agent blast radius (read, write, OAuth reach, external input, memory) anchored on the AEPD's 18 February 2026 agentic AI guidance and EchoLeak (CVE-2025-32711).
What EchoLeak actually showed, what the lethal trifecta actually is, and how your defense posture should change by architecture tier. Grounded in 2025 Microsoft, Google, and OWASP research.
Free tool · live
AI Data Flow Checker
Map how personal data flows through your AI integrations and spot the privacy risks before they spot you.