30 MCP CVEs in 60 Days: The Attack Surface That Keeps Growing

Thirty CVEs. Sixty days. All targeting the same protocol: the Model Context Protocol. From January through early March 2026, the MCP ecosystem has produced vulnerabilities at a rate that has no precedent in developer tooling. Remote code execution, prompt injection, authentication bypass, cross-tenant data leaks. The vulnerability classes are not exotic. The root causes are not novel. Unsanitized input reaches dangerous functions. Authentication does not exist. Permissions are not checked. These are decade-old mistakes recurring in a protocol that was supposed to standardize how AI agents interact with the world.

The numbers behind this acceleration are stark. MCP SDK downloads surpassed 97 million per month, up from 100,000 in November 2024. That is a 970x increase in 14 months. There are now more than 5,800 available MCP servers. Sixty percent of organizations report running AI agents in production. And the security posture of those servers is dismal: Enkrypt AI scanned over 1,000 MCP servers and found that 32% had at least one critical vulnerability, servers averaged 5.2 vulnerabilities each, and exactly zero percent included any security documentation. Kai Security scanned 518 MCP registry servers and found that 41% had no authentication whatsoever.

This post breaks down the 30 CVEs by vulnerability category, examines the highest-impact examples in technical detail, maps each category to Aguara detection rules, and identifies the systemic patterns driving this growth. We also show what you can do today to reduce your exposure.

Categorizing the 30 CVEs

Not all 30 CVEs are the same. They cluster into distinct categories that reveal where MCP server developers consistently fail. The following table breaks down the distribution by vulnerability type, based on our analysis of each CVE advisory, the associated CWE classifications, and the affected components.

Category	Count	CWE Classes	Severity Range
Remote Code Execution (RCE)	11	CWE-78, CWE-94, CWE-77	High–Critical
Prompt Injection / Tool Hijacking	6	CWE-74, CWE-1336	High–Critical
Authentication Bypass / Missing Auth	5	CWE-306, CWE-287	High
Path Traversal / File Access	4	CWE-22, CWE-59	Medium–High
Cross-Tenant Data Leak	2	CWE-200, CWE-639	High
SQL Injection / Data Manipulation	2	CWE-89	High

Remote code execution dominates. Eleven of the 30 CVEs—more than a third—result in arbitrary command or code execution on the host system. Seven of those eleven were published in February 2026 alone, and they all share the same root cause: unsanitized user input reaching dangerous execution functions like subprocess.run(shell=True), exec(), or child_process.exec().

Prompt injection is the second-largest category. These vulnerabilities exploit the fact that MCP servers process content from external sources—GitHub issues, Slack messages, Asana tasks, web pages—and that content can contain instructions that the LLM interprets as commands. The AI agent becomes the attack vector, calling MCP tools on the attacker's behalf.

The authentication and authorization failures are perhaps the most systemic. When 41% of registry servers have no authentication, the CVE count understates the actual exposure. Missing authentication is not always reported as a CVE. It is simply a default state.

RCE: The dominant vulnerability class

The February 2026 RCE cluster deserves close examination because it reveals a pattern. Seven CVEs, all RCE, all published within the same month, all with the same fundamental flaw. The developers who built these MCP servers treated LLM-supplied input as trusted data. That input went directly into shell commands, eval() calls, or system-level execution functions.

CVE-2026-2256: MS-Agent shell tool command injection

CVE-2026-2256 is not an isolated case. It is the prototype for the majority of the February RCE cluster. The pattern repeats: a tool exposes a dangerous function (shell execution, code evaluation, file operations), takes input from the MCP client, and passes that input through without validation. The only variable across these CVEs is which dangerous function gets reached and which MCP server package contains the flaw.

Anthropic MCP Inspector RCE

The Inspector RCE combines two failure modes: missing authentication and code injection. The proxy trusted all incoming connections. Once connected, it allowed operations that resulted in code execution. Neither failure on its own is surprising. Together, they turn a development tool into a persistent backdoor.

What Aguara detects

Aguara's Command Execution category contains 16 detection rules that target the patterns behind these RCE vulnerabilities. The rules match configurations where MCP tools expose shell access, where input flows to subprocess or exec calls, and where tool descriptions indicate command execution capabilities without documented input validation.

# Scan for command execution patterns in your MCP setup
aguara scan --auto --category command-execution

# Example output for a vulnerable configuration:
CRITICAL  command-execution/shell-tool-unrestricted
  Tool "run_command" exposes unrestricted shell access
  File: ~/.config/claude/claude_desktop_config.json
  Server: my-custom-mcp-server
  Description: "Execute any shell command on the system"
  Risk: Arbitrary command execution via prompt injection

