The Model Context Protocol is how most coding agents now reach the rest of the world: a small server sits between the agent and a database, a cloud API, a filesystem, and advertises what it can do. Roughly 21,000 of these servers are reachable on the public internet. Nobody had checked what happens if a stranger calls one.
A researcher did, by finding live servers across eleven different places they get listed and then actually talking to them rather than reading their source code. More than nine in ten of the servers tested had no meaningful authentication in front of them. Anyone could ask what tools a server offered and then invoke them. Across the confirmed set, 687 of those advertised tools offered shell execution (run a command on the host machine) with nothing standing between them and the open internet.
The cause is a default nobody chose.
"The result is that the path of least resistance—the npx @modelcontextprotocol/create-server onboarding path—produces an unauthenticated HTTP server by default."
The protocol was designed for servers running locally, where the operating system provides the security. Network deployment came later, and the tooling never caught up. Ship the starter template to a hosting platform and it's live and open.
Two in five servers vanished within three days, the churn rate of weekend experiments rather than production services. That sounds reassuring until you look at which ones stayed.
"This suggests that the most dangerous deployments are also the most persistent, likely because they underpin production-adjacent agent workflows rather than transient experimentation."
The servers wired into real workflows are exactly the ones that keep running.
For an engineering leader the practical question is whether any of this is yours. MCP servers get stood up by individual engineers in an afternoon, on a company card or a free hosting tier, and they don't appear in the service catalogue, the on-call rota, or the threat model. The mental model to break is "it's just a connector." A tool server is a public network service that executes privileged operations, and it deserves the same review as anything else with a routable hostname.
Two things to do. Ask who in the organisation has deployed one and where it's running. The answer is rarely nobody. And treat vendor claims carefully: a supplier saying their MCP integration is secure is describing their repository, not the instance actually running, and the study's whole point is that those diverge.
The findings themselves are modest in scale: 68 confirmed vulnerabilities from a single researcher, on the servers that happened to be discoverable, and the paper is careful to call its numbers a lower bound. That's the right way to read it. The stronger signal is not the vulnerability count but the default, and the default hasn't changed.
Sources
- Padilla, N., "Exposed by Design: A Dynamic Security Assessment of Internet-Facing MCP Servers at Scale" — https://arxiv.org/abs/2608.00150