DEV Community

Cover image for 30 CVEs in 60 Days: MCP's Security Reckoning Is Here
AI Agent Digest
AI Agent Digest

Posted on

30 CVEs in 60 Days: MCP's Security Reckoning Is Here

30 CVEs in 60 Days: MCP's Security Reckoning Is Here

The protocol that promised to standardize AI agent tooling just became the ecosystem's fastest-growing attack surface. 38% of servers have no authentication. Here's what you need to know — and fix.

Two days ago, we wrote about MCP crossing 97 million monthly downloads and called it "infrastructure." Chrome ships native support. Google Cloud built gRPC transport for it. The protocol won.

What we didn't write about — what almost nobody was writing about — is that MCP's rapid adoption has outpaced its security posture by a dangerous margin. And the numbers are now impossible to ignore.

30 CVEs filed in 60 days. A scan of 560 MCP servers found 38% with zero authentication. The official TypeScript SDK itself has published vulnerabilities. The protocol that connects your AI agents to every tool, database, and API in your stack is riddled with holes.

MCP won the adoption war. Now it has to survive the security reckoning.

The Attack Surface Has Three Layers

The 30 CVEs aren't random. They cluster into three distinct attack layers, each with different risk profiles and different fixes.

Layer 1: Server-Side Vulnerabilities (The Obvious Ones)

This is where most of the CVEs live — 43% involve exec() or shell injection in MCP servers. The pattern is painfully familiar: an MCP server receives input from the LLM, passes it to a shell command without sanitization, and now an attacker who can influence the LLM's output has remote code execution.

Another 13% are path traversal — MCP servers that expose file system access without proper path validation. Ask the agent to read a config file, and it happily serves up /etc/passwd or your .env with all your API keys.

These aren't sophisticated attacks. They're the same bugs we've been writing about for twenty years, repackaged in a new protocol. The difference is scale: there are now over 1,200 MCP servers in the ecosystem, and most were built by developers who understand LLMs far better than they understand input sanitization.

Layer 2: Client and Host Vulnerabilities (The Scary Ones)

This is where things get novel. Two new CVE classes emerged in early 2026 that target the infrastructure around MCP, not just the servers themselves:

CVE-2026-23744 (MCPJam Inspector): An unauthenticated HTTP endpoint that can install arbitrary MCP servers. The service listens on 0.0.0.0 by default — meaning anyone on the network can push a malicious MCP server into your setup. This isn't a hypothetical. It's a curl command.

CVE-2026-23523 (Dive MCP Host): The first host-layer CVE. Crafted deeplinks can install malicious MCP configurations on the client side. Think of it as phishing, but instead of stealing your password, it installs a backdoor into your AI agent's tool chain.

These attacks don't require compromising a server. They compromise the plumbing — the tools developers use to build and test MCP integrations. If your development environment is compromised, every server you build from it is potentially tainted.

Layer 3: SDK and Supply Chain (The Systemic Ones)

Two critical vulnerabilities have been published against the official MCP TypeScript SDK — the foundation that thousands of servers are built on. When the SDK itself has vulnerabilities, patching individual servers isn't enough. You need to update the dependency and rebuild.

Check Point Research also discovered that Claude Code's project configuration files could be weaponized to achieve remote code execution and steal API tokens through malicious MCP server configurations. The attack exploits the trust relationship between the IDE, the agent, and the MCP server.

This is the supply chain problem. MCP servers depend on the SDK. The SDK depends on how hosts load configurations. Hosts depend on how developers share project files. Compromise any link in that chain, and you compromise everything downstream.

The Identity Problem Nobody's Talking About

Beyond the CVEs, there's a structural problem: AI agents are the fastest-growing category of non-human identities in enterprise environments, and almost nobody is managing them properly.

Here's the data from recent enterprise security surveys:

  • 88% of organizations reported confirmed or suspected AI agent security incidents in the past year
  • Only 21% of executives have complete visibility into agent permissions, tool usage, or data access
  • 80% of organizations reported risky agent behaviors including unauthorized system access
  • Machine identities now outnumber human identities 80 to 1

The core issue: most organizations still treat AI agents as extensions of human users or as generic service accounts. Only 21.9% treat agents as independent, identity-bearing entities with their own access controls, audit trails, and lifecycle management.