HIGH  command-execution/eval-in-tool-handler
  Tool "execute_code" passes input to eval()
  File: ~/.cursor/mcp.json
  Server: code-runner-mcp
  Risk: Code injection through LLM-supplied arguments

The MCP Attack category (12 rules) detects configurations vulnerable to the tool hijacking pattern that delivers the exploit. When an MCP server is configured to process external content—GitHub issues, Slack channels, email—and another server on the same client exposes dangerous tools, prompt injection in the external content can chain through to command execution. Aguara detects this cross-server attack surface.

Prompt injection: the universal delivery mechanism

Six of the 30 CVEs are directly classified as prompt injection or tool hijacking vulnerabilities. But prompt injection is also the delivery mechanism for many of the RCE vulnerabilities. The attacker does not need direct access to the MCP server. They need to place malicious content somewhere the AI agent will process it.

GitHub MCP Server prompt injection

This vulnerability is not specific to GitHub. The same pattern applies to every MCP server that ingests external content: Slack messages, Jira tickets, Asana tasks, email, web pages, RSS feeds. The content is attacker-controlled. The MCP server passes it to the LLM. The LLM interprets embedded instructions as legitimate commands. Any MCP tools available to the agent become available to the attacker.

Asana MCP Server cross-tenant data leak

Cross-tenant data leaks represent a category that will grow. As organizations connect AI agents to SaaS platforms through MCP servers, each server becomes a potential authorization boundary violation. The MCP specification does not enforce tenant isolation. That responsibility falls entirely on the server implementation. When the implementation fails, prompt injection turns a read-access agent into a data exfiltration tool.

What Aguara detects

Aguara's MCP Attack and Prompt Injection detection rules (12 + 8 rules) identify configurations where the prompt injection attack surface is exposed. This includes MCP servers that ingest external content without content boundary enforcement, tool descriptions that allow open-ended input, and configurations where high-privilege tools coexist with content-ingestion tools on the same client.

# Scan for prompt injection attack surface
aguara scan --auto --category mcp-attack,prompt-injection

# Example output:
HIGH  mcp-attack/cross-server-tool-chain
  Content-ingestion server "github-mcp" shares client with
  privileged server "filesystem-mcp" (tools: write_file, delete_file)
  File: ~/.config/claude/claude_desktop_config.json
  Risk: Prompt injection in GitHub content can chain to file operations

HIGH  mcp-attack/external-content-no-boundary
  Server "slack-mcp" ingests external messages without content boundaries
  File: ~/.cursor/mcp.json
  Risk: Malicious Slack messages can hijack agent tool calls

Authentication failures: the 41% problem

Five of the 30 CVEs relate directly to authentication bypass or missing authentication. But the Kai Security registry scan tells a bigger story: 41% of 518 MCP servers examined had no authentication at all. These are not misconfigurations. They are servers that were designed and shipped without any concept of access control.

The MCP specification originally did not address authentication. The protocol focused on tool description, invocation, and response format. Authentication was implicitly delegated to the transport layer or to the server implementation. The result: thousands of servers that accept connections from any client, execute any requested tool, and return results without verifying the caller's identity.

