MCP Server Security: 12,520 Exposed Servers and What the Scans Actually Found

The Model Context Protocol never required authentication, and the public internet reflects that. Here is what the scan data says, what it does not say, and how to audit your own servers this week.

There are roughly ninety Model Context Protocol servers on the public internet advertising a tool named run_command, execute_command, run_shell, exec_command, or shell_exec. Censys counted them by name: 41, 39, 6, 3, and 2. Nobody had to break anything to find that out. They asked each server what it could do, which is precisely the question MCP is built to answer for whoever connects.

Those ninety sit inside a population of 12,520 internet-accessible MCP services that Censys identified in a four-day window ending April 28, 2026. By May 6 the same dataset held more than 21,000. And the reason any of this is possible is not a bug in anyone's code. The MCP specification does not require authentication or authorization. When a server designed for a local machine or a trusted network gets a public IP, it becomes an unauthenticated JSON-RPC endpoint that will enumerate its own capabilities for a stranger.

Why this matters the same week MCP grew up

The MCP Dev Summit Seoul runs August 13 and 14, presented by the Agentic AI Foundation, with AWS as the diamond sponsor and Anthropic's Den Delimarsky opening with a keynote titled "Two Years of MCP: State of The Ecosystem." Governance sits with the Linux Foundation now. MCP, goose, and AGENTS.md were donated into the Agentic AI Foundation in December 2025, with AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI as platinum members. The protocol has arrived at the stage where it gets certifications, conference tracks, and a neutral foundation.

Here is my position. The exposure problem is not waiting on a better spec. It is a deployment-default problem, and it belongs to the people running servers, not to the working group. Every credible fix available today is a thing you already know how to do: put an authenticating proxy in front of it, scope the credential, stop binding to 0.0.0.0. The reason it has not happened at scale is that MCP servers do not feel like servers. They feel like config. You add fifteen lines to a JSON file, a tool shows up in your agent, and nothing in that experience prompts you to think about who else can reach it.

What the scans measured, and what they found

Censys started collecting MCP exposure data on April 24, 2026, and published in May. As of April 28 the count stood at 12,520 services across 8,758 unique IP addresses, spanning 56 countries and 425 autonomous systems. Roughly 61.5 percent were reachable by bare IP address with no hostname needed. About 21 percent of those IPs hosted two or more MCP servers, and one address served 177 of them, which looks like a reverse proxy fronting a pool.

Version adoption is lopsided toward the old stable release. The 2025-03-26 spec accounted for 89.4 percent of observed services, with 2024-11-05 still holding 8.3 percent and the two newer versions together under 2 percent. That matters because 2025-03-26 is the version that introduced OAuth 2.1 authorization flows as an option. Nine out of ten public servers are running a spec that offers them auth and does not make them use it.

The capability breakdown is where it gets uncomfortable. Around 88 percent of these services advertise at least one tool, averaging 6.5 capabilities each. Censys sorted them by function:

Data and Knowledge, 1,776 services, including 1,056 offering direct query interfaces to SQL, NoSQL, and vector databases, and 642 exposing agent memory stores.
Infrastructure, 1,549 services, of which 687 fall into a System Control category covering command execution, shell access, and process management.
Then Content and Media, Business Ops, Finance, Commerce, Communication, AI and Agents, and Security in descending order.

Within that System Control bucket, roughly 90 servers advertise tools whose names leave nothing to interpretation: 41 named run_command, 39 named execute_command, 6 named run_shell, 3 exec_command, 2 shell_exec. Censys never invoked any of them. They read the manifests, which the protocol hands over during initialization in plaintext.

The servers that did try authentication mostly got it wrong

Exposure is one measurement. Whether authentication works on the servers that bothered is a separate one, and a measurement study posted to arXiv in May 2026 took it on. The authors identified 7,973 live remote MCP servers and found 40.55 percent exposing tools with no authentication at all. It is a preprint, not a published paper, so weigh it accordingly.

The part I keep coming back to is what happened on the servers that did authenticate. Of 119 real-world OAuth-enabled MCP servers the team could test, every single one exhibited at least one authentication flaw. They catalogued 325 flaws in total across four categories, and flaws in DCR, the OAuth flow that lets a client register itself with a server on the fly, affected 96.6 percent of tested servers. Responsible disclosure produced nine CVE IDs.

DCR is the specific thing worth understanding here. MCP deployments tend to combine open client environments, self-service client registration, and delegated authorization, and that combination is unusual for OAuth. The paper's argument is that these three traits together create attack surface that conventional OAuth deployments do not have, which is why importing an OAuth library and calling it done does not finish the job.

A number I could not verify, and why I am telling you