When an agent connects to an MCP server, whose permissions does it use? Whose API key? Whose audit trail? In most deployments today, the answer is "the developer's" — which means every agent runs with developer-level access, 24/7, with no session timeouts, no privilege escalation checks, and no monitoring.

The Eight Threats You Need to Know

Based on the published research and CVEs, here are the MCP-specific attack vectors that matter most:

Attack What Happens Severity
Prompt Injection Malicious input manipulates the LLM into calling tools with attacker-controlled parameters High
Tool Poisoning Manipulated tool metadata causes the agent to trust and execute compromised tools Critical
Over-Permissioned Tools Tools granted excessive privileges amplify the blast radius of any compromise High
Supply Chain Tampering Fake or compromised tools infiltrate MCP registries Critical
Unrestricted Network Access MCP servers connecting freely to external services enable data exfiltration Medium
File System Exposure Improper path validation leaks sensitive files through MCP tool access High
Weak Authentication 38% of servers have no auth — anyone who can reach them can use them Critical
Confused Deputy MCP servers execute actions with elevated privileges without proper user context verification High

What You Should Do This Week

If you're running MCP servers in production — or even in development — here's a prioritized action list:

1. Audit Your MCP Servers for Authentication

This is the lowest-hanging fruit. If 38% of scanned servers had no authentication, the odds that you have at least one unprotected server are uncomfortably high. Every MCP server should require authentication. No exceptions.

2. Update Your MCP SDK Dependencies

Check what version of @modelcontextprotocol/sdk you're running. If it's older than two months, update it. The SDK-level vulnerabilities affect every server built on top of them.

3. Apply Least-Privilege to Every Tool

Each MCP tool should have the minimum permissions required. If a tool needs to read files, it shouldn't have write access. If it needs to access one API, it shouldn't have network access to everything. This is security 101, but the speed of MCP development means most tools were built with convenience, not security.

4. Sandbox Your MCP Servers

Run MCP servers in isolated environments — containers, VMs, or sandboxed processes. If a server is compromised, the blast radius should be limited to that server, not your entire infrastructure.

5. Treat Agents as Independent Identities

Stop running agents with developer credentials. Create dedicated service accounts with scoped permissions, time-bound tokens, and comprehensive audit logging. Assign a human sponsor accountable for each agent's lifecycle.

6. Monitor for Tool Poisoning

This is harder. Tool poisoning attacks manipulate metadata that your agent trusts implicitly. Use digitally signed, version-locked tools where possible. Implement anomaly detection on tool behavior. If a tool that usually returns JSON suddenly returns a shell command, something is wrong.

7. Red-Team Your Agent Workflows

Run adversarial tests against your MCP integrations. Try prompt injection. Try path traversal. Try feeding the agent instructions that would cause it to call tools with unexpected parameters. If you're not testing this, attackers will test it for you.

The Bigger Picture

MCP's security crisis isn't unique to MCP. It's what happens every time a protocol goes from "cool project" to "production infrastructure" faster than the security model can evolve. We saw it with Docker (years of privileged containers by default), with Kubernetes (open dashboards everywhere), with npm (typosquatting and supply chain attacks).

The pattern is always the same: adoption leads, security follows, and there's a painful gap in between where real damage happens.

MCP is in that gap right now. The good news is that the Linux Foundation's Agentic AI Foundation (AAIF) is governing the protocol, NIST is building agent security standards, and the security community is actively auditing. The bad news is that 70% of enterprises already have agents in production, and most of them were deployed before anyone was counting CVEs.

The protocol won. Now it needs to grow up.

Key Takeaways

  • MCP has accumulated 30 CVEs in just 60 days, spanning server, client/host, and SDK layers
  • 38% of 560 scanned MCP servers have zero authentication — this is the most urgent fix
  • The official TypeScript SDK has its own published vulnerabilities, making dependency updates critical
  • 88% of organizations reported AI agent security incidents, but only 21% have full visibility into agent permissions
  • Treat AI agents as independent identities, not extensions of human users — scoped credentials, audit trails, lifecycle management
  • The security gap between MCP's adoption and its hardening is real, but it's a familiar pattern — and it's fixable if you act now

AI Agent Digest covers AI agent systems — frameworks, architectures, and the tools that make them work. No hype, just analysis.

Top comments (1)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.