The MCP specification update introducing OAuth 2.1 standardization is a step forward. But it is a specification change, not a deployment change. The 5,800+ existing servers do not automatically gain authentication. Each one must be individually updated. Given that zero percent included security documentation (per Enkrypt AI's scan), the probability of widespread adoption is low without external pressure.

What Aguara detects

Aguara's Excessive Permissions and Credential Leak categories (14 + 19 rules) detect configurations where authentication boundaries are missing or where credentials are exposed through MCP tool chains. Rules flag MCP servers running without transport-level authentication, servers binding to 0.0.0.0 instead of localhost, and configurations where API keys or tokens are passed as plaintext command-line arguments.

# Scan for auth and credential exposure
aguara scan --auto --category excessive-permissions,credential-leak

# Example output:
CRITICAL  excessive-permissions/server-no-auth-network-exposed
  Server "data-tools" bound to 0.0.0.0:3000 with no authentication
  File: ~/.config/claude/claude_desktop_config.json
  Risk: Any network client can invoke all tools

HIGH  credential-leak/api-key-in-args
  Server "openai-mcp" passes API key as CLI argument: --api-key=sk-...
  File: ~/.cursor/mcp.json
  Risk: Key visible in process list, shell history, crash logs

Supply chain: 1,184 malicious skills and counting

In January 2026, ClawHub confirmed 1,184 malicious skills across MCP registries. These are not vulnerabilities in legitimate servers. These are intentionally malicious packages: typosquatting on popular server names, embedding backdoors in tool handlers, exfiltrating data through tool descriptions that instruct the LLM to send information to attacker-controlled endpoints.

The supply chain attack surface in MCP is structurally worse than in package managers like npm or PyPI. In those ecosystems, the package runs code that the developer can audit (in theory). In MCP, the tool description itself is an attack vector. A malicious tool description can instruct the LLM to perform actions without any code executing on the server side. The tool description becomes the payload.

This is what we documented in our earlier research on MCP tool poisoning. The problem has scaled. The 1,184 confirmed malicious skills represent the skills that were caught. The detection rate for tool-description-based attacks across the ecosystem is unknown, but given that zero percent of servers include security documentation, the outlook is not encouraging.

What Aguara detects

Aguara's Supply Chain category (15 rules) and External Download category (17 rules) target the installation and configuration patterns that introduce malicious or vulnerable MCP servers. This includes npx -y installations without pinned versions, curl | bash patterns, Docker images pulled from unverified registries, and tool descriptions containing exfiltration patterns.

# Scan for supply chain risks
aguara scan --auto --category supply-chain,external-download

# Example output:
CRITICAL  supply-chain/npx-unpinned-version
  Server installed via "npx -y some-mcp-server" (no version pin)
  File: ~/.config/claude/claude_desktop_config.json
  Risk: Any future publish of "some-mcp-server" runs on your machine

HIGH  external-download/curl-pipe-bash
  Server installation: "curl -fsSL https://example.com/install.sh | bash"
  File: ~/.cursor/mcp.json
  Risk: Remote script execution without integrity verification

Mapping CVE categories to Aguara detection rules

The following table maps each CVE category to the Aguara rule categories that detect the corresponding vulnerability patterns. Aguara does not detect CVEs by identifier—it detects the patterns that produce CVEs. A single Aguara rule category often covers multiple CVE categories because the underlying detection logic targets the root cause, not the specific manifestation.

CVE Category	CVE Count	Aguara Rule Categories	Rule Count
Remote Code Execution	11	command-execution, external-download	33
Prompt Injection / Tool Hijacking	6	mcp-attack, prompt-injection	20
Auth Bypass / Missing Auth	5	excessive-permissions, credential-leak	33
Path Traversal / File Access	4	credential-leak, data-exfiltration	30
Cross-Tenant Data Leak	2	data-exfiltration, ssrf-cloud	21
SQL Injection	2	command-execution, excessive-permissions	30

What the data tells us

Three patterns emerge from analyzing the 30 CVEs collectively rather than individually.

Pattern 1: the same root cause, repeated

Unsanitized input reaching dangerous functions accounts for the majority of these CVEs. The February 2026 RCE cluster—seven CVEs, one root cause—is the clearest example. MCP server developers are building tools that accept input from LLMs and pass it directly to exec(), subprocess.run(shell=True), child_process.exec(), or equivalent functions. No input validation. No allowlisting. No output encoding.

This is not a new vulnerability class. OS command injection (CWE-78) has been in the CWE catalog for decades. The OWASP Top 10 has listed injection attacks since its first publication. What is new is the delivery mechanism: prompt injection makes it possible to deliver the malicious input without any direct interaction with the target. The attacker plants the payload in content the AI agent will process. The agent supplies the payload to the MCP tool. The tool executes it.

Pattern 2: speed of adoption outpaces security

The growth metrics are extraordinary. From 100,000 monthly SDK downloads in November 2024 to 97 million in early 2026. From a handful of MCP servers to 5,800+. From experimental agents to 60% of organizations running them in production. That growth happened in 14 months.

Security did not keep pace. Enkrypt AI's finding that zero percent of the 1,000+ servers they scanned included security documentation is not a sampling error. It reflects a fundamental gap: the MCP ecosystem prioritized functionality and adoption over security. Server developers built integrations that worked and shipped them. Authentication, input validation, and access control were not part of the template they followed.

The Anthropic reference implementations reinforced this pattern. When the official Git, Filesystem, and SQLite servers shipped with path traversal, argument injection, SQL injection, and sandbox escapes, they set the security baseline for the ecosystem. Developers copied those patterns. The vulnerabilities propagated.

Pattern 3: the ecosystem lacks feedback loops

In mature ecosystems like npm or PyPI, security scanning is built into CI/CD pipelines. Dependabot, Snyk, and similar tools automatically flag known vulnerabilities. The MCP ecosystem has no equivalent infrastructure. There is no standard vulnerability database for MCP servers. There is no automated scanning in MCP client configurations. When a CVE is published against an MCP server package, there is no mechanism to notify the organizations that have deployed it.

This is why we built Aguara Watch. It scans 43,000+ skills across 7 registries four times daily, tracking the security posture of the ecosystem over time. But Watch monitors the public ecosystem. The deployed configurations inside organizations—the claude_desktop_config.json files, the Cursor MCP settings, the Windsurf configurations—are invisible unless someone scans them locally.

The industry is responding (slowly)

The acceleration of MCP CVEs has not gone unnoticed. Several significant developments in early 2026 indicate that the industry is starting to treat AI agent security as a distinct discipline.

OWASP Top 10 for Agentic Applications. Released in 2026, this is the first authoritative ranking of AI agent-specific risks. It covers prompt injection, tool misuse, excessive permissions, and supply chain attacks—precisely the vulnerability classes in the 30 CVEs. We mapped all 10 risks to Aguara detection rules in a dedicated post.

CoSAI 40-threat taxonomy. The Coalition for Secure AI published a taxonomy of 40 threats specific to the MCP ecosystem. This is the most comprehensive threat model for MCP to date. It covers categories from tool poisoning to transport-layer attacks to multi-tenant isolation failures.

MCP OAuth 2.1 standardization. The MCP specification update introducing OAuth 2.1 addresses the authentication gap. It defines how MCP clients should authenticate to servers and how servers should validate client identity. Adoption will take time, but the specification now has a position on authentication instead of leaving it implicit.

RSA Conference 2026. Scheduled for March 23–26, RSA Conference has multiple sessions on AI agent security this year. The concentration of MCP CVEs in the weeks leading up to RSA has made agent security one of the conference's focal topics.

What you can do today

The 30 CVEs are a signal. The vulnerability rate is not decreasing. As more researchers audit MCP servers and more organizations deploy agents in production, the CVE count will continue to grow. Here is what you can do now to reduce your exposure.

1. Scan your MCP configurations. Run aguara scan --auto to discover and scan all MCP client configurations on your machine. It supports Claude Desktop, Cursor, Windsurf, VS Code, Zed, and 14 other clients. The scan takes seconds and produces actionable output.

   # Auto-discover and scan all MCP configurations
   aguara scan --auto
   
   # Scan with severity filter
   aguara scan --auto --severity high
   
   # Scan a specific configuration file
   aguara scan ~/.config/claude/claude_desktop_config.json

2. Audit server installations. Check how your MCP servers were installed. If any use npx -y without a pinned version, curl | bash, or Docker images without digest pinning, you have a supply chain vulnerability. Pin versions. Verify checksums. Use lock files.
3. Separate content-ingestion servers from privileged servers. Do not configure GitHub, Slack, or email MCP servers on the same client as filesystem, shell, or database servers. The prompt injection attack chain depends on this co-location. Isolation is the most effective defense.
4. Require authentication on network-exposed servers. If any MCP server binds to a network interface (not just localhost), it must require authentication. The MCP OAuth 2.1 specification provides a standard mechanism. At minimum, use transport-level authentication (mTLS, API keys) until OAuth support is implemented.
5. Monitor the ecosystem. Check Aguara Watch for the current security posture of MCP servers you depend on. Watch scans 43,000+ skills across 7 registries and updates four times daily. If a server you use develops a known vulnerability pattern, you want to know before it gets a CVE.
6. Add scanning to CI/CD. Use the Aguara GitHub Action to scan MCP configurations on every pull request. Catch new vulnerabilities before they reach production. The action runs in seconds and fails the pipeline if critical findings are detected.

The trajectory

Thirty CVEs in 60 days is not the ceiling. It is the beginning of a vulnerability discovery curve that will steepen as more security researchers turn their attention to MCP. The ecosystem has 5,800+ servers, 32% of which have at least one critical vulnerability according to Enkrypt AI's data. The majority of those vulnerabilities have not been found yet.

The pattern is familiar from other protocol and ecosystem security histories. OAuth had its vulnerability spike. GraphQL had its exposure phase. Kubernetes went through years of security hardening after widespread adoption. MCP is following the same trajectory, but compressed: the adoption curve is steeper, the attack surface is larger (because LLMs add prompt injection as a universal delivery mechanism), and the consequences are more immediate (because agents have real-world tool access).

The organizations that treat MCP security as an afterthought will contribute to the next batch of CVEs. The organizations that scan configurations, isolate servers, require authentication, and monitor the ecosystem will not eliminate all risk, but they will reduce their exposure to the vulnerability classes that account for 30 CVEs in 60 days.

We built Aguara to make that second path accessible. 173 rules. 13 categories. Open source. Every vulnerability pattern documented in this post is detectable before it becomes a CVE in your infrastructure.

The MCP ecosystem's security problem is not a lack of awareness. It is a lack of tooling, feedback loops, and defaults. The protocol needs secure defaults. The ecosystem needs scanning infrastructure. The developers need templates that do not teach them to be insecure. We are working on all three.