SecurityArticle
New internet-wide scanning research shows MCP's authorization spec works — the way developers deploy servers doesn't.
A paper posted to arXiv in late July counted more than 21,000 Model Context Protocol server instances reachable from the public internet. Of the servers the author managed to audit dynamically, 91.8% had no OAuth in front of them, and 687 tools across the confirmed set exposed shell execution with no access control at all.
The tempting headline is "MCP is broken." That's the wrong read. The uncomfortable truth in the data is that MCP's security model mostly exists on paper — the spec has had a real authorization framework since March 2025 — and the ecosystem is shipping servers as if it doesn't. This is a defaults-and-deployment failure, and we've watched this exact movie before.
What the scan actually found #
The study, "Exposed by Design", is worth reading past its abstract, because the numbers are more nuanced than the 21,000 figure suggests. The author discovered candidate servers passively through eleven sources — Shodan, Censys, FOFA, certificate transparency logs, plus package registries like npm and PyPI and MCP directories like Smithery and PulseMCP — then probed them with a purpose-built framework covering ten vulnerability classes.
Of 21,000+ detectable instances, only 640 were confirmed as real production MCP servers, and 414 could be fully audited. That's where the 91.8%-no-OAuth figure comes from. The audit surfaced 68 reportable vulnerabilities — SQL injection, SSRF, path traversal, prompt injection — and, most striking, 41.6% of confirmed servers vanished within three days between measurement runs.
That churn number is the tell. These are largely development instances: someone runs a server with host="0.0.0.0"
to test against a remote agent, forgets about it, kills the box a few days later. The exposure is transient per server but permanent as a population. There's always a fresh cohort of unauthenticated MCP endpoints online, and attackers scan continuously.
The trend line matters more than any snapshot. When Knostic ran a similar hunt in mid-2025, they found roughly 1,800 exposed servers. A year later it's an order of magnitude more, which tracks MCP's adoption curve — Anthropic cited 97 million monthly SDK downloads when it donated the protocol to the Linux Foundation's Agentic AI Foundation in December 2025.
The protocol isn't blameless — but the spec isn't the gap #
There is a genuine architectural argument running in parallel. OX Security's April 2026 audit of the STDIO transport found that malformed input could still trigger command execution in a pattern affecting 200-plus open-source projects and roughly 150 million downloads; they filed 30+ disclosures and landed more than ten high or critical CVEs. Anthropic's position, per the report, is that STDIO's execution model is a secure default and input sanitization is the developer's job. The security community mostly disagrees, and now that MCP governance sits with a neutral foundation co-founded by Anthropic, Block, and OpenAI, that fight will get litigated in the open rather than settled by one vendor. Good.
But hold the two findings side by side and the picture sharpens. The STDIO issue requires something malicious to reach a locally spawned process. The 21,000 exposed servers require nothing but a port scan. The spec's authorization model — OAuth 2.1 with resource indicators, tightened in the June 2025 revision — addresses exactly this, and 92% of audited deployments skipped it. The spec is optional where it should be insistent, and SDK defaults let you go from tutorial to internet-exposed without ever seeing the word "token."
If you were doing security work in 2017, you know this shape. MongoDB, Redis, and Elasticsearch all went through the same lifecycle: developer-friendly defaults, no auth out of the box, explosive adoption, then tens of thousands of exposed instances and the ransacking campaigns that followed. Every one of those projects eventually flipped to secure-by-default binding and auth. MCP is at the pre-flip stage, with a worse blast radius — an exposed Redis leaked data, but an exposed MCP server with a shell tool is a remote code execution endpoint that also happens to describe its own capabilities to anyone who asks.
What to do before you ship an MCP server #
Concrete guidance, in priority order:
Default to stdio. If your server serves one local agent — Claude Code, Cursor, an IDE extension — there is no reason for it to own a network socket. The client spawns the process; nothing is listening.
If you need HTTP, bind loopback until auth exists. The FastMCP-style one-liner is where most of the exposed population comes from:
mcp.run(transport="http", host="0.0.0.0", port=8000)
mcp.run(transport="http", host="127.0.0.1", port=8000)
Implement the authorization spec, not a bearer-token shim. The current spec makes your server an OAuth 2.1 resource server: validate tokens, check the audience per RFC 8707, reject anything unscoped. If that's too much lift, put the server behind a gateway that does it — the emerging agent-gateway category exists precisely because of this gap.
Audit your tool surface like an API surface. A tool named run_command
on a network transport is a self-documenting backdoor — 687 of those were sitting on the open internet in July. Allowlist commands, drop shell tools from anything remote, and log tool invocations the way you'd log admin API calls.
Where this lands #
My call: the protocol survives this fine, but 2026–2027 is when MCP security stops being a blog-post genre and becomes mandatory plumbing. The foundation-governed spec process will face pressure to make authorization normative rather than recommended, SDKs will move to loopback-by-default binding the way MongoDB did in 3.6, and enterprises will refuse to terminate MCP traffic anywhere but a gateway. If you're building agentic tooling, assume that future now — retrofitting auth onto a protocol surface your agents already depend on is far more painful than starting with it. The researchers scanning for exposed servers this time were friendly. The next sweep won't be.
Sources & further reading #
21,000 MCP servers exposed: the protocol reaches a security inflection point— forkast.news - Exposed by Design: A Dynamic Security Assessment of Internet-Facing MCP Servers at Scale— arxiv.org - Systemic Flaw in MCP Protocol Could Expose 150 Million Downloads— infosecurity-magazine.com - Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF)— linuxfoundation.org
Emeka Okafor· Security Editor
Emeka has spent over a decade tracking threat actors, vulnerability disclosures, and the evolving landscape of application security, bringing a sharp continent-spanning perspective to his reporting. He's known for translating dense CVE advisories into clear, actionable context that developers and security teams alike actually read.
Discussion 0 #
No comments yet
Be the first to weigh in.