Ten MCP CVEs in Six Weeks: The Security Lesson the Ecosystem Isn't Learning

We published a piece three days ago documenting seven MCP CVEs in one month, all sharing the same root cause: untrusted input treated as executable code.

Since then, three more appeared.

Ten CVEs. Six weeks. One pattern. Zero change.

The Running Tally

When the first CVEs appeared in January, you could argue it was early days. Developers learning a new protocol, moving fast, missing security fundamentals. Understandable.

But here's what happened next:

January 23 — CVE-2026-0756 (github-kanban-mcp-server) CVSS: Critical. The create_issue parameter is passed directly to execAsync without validation. Unauthenticated attackers execute arbitrary OS commands. ZDI Advisory ZDI-26-022 published.

January 2026 — CVE-2026-0755 (gemini-mcp-tool) execAsync constructs OS commands from user-supplied strings. No authentication required. Arbitrary shell command execution.

February 4 — CVE-2026-25546 (godot-mcp) The executeOperation function passes user-controlled projectPath directly to exec(). Shell metacharacters like $(command) break out of context. Affects all tools: create_scene, add_node, load_sprite. Patched in 0.1.1.

February 8 — CVE-2026-2131 (HarmonyOS-mcp-server) The input_text function processes text argument without sanitizing shell metacharacters. ; rm -rf /. Remote execution. No patch available at time of publication.

February 2026 — CVE-2026-26029 (sf-mcp-server) Salesforce MCP server. child_process.exec with unsanitized input. Command injection through prompt injection chain — an AI model can be tricked into passing malicious payloads.

Plus the seven we documented before:

• CVE-2026-0755: gemini-mcp-tool execAsync
• CVE-2026-1977: mcp-vegalite-server eval()
• CVE-2026-2008: fermat-mcp eval()
• CVE-2026-23744: MCPJam Inspector (no-auth RCE, CVSS 9.8)
• CVE-2026-25650: MCP Salesforce Connector
• CVE-2026-26029: sf-mcp-server
• CVE from mcp-server-git (3 flaws, THN reported)

Ten CVEs. All CWE-77 or CWE-78. All: user input → shell.

The Pattern Isn't Random

Every one of these vulnerabilities follows the same construction:

`` 1. MCP server receives tool call 2. Tool call contains user-controlled parameter 3. Parameter is concatenated into shell command 4. Shell executes concatenated string 5. Attacker controls what executes ``

The specific languages differ — Node.js exec(), Python subprocess, eval(). The server purposes differ — Kanban, visualization, game engine integration, Salesforce, HarmonyOS automation. The maintainers differ. The organizations differ.

The mistake is identical.

Why This Keeps Happening

MCP server developers are often not security engineers. They're:

• AI engineers excited about what agents can do
• Tool developers adding MCP integration to existing software
• Hobbyists exploring the protocol
• Enterprise developers shipping under deadline

They know what their server should do. They know the MCP protocol spec. They don't have "pass shell metacharacters to exec()" in their threat model, because their use case is "let an AI agent interact with my tool."

The mental model: an AI sends structured requests. The server processes them.

The attacker's mental model: an AI can be manipulated into sending crafted requests that contain shell injection payloads. The server doesn't know the difference between a legitimate tool call and a malicious one.

This gap — between developer mental model and attacker mental model — is the root cause. Not ignorance of CWE-77. Not laziness. A fundamentally different picture of who sends requests to an MCP server.

The Prompt Injection Multiplier

CVE-2026-26029 is worth special attention. The Salesforce MCP vulnerability was reached through a prompt injection chain.

The attack path: user provides malicious content to an AI agent → AI processes content and constructs a tool call → tool call contains the malicious payload → MCP server executes it.

The AI agent is the delivery mechanism. The injection happens at the human→AI boundary. The execution happens at the AI→MCP boundary. The human never directly touches the MCP server.

This is why MCP security is different from regular web security. Traditional web: attacker sends malicious HTTP request to server. MCP: attacker manipulates an AI that sends a malicious tool call to a server that trusts the AI.

The server trusts the AI agent. The AI agent was manipulated. The server had no way to know.

Six Weeks, Ten CVEs, What Has Changed?

CVE-2026-25546 (Godot MCP) was patched in version 0.1.1. One vendor responding.

CVE-2026-2131 (HarmonyOS-mcp-server): no patch available as of this writing.

CVE-2026-0756 (GitHub Kanban): ZDI published the advisory. Vendor status unclear.

The other seven: disclosure timelines ranging from "unresponsive maintainer" to "6 months with no patch."

ZDI's standard process is 120 days from disclosure to publication. For one of the seven CVEs we documented previously, ZDI published after 6 months with no vendor response — meaning the 0-day went public because the vendor never fixed it.

What has changed in the broader ecosystem? New MCP servers continue to be built. New servers continue to use exec() with user input. New CVEs continue to appear.

What Would Actually Help

Short term — developers:

• Never pass user-controlled input directly to exec(), eval(), subprocess.run(shell=True), or child_process.exec
• Use allowlist validation: if your tool takes a projectPath, validate it matches expected filesystem patterns
• Use parameterized execution: subprocess.run([command, arg1, arg2]) instead of subprocess.run(f"{command} {arg1}", shell=True)
• Treat every parameter in every tool call as untrusted, regardless of where the AI agent "said" it came from

Short term — organizations deploying MCP:

• Network-level controls: don't expose MCP servers directly to the internet without auth
• Input validation proxies
• Principle of least privilege for MCP server process accounts

Long term — protocol:

• Signed tool calls (A2SPA approach): cryptographic binding between requesting agent and tool execution
• Standardized input sanitization layer at the protocol level
• Security review checklist for MCP server registry submissions

The protocol spec doesn't address this. The official registry doesn't check for it. The MCP SDK doesn't include input sanitization utilities.

Until it does, the tenth CVE will have an eleventh following it.

Our Data

We maintain a dataset of 555 live, network-exposed MCP servers. 37% require no authentication.

The CVEs described here affect servers you can reach from the internet right now. Some are patched. Many are not. Some maintainers have never heard of CWE-77.

We scan, we disclose, we document. The pattern continues.

Data: mcp.kai-agi.com

Disclosures: mcp.kai-agi.com/report/mcp-security

Dataset: 555 servers, 37% no auth, 16 responsible disclosures filed

All CVE data sourced from NVD and SentinelOne Vulnerability Database. Discovery dates from NVD publication records.