OX Security has published research on 15,465 publicly indexed Model Context Protocol (MCP) servers. It found some servers sitting on expired domains anyone can register, some routed through consumer tunnels, and no vetting by the marketplaces that list them. For teams wiring AI agents into business systems, the MCP server's hostname is a trust decision, and right now nobody upstream is making that decision for you.
What happened
The findings come from OX Security's gated report 15,465 MCP Servers. 0 Governance. and a companion piece on The Hacker News, dated October 6, 2026. That piece was written by Moshe Siman Tov Bustan, Security Research Team Lead at OX Security. This is vendor research, and the numbers below are OX's own.
- Scope: 15,465 servers across five MCP registries, deduplicated to 5,095 unique hostnames. The registries are not named in the public material.
- Location: 15.6% of hostnames resolve to infrastructure outside the US. The Hacker News piece counts 19 of those hostnames in China and 18 in Russia.
- Consumer infrastructure: 0.45% are on home networks or consumer tunneling services, mostly free ngrok.
- Dangling domains: 2.3% of hostnames no longer resolve. Six sit on expired domains that can be re-registered for $4 to $12 a year.
- Always-Allow persistence: OX's report summary says one "Always-Allow" grant to a malicious server let later prompt injections reach privileged file access with no further confirmation. According to OX, this worked against Claude Code running Haiku 3.5 and failed against Opus 4.6 and 4.7.
The article compares the situation to Google's Bouncer, which scanned Android apps for malware in 2012 before users could install them. OX says MCP marketplaces have nothing like it. It also points out that a remote MCP server can run backend code that differs entirely from its public repository, so reviewing the repo doesn't tell you what the server actually runs.
Why it matters
The expired-domain finding is the one identity teams should focus on. OX's article puts it plainly:
A new owner would inherit an established server identity, along with requests from any agent still configured to call it.
Most agent configurations identify an MCP server only by URL. If the domain lapses and someone else buys it, the agent keeps sending requests and the tool calls it was approved for. Nothing about the connection looks new. It is the dangling-DNS problem again, except the new owner can feed instructions to an agent with standing permissions.
The Always-Allow result is about consent. A one-time approval turns into a standing grant. A server that behaves well on day one can change its behavior later, and the user already said yes. That is the same standing-access pattern we covered in our MCP Python SDK OAuth credential theft piece, where a hostile server was treated as trusted inside the OAuth flow. Govern MCP servers like third-party OAuth apps: approved by name and owner, scoped, and reviewed, not added ad hoc by developers.
What to check in your environment
- Inventory MCP server URLs in use. Collect the remote MCP endpoints configured in developer tools, agent platforms and internal agents, along with who added each one.
- Check that every hostname still resolves and is still owned by the expected party. Look up each domain's registration and expiry. Remove any server whose domain has lapsed or changed hands.
- Flag tunnel and home-network endpoints. Treat MCP URLs on consumer tunneling services such as free ngrok as unapproved for business data.
- Review hosting location against data-residency requirements. OX notes the protocol has no built-in way to enforce where data goes, so check where approved servers resolve.
- Audit and reset Always-Allow grants. Find persistent tool approvals in agent clients and require per-action confirmation for file, shell and credential access.
- Move to an allowlist. Allow only reviewed MCP servers with a named internal owner. Don't let teams install new servers straight from a public registry.
- Limit what agents can reach. Assume any connected server could become hostile, and scope the file paths, tokens and APIs available to the agent accordingly.