MCP Server Security Study: Most Internet-Facing Hosts Lack Auth

What the audit found

The Model Context Protocol (MCP) has quickly become a common way to connect large language models to external tools, files, and services. A new study suggests that many of the servers implementing it are open to anyone who connects. Researchers describe it as the first dynamic security audit of internet-facing MCP servers, meaning they probed live deployments rather than only analyzing code. They examined 414 servers and identified 68 exploitable vulnerabilities 1.

The authentication result stands out more than the vulnerability count. Of the 414 audited servers, 91.8% did not use OAuth authentication at all 12. The study, built on a framework called Corvus, also counted 687 tool instances that allowed unauthenticated shell execution 2. In practice, anyone who finds such an endpoint could ask it to run commands on the host.

The researchers also found that these deployments are short-lived. Between scans, 41.6% of confirmed servers disappeared within three days 2. That churn suggests many MCP servers are put online quickly, probably for experiments or demos, and taken down soon after. It also suggests few of them go through any security review before they are exposed.

A structural problem, not just buggy code

It helps to separate two kinds of risk. Earlier MCP security work has focused on code-level flaws. One example is ToFu, a fuzzer that targets how MCP tools handle their arguments and surfaces bugs such as path traversal and command injection 2. Those findings matter, but they often assume a specific attack path: an adversarial or manipulated LLM sends malicious input to a tool.

The Corvus findings describe a different problem. They point to a structural exposure issue that exists separately from argument-handling bugs 2. If a server has no authentication and is reachable from the public internet, an attacker does not need to trick a model into calling a tool. They can call it themselves. The two problems compound each other. A path traversal or command injection flaw found by a fuzzer becomes far more dangerous when anyone on the internet can reach the vulnerable tool, not only an AI agent fed hostile content 2.

The 687 shell-capable tools make the point concrete. A tool that runs shell commands is effectively a remote code execution interface when it is exposed without authentication 2. No exploit chain is required.

Why this keeps happening

The study's title, "Exposed by Design," points to the authors' framing 1. The following explanation is an interpretation, but the reported figures fit it.

MCP servers are often written to give a local AI assistant powerful capabilities, such as reading files, querying databases, and running scripts. In a local, single-user setting, skipping authentication may look harmless. The risk appears when those same servers are deployed to cloud hosts or bound to public interfaces without anyone revisiting that assumption. The near-universal absence of OAuth 12 suggests that putting authentication in front of MCP endpoints is not yet a default habit in this ecosystem.

The three-day disappearance rate 2 supports the same picture. Developers who spin up servers for a quick test are unlikely to harden them. A brief exposure window still offers little protection, because internet-wide scanning can find a new host within hours.

What it means for teams using MCP

The practical lessons follow directly from the data:

• Treat MCP endpoints as production attack surface. If a server is reachable from the internet, it needs authentication. The study's 91.8% figure shows this is currently the exception 12.
• Restrict high-risk tools. Shell execution, filesystem access, and similar capabilities should be absent from public-facing servers or tightly gated, given the 687 unauthenticated shell-capable instances observed 2.
• Don't rely on code-level fixes alone. Patching argument-handling bugs like those found by fuzzers is necessary but not enough if the endpoint stays open to the world 2.
• Track ephemeral deployments. Short-lived test servers still count as exposures and should follow the same rules as long-running ones.

The bigger picture

The study's conclusion is that MCP's main security problem is not exotic AI-specific attacks. It is old-fashioned exposure. Prompt injection and model manipulation get much of the attention in agent security discussions, yet these results suggest the more immediate risk is ordinary: unauthenticated services running powerful tools on the public internet 12.

The 414-server sample is a snapshot, and the high churn means the population changes constantly. Even so, the pattern is clear enough to act on. Until authentication becomes standard practice, as the authors' "by design" framing implies it should be 1, many MCP deployments will remain reachable by anyone who scans for them.