OX Security just published the largest audit of the public MCP ecosystem to date: 15,465 servers pulled from 5 registries, deduplicated to 5,095 unique hostnames. Six of those hostnames sit on expired domains that anyone can re-register for $4 to $12 a year, inheriting every agent still configured to call them. If your agents connect to MCP servers you do not operate, that second sentence is about you.
I went through the OX findings alongside the two other large scans, BlueRock's 12,000-server registry work and AgentAvow's 7,029-server static analysis. Below are the findings ranked by how fast they ruin your week, then a hardening checklist where every item maps to a specific finding.
Three teams, three methods, one conclusion
Quick context on why this dataset matters. BlueRock had the biggest number until now, more than 12,000 public servers scanned as of June 2026. AgentAvow's mcp-security-scan project statically analyzed 7,029 servers inside a 35,689-endpoint corpus. OX went wider than both, and The Hacker News published the writeup on October 6, 2026.
The methods differ (live infrastructure analysis, rule-based scanning, static analysis) and the conclusions do not. Independent scans keep landing in the same place: somewhere between 30% and 82% of public MCP servers carry exploitable flaws, per aggregated figures. At this point, arguing about the exact percentage is a way of avoiding the work.
The findings, ranked by how fast they ruin your week
1. Expired domains: a full identity takeover for $4 a year
2.3% of hostnames in the OX dataset no longer resolve, and six sit on expired domains registerable for the price of lunch. The exploit path needs no imagination. Register the domain, stand up an MCP server on it, and you inherit an established server identity plus requests from every agent still configured to call it. You see the queries those agents send, which often include internal data and credentials, and you control the tool descriptions that come back, which is a prompt-injection channel pointed straight at the model.
This is my pick for worst finding because the barrier is a credit card and the trust is pre-installed.
2. Jurisdiction drift: 15.6% of hostnames resolve outside the US
That includes 19 in China and 18 in Russia. An agent connected to one of these servers may be sending data to a jurisdiction your security team never approved, and nobody gets an alert when it happens, because the traffic looks like a normal tool call.
The subtler problem: OX notes that a server operator can launch on a clean US IP address and reroute traffic later. A point-in-time geolocation check at approval time is a screenshot of a moving target.
3. Publicly listed servers running from somebody's house
0.45% of the servers route traffic through consumer tunneling services, mainly ngrok-free. Translation: these are publicly listed MCP servers running on personal machines, most likely on home networks. Works out to roughly 70 servers in a dataset this size.
Your agent does not care. It will call a tool hosted on a laptop in someone's spare bedroom with the same trust it gives your internal API. That laptop has no patch SLA, no EDR you control, and a user who closes the lid at 6pm.
4. The repo you reviewed is not the code that runs
OX puts it bluntly: remote MCP servers can run backend code that differs entirely from what the public repository shows. Code review of the GitHub repo, the control most teams actually rely on, cannot establish what a server does.
AgentAvow's taxonomy names the nastiest version: dynamic_remote_load, fetch-then-exec rug pulls where the server pulls code at runtime, citing MCPoison (CVE-2025-54136). The mcp-security-scan project also flags prompt injection embedded in tool descriptions and missing authentication, and found 9% of scanned servers, nearly 1 in 11, ship at least one high or critical issue detectable by static analysis alone. Runtime-only issues sit on top of that.
Treat a newly adopted MCP server like a dependency that phones home. The triage discipline in The First Hour of an npm Supply-Chain Alert: Three Questions, One Right Order transfers directly.
5. The old web bugs moved into tool calls
BlueRock's numbers on 12,000+ servers: roughly 33% have unbounded URI fetch, meaning SSRF, and 42% have command injection. 6% carry critical vulnerabilities.
The exploit paths are depressingly familiar. SSRF in an MCP server lets a manipulated agent reach the cloud instance metadata service first, then internal APIs and credential stores. Command injection happens because MCP servers are often thin wrappers around CLI tools, parameterized with no input validation. The model supplies the argument, the argument lands in a shell.
Then there is the cross-server problem. AgentAvow calls it toxic_flow: the lethal trifecta of private-data read plus untrusted input plus outbound send, composing in one tool. It also composes across tools and across servers. Server A reads your drive, server B ingests pasted web content, server C sends email. Each looks fine alone. Wired into one agent, they are an exfiltration pipeline.
6. No auth, no limits, no bill-shock protection
Trend Micro found 492 MCP servers exposed to the open internet with zero authentication, as cited in the Practical DevSecOps roundup. Only 8.5% of public servers use OAuth. BlueRock names the other half of this one: denial of wallet, where unbounded or recursive tool calls exhaust API quotas, compute budgets, or billing limits on servers with no rate limiting and no cost controls.
The root cause is a missing Bouncer
Why is the ecosystem like this? Because there is no gate. OX's framing: MCP marketplaces have no equivalent of the Bouncer scanner Google shipped for Android back in 2012. Anyone can write a server, push it, publish it. No review, no guardrails. The full OX report, which also details methodology and a prompt-injection proof of concept, says it in six words: "15,465 MCP Servers, 0 Governance."
Growth compounds it. BlueRock counts more than 20,000 new MCP servers published every month, against 97 million-plus monthly MCP SDK downloads across Python and TypeScript. HackerOne logged a 540% surge in prompt-injection reports, as cited in the same roundup. And the plumbing itself has had issues: earlier in 2026, OX traced critical vulnerabilities in Anthropic's MCP source code, which has been downloaded more than 150 million times.
My position: treat public MCP registries the way you treated npm a decade ago. Useful, hostile, unvetted. OX's core argument deserves repeating, because it is the one most teams get wrong. The protocol is not the weak link. The implicit trust enterprises hand it is. Look at the enterprise side of the ledger: 47 to 53% of organizations already report AI agents exceeding permissions or suffering an incident, and only 14.4% of agents reach production with full security approval. That gap between demo and production is exactly what we mapped in Your Agent Demo Is Lying to You: A Map of the Production Gap.
"Those percentages are tiny," and other true statements that miss the point
The pushback I get: 0.45% ngrok and six expired domains are rounding errors. Sure, and your agent does not connect to 15,465 servers. It connects to maybe a dozen. Each connection is a binary trust decision with the full blast radius of that agent's permissions. An attacker does not need most servers to be malicious. They need the one server your analyst installed last Tuesday to be.
Second pushback: we only use well-known servers. Reputation verifies nothing at runtime (finding 4), and popularity is precisely what makes a server worth hijacking (finding 1).
Third: our gateway vendor handles this. Fine. Ask them which of the six findings above their product detects today, and get the answer in writing.
The hardening checklist, mapped to the findings
Each item names the finding it closes. The first two take an afternoon.
1. Inventory, then allowlist. Pull every MCP server any agent in your environment can reach: mcp.json files, desktop and IDE agent configs, gateway routes. One named owner per server. No owner, no connection. Everything not on the list gets denied at the egress layer. (Closes: all six. This is the control the ecosystem assumes you have and you probably do not.)
2. Vet domains like an attacker shopping for them. Before approving a server, check registration date, expiry, and resolution history. After approval, keep checking, because finding 2 means the launch-clean-reroute-later pattern defeats one-time review. Weekly re-resolution for anything touching sensitive data:
whois mcp-vendor.com | grep -iE "creat|expir|upd"
dig +short mcp-vendor.com # alert if this answer changesSix expired domains in one scan means this is not hypothetical. (Closes: F1, F2.)
3. Put an egress proxy between agents and the world, and deny by category. Tool-call destinations should never include cloud metadata, internal address space, or consumer tunnels:
deny 169.254.169.254/32 # cloud metadata
deny 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
deny *.ngrok-free.app # finding 3, personal machinesThen test the SSRF path directly: take any fetch-style tool your agent can call, point it at the instance metadata URL, and see what comes back. Anything other than an error is a failed control. (Closes: F5, partially F3.)
4. Treat tool descriptions as untrusted, versioned input. Snapshot every tool name, description, and schema at approval time. Diff on a schedule and alert on any change, because a quietly changed description is the rug pull from finding 4 arriving in production. Scan descriptions for injection attempts the way you would scan user content; the category-by-category approach in The OWASP LLM Top 10, Applied: A Pentester's Checklist for Each Category works here. (Closes: F4.)
5. Classify tools by blast radius and break the trifecta. Tag every tool read, write, destructive, admin, iam, or cost-impact. BlueRock's scanner uses this same classification, mapped to the OWASP MCP Top 10, MAESTRO, and MITRE CWE frameworks, and it is worth copying. Destructive and admin calls require human approval. And never let one agent session hold private-data read, untrusted input, and outbound send at the same time. If a workflow genuinely needs all three, split it across two agents with a reviewed handoff. (Closes: F5, toxic flows.)
6. Give each agent its own identity and a hard budget. No zero-auth servers, period. Scoped, per-agent credentials rather than one shared API key in an environment variable. Per-tool rate limits, a recursion depth cap, and a daily cost ceiling per agent; when the ceiling trips, the agent stops and a human looks. That is the denial-of-wallet fix. Only about 23% of organizations have a formal AI-agent identity strategy, so doing this puts you ahead of three quarters of the market. (Closes: F6.)
7. Rescan on a schedule and keep receipts. Quarterly re-vetting of approved servers: static analysis where source exists, runtime behavior testing always, because finding 4 says the repo is not evidence. Log every tool call with enough detail to reconstruct what left your environment. Auditors have already noticed this space, and Your AI Agents Are One Audit Question Away From a Finding covers how that conversation goes. (Closes: the governance gap underneath all six.)
One caveat on everything above: this is a point-in-time posture in an ecosystem adding more than 20,000 servers a month, and a good auditor will press on exactly that. For evidence between point-in-time audits, Axeploit pentesting for audits is the page to send a buyer or auditor.
If you want this checked automatically
If you want the auth and object-level checks in this article run against a live app, start with Axeploit's API security checker.
Key takeaways
- The largest MCP scan yet (15,465 servers, 5,095 unique hostnames) found an ecosystem with zero marketplace vetting: expired domains for sale at $4 a year, servers resolving to unapproved jurisdictions, publicly listed tools running on home machines.
- Code review of a server's repo does not tell you what the server runs. Verify behavior continuously, and diff tool descriptions over time to catch rug pulls.
- SSRF (33%) and command injection (42%) are the workhorse flaws. An egress proxy that blocks metadata endpoints and internal ranges, plus real input validation, removes most of the practical risk.
- Small percentages are not small risk. Your agent connects to a handful of servers, and one poisoned connection inherits everything that agent can touch.
- Allowlist, proxy, classify, budget, rescan. Five controls, each mapped to a finding from real scan data.
