There is a particular kind of statistic that sounds like a scandal and is actually a floor. "Two in five public MCP servers have no authentication" is one of them. The number comes from the first systematic measurement of the thing everyone has been building on since 2024 — a scan of real, live, internet-facing Model Context Protocol servers — and the temptation on reading it is to file it under sloppy developers and move on. That reading is comfortable, and it is wrong. The interesting finding is not in the 40%. It's in the 30% who did the responsible thing.

The scan#

The study — A First Measurement Study on Authentication Security in Real-World Remote MCP Servers (arXiv 2605.22333) — did the unglamorous work of fingerprinting the ecosystem instead of theorizing about it. It identified 7,973 live remote MCP servers and sorted them by how they handle the front door:

If you stop there, the story writes itself: a third of the ecosystem is doing it right, a third is doing it lazily, and a third hasn't bothered. Turn the laggards into the OAuth column and the problem shrinks. This is the conclusion nearly every summary of the paper reached, and it is precisely the one the data refutes.

The part that should worry you#

The authors took the 30.45% who implemented OAuth — the conscientious cohort — and tested the 119 servers they could actually exercise. Every single one had at least one authentication flaw. Not most. All of them. Across those 119 servers they catalogued 325 distinct flaws, and 96.6% clustered on the same failure: dynamic client registration.

The servers that added OAuth were not the secure group. They were a different attack surface wearing a lock.

Dynamic client registration is the MCP OAuth profile's convenience feature — it lets a client register itself with the authorization server on the fly, no human in the loop, so that an agent can discover and connect to a tool it has never seen before. That is a lovely property for an open agent ecosystem and a terrible one for a security boundary. An open DCR endpoint is a confused deputy generator: it invites unknown clients to mint credentials, and the server, dutifully following the spec's happy path, hands them out. The vulnerability isn't a mistake layered on top of OAuth. It's the default.

This is why the framing matters. "Add authentication" is not a remediation here, because the most-recommended way to add authentication is where 96.6% of the failures live. The safety variable is not whether a server authenticates. It's whether whoever deployed it understood that the spec's convenience path is load-bearing for security — and almost none of them did. It is the same lesson the NSA's MCP design guidance keeps circling: the protocol's defaults optimize for reach, and reach and security are in tension by construction.

This is a transport-level problem, and it stacks on top of the content-level ones we've covered before — tool poisoning through malicious tool descriptions and rug pulls attack the agent through what a server says; the measurement here is about servers that never checked who was asking in the first place. An attacker doesn't have to poison a tool if the door was never locked.

What's behind the unlocked doors#

A base rate is only alarming in proportion to what it exposes, so it's worth knowing what these servers actually wrap. A parallel Censys inventory, taken 28 April 2026, counted 12,520 internet-facing MCP services across 8,758 unique IPs and sorted them by function. The largest bucket was Data & Knowledge — 1,776 services, many of them direct database query interfaces. A separate Infrastructure category included 687 "System Control" services exposing command execution and remote system interaction.

Read that against the 40.55%. The unauthenticated fraction is not a pile of read-only demo servers someone spun up for a hackathon. A meaningful slice of the open doors front databases and shells. An MCP server is exactly as dangerous as the tools it exposes, and the population includes remote command execution reachable, in the worst cases, by anyone who runs the same scan the researchers did.

Every number here is a lower bound#

The discipline this topic demands is to read each figure as a floor, not a fact. Both studies see only what is internet-facing and fingerprintable; self-hosted servers behind a VPN, local stdio servers, and anything that doesn't answer a probe are invisible to them. The true exposure is larger than 7,973 or 12,520 by an unknown margin.

And it moves fast. Censys's 12,520 became over 21,000 servers eight days later, on 6 May. That is not a rounding error; it is the growth rate of the attack surface itself. Any snapshot of MCP security is stale before it's published, which is the strongest argument for treating these as base rates to design against rather than a scoreboard to check once.

The disclosures have started. The measurement study alone obtained 9 CVEs through responsible disclosure; a June 2026 sweep catalogued in Adversa AI's roundup — the VIPER-MCP project, plus Akamai's database-MCP findings and fresh NSA design guidance — added dozens more. That pace will continue, because the underlying condition isn't a bug in one server. It's a protocol whose most-recommended authentication path ships open by default, deployed by people reading the happy-path docs.

The 40% will get quoted. Quote the 100% instead.