MCP Security: 40% of Servers Have No Authentication

Censys found 12,520 Internet-accessible MCP services. 40% have no authentication. VIPER-MCP produced 67 CVEs. Here is what every AI engineering team needs to know about MCP security.

Mayur Domadiya · June 8, 2026 · 5 min read

MCP went from a convenient way to plug tools into AI agents to one of the most exposed surfaces in the AI stack. This month the measurements made that concrete. Censys counted 12,520 Internet-accessible MCP services, most unauthenticated. A separate study found roughly 40% of remote servers expose their tools with no authentication at all. VIPER-MCP swept about 40,000 server repositories and produced 67 CVEs. At Boundev, we ship AI features every week and MCP is part of how agents connect to the tools they need. This post covers what the latest research reveals about MCP security and the single highest-impact move your team can make today.

MCP Is the Most Exposed Surface in AI

The Model Context Protocol gives agents a standard way to discover and call tools. It solves a real integration problem, which is why adoption has been fast. But the same properties that make MCP useful — open discovery, dynamic tool loading, bidirectional communication — also make it attractive to attackers.

This month three independent measurements quantified the exposure. Censys found 12,520 Internet-accessible MCP services, most without authentication. Trend Micro's follow-up scan counted 1,467 exposed MCP servers specifically, including CVSS 9.8 command-injection flaws in unofficial AWS and Azure MCP servers. And the first large-scale measurement study of authentication on remote MCP servers found roughly 40% expose their tools with no authentication at all, with nine additional CVEs traced back to broken OAuth flows.

The exposure problem is no longer confined to experimental local setups. It has reached the cloud.

67 New CVEs in One Month

VIPER-MCP is a combined static-and-dynamic analysis framework purpose-built for finding taint-style vulnerabilities in MCP servers. Run across roughly 40,000 server repositories, it uncovered 106 zero-day vulnerabilities and produced 67 CVEs in a single batch. That volume signals structural weakness: MCP servers are being built without security review at a rate that outstrips the community's ability to audit them.

Beyond the VIPER-MCP findings, specific vulnerabilities emerged across the ecosystem. Akamai disclosed SQL injection in the Apache Doris MCP server, an unauthenticated metadata-exfiltration flaw in Alibaba RDS MCP, and a potential takeover in Apache Pinot MCP. One of the three vendors declined to patch.

The MCP tool-poisoning CVE (CVE-2025-54136) is perhaps the most architecturally significant. A third-party server's boot-loaded tool metadata lands in the context window carrying prompt-level authority. That authority lets it inject instructions silently, with no user action required. The attack requires no jailbreak — just a malicious MCP server that the agent trusts.

Why Authentication Is Not the Full Answer

Putting authentication on every remote MCP server is the obvious first step, and it would eliminate the largest class of current exposure. But authentication alone does not solve the deeper problem: MCP servers carry instruction-level authority in the agent's context window.

The NSA's published guidance on MCP security design considerations walks through the inverted client-server pattern that makes MCP unique. In a typical protocol, the server holds authority and the client requests access. In MCP, the reverse is true — the agent (client) holds authority, and the server supplies tools that the agent executes. That inversion means a compromised or malicious server does not need to escalate privileges. It simply offers a tool the agent already has permission to call.

Two defense proposals from this month address the gap. Attested tool-server admission adds signed clearance assertions and deny-by-default allowlists so hosts can admit third-party MCP servers safely, without changing the protocol. MCPShield encodes MCP sessions as embedding-enriched graphs and runs a graph neural network over them to flag attacked sessions at the session level. Both are early but point in the right direction: defense must live in the tool execution layer, not the transport layer.

For teams building AI features that depend on MCP, the practical sequence is clear. Authenticate every remote server first. Audit which third-party servers boot-load into agent context. Then start planning how to inspect every exchange between agent and MCP to catch anomalous behavior before damage occurs.

What This Means

MCP security this month is defined by a gap between adoption and protection. The protocol solves a genuine integration problem, which is driving fast deployment. But the measurement data shows most deployments skip even basic authentication, and the vulnerability research shows structural weaknesses that authentication alone cannot fix.

The 67 CVEs are not a bug count. They are a signal that MCP servers are being built and shipped without the security review that production infrastructure requires. The NSA guidance is a reasonable baseline to design against, but the implementation work belongs to the teams shipping MCP into production.

Here is the open question worth sitting with. If MCP servers enter the context window with instruction-level authority, and 40% have no authentication, how many unauthenticated MCP servers are already loaded into your agent's context right now?