A figure has been circulating this month attached to MCP security coverage: more than 21,000 internet-facing instances, 640 production servers audited, 91.8 percent with no OAuth, and 687 with unrestricted shell tool access. It is attributed to an arXiv paper from July 2026. I could not resolve that arXiv ID to a retrievable paper, and neither could a second pass that went looking specifically for it.

Something worth noticing while you wait for a better source: 687 is also, exactly, the count of Censys System Control services. That category comes from matching regular expressions against advertised tool names, so it means "the manifest lists something that looks like command execution." That is a weaker claim than "687 servers were tested and found to grant unrestricted shell access to anonymous callers."

I want to be careful here, because I cannot read the paper and therefore cannot tell you the two numbers are the same number. It may be a coincidence. It may be independent confirmation. What I can tell you is that the strongest-sounding figure in the chain currently rests on a citation nobody I know of has successfully followed, and that a number you cannot trace does not belong in a risk register. The verifiable numbers are bad enough to make the point without it.

Put this into practice

The first step is smaller than you think, and it is inventory.

Find out whether you have any. Most teams running exposed MCP servers do not know it, because the server was a side effect of a demo or a hosted integration. Check what is listening in your own infrastructure before you look outward. Censys indexes MCP as a service type, so you can search your own ASN or domains directly.
Read your own manifest the way a stranger would. Connect to your server with no credential and list its tools. That output is the entire attack surface, and it is public by design. If the list includes anything that queries a database, executes a command, or reads memory, treat the server as internet-facing until proven otherwise.
Put existing auth in front of it rather than inventing new auth. A reverse proxy that already terminates your SSO is a better answer this week than a bespoke OAuth implementation. Given that all 119 tested OAuth servers had flaws, writing your own is the higher-risk path, not the safer one.
If you already run OAuth, go look at DCR specifically. That single feature accounted for flaws on 96.6 percent of tested servers. Ask whether you need open, self-service client registration at all. Most internal deployments do not.
Use the OWASP MCP Top 10 as a review checklist. MCP01 through MCP10 cover token mismanagement, scope creep, tool poisoning, supply chain, command injection, intent subversion, insufficient authentication, missing telemetry, shadow servers, and context over-sharing. Read it as a set of questions to ask in review, and pair MCP09 with step one, because shadow MCP servers are the same problem as not knowing what you run.

None of this requires waiting for a spec revision. All of it is available on a Tuesday afternoon.

Honest limitations

The Censys data is a snapshot taken four days after they began scanning, published in May, and reflecting April conditions. It is a discovered population, not a census, and both the total and the mix have moved since.

Censys never executed anything on these servers. That is the right call ethically and it caps what the data can claim. "Advertises a shell tool" is not "grants shell access." Some fraction of these are demos, templates, and tutorial deployments wired to nothing. Censys says as much, and calls the hope that they are harmless a hope rather than a finding.

Some fraction are also bait. The most quotable server in the whole report is one calling itself prod-corp-mcp-server, advertising config://production/database and configuration data that looked like API keys across eighteen hosts. Censys assesses it as most likely a honeypot or a deliberately fabricated test deployment, with none of the exposed data appearing legitimate. I nearly opened this article with it, which is a decent illustration of the problem: the most alarming thing in a scan dataset is often the thing somebody put there to be found. Read the caveats attached to the examples, not only the examples.

The functional categories come from regular expressions against tool names, which produces both false positives and misses. A server with a shell tool named something imaginative will not appear in the System Control count.

The authentication study tested 119 servers out of 7,973 it identified, selected for being testable OAuth deployments. "Every tested server had a flaw" is a strong finding on a small and non-random subset. The 40.55 percent unauthenticated figure covers the broader population and is the more portable number.

The OWASP MCP Top 10 is still an incubator project. Its own page lists it as version 0.0.0 in Phase 3 beta, with the next release due October 2026, and the page names MCP06 two different ways: Intent Flow Subversion in the summary table, Prompt Injection via Contextual Payloads in the detailed section. Treat it as a shared vocabulary that is still settling, not as a control framework you can certify against.

What to do with this

The gap here is not knowledge. Every practitioner reading this already knows you do not put an unauthenticated RPC endpoint with database access on a public IP. The gap is that MCP servers do not announce themselves as that thing, and the tooling around them optimizes for how fast you can add one.

So the useful move is deliberately unglamorous. Go find out what you are running. Connect to it without a credential and read what comes back. If the answer embarrasses you, you have learned something worth more than any conference keynote, and you have learned it before someone else did.

Sources: Censys, "MCP Servers on the Internet"; arXiv 2605.22333, "A First Measurement Study on Authentication Security in Real-World Remote MCP Servers"; OWASP MCP Top 10; MCP Dev Summit Seoul, Linux Foundation Events; Linux Foundation, Agentic AI Foundation formation.