Knostic’s research team conducted a systematic study to locate exposed MCP servers on the internet. Leveraging Shodan and custom Python tools, we fingerprinted and mapped production MCP servers. All servers we discovered were insecure and revealed their capabilities to anyone asking.

In this series of posts, we are sharing our findings, along with a guide detailing how we fingerprinted MCP servers.

We identified a total of 1,862 MCP servers exposed to the internet. From this set, we manually verified a sample of 119. All 119 servers granted access to internal tool listings without authentication.

While only servers exposed to the internet were tested, and many others may be running on private networks, the number we identified is relatively low, suggesting that adoption still has a long way to go.

None of the servers were secure, and many were unstable when we connected to them and exhibited various bugs. This further indicates the relatively low maturity of the technology and its current stage of adoption. 

From this, we can conclude that while the technology is being actively explored and adopted, it remains in the early stages of the adoption curve.

The systems’ low stability and lack of security are significant concerns. It suggests that, as with previous technologies, security may only be actively introduced after widespread exploitation has already occurred. 

How We Did It

MCP was not originally released with security in mind. Using Shodan and a suite of custom Python tools, we fingerprinted and mapped production servers that responded to unauthenticated, protocol-compliant handshake requests. These servers openly revealed their capabilities to anyone who knew how to ask the right questions.

We began by researching the distinctive traits of MCP servers to support accurate fingerprinting. We then trained Shodan to recognize these traits using a script that contains more than 100 Shodan filters.

The filters capture multiple dimensions of an MCP server's identity, including:

• Protocol Markers:

We searched for protocol-defined values such as "jsonrpc": "2.0" and "method": "initialize", which directly indicate a compliant server.

• Transport Signals:

We identified the use of Server-Sent Events by filtering for the text/event-stream content type. When combined with filters referencing MCP content, this approach helped isolate relevant results.

• Endpoint Paths:

We searched for common URLs such as /mcp, /messages, and /api/mcp, which are often left in default configurations or linked from a homepage.

• Technology Fingerprints: 

Headers such as Server: uvicorn indicate the use of Python frameworks like FastAPI. When seen with MCP terms, these headers strengthened the attribution.

This was not a one-time task but an iterative cycle of discovery. We began with broad queries, analyzed the results, identified new patterns in server banners, and continuously refined our search criteria. By layering filters across content, transport, endpoints, and headers, we improved accuracy and developed a detailed map of exposed MCP servers.

To explore our methodology in more detail, see these technical walk-throughs: How to Find an MCP Server with Shodan, and Automating MCP Server Discovery with Claude Sonnet 4.

Using the official MCP Inspector tool to connect to an exposed, unauthenticated MCP server

How We Verified Them

Once a server was identified as likely running MCP, the next step was to determine whether it was functional. We did this by issuing a safe, read-only tools/list request. This is the MCP equivalent of asking, "What can you do?" without actually invoking any tool.

We maintained a strict ethical boundary throughout the research process. At no point did we use tools/call or any command that could trigger actions, incur API usage costs, or alter data. Our goal was purely observational, and we respected responsible disclosure practices by validating exposure without causing impact. 

If a server responded to tools/list with available tool descriptions, we concluded it was not only active but also fully configured and capable of receiving commands. For a detailed overview of the verification steps, see our technical walkthrough: How to Find an MCP Server with Shodan. 

What It Means 

Our findings reveal a significant number of internet-exposed MCP servers operating in production environments, many lacking authentication or adequate safeguards. These servers respond to handshake requests and expose internal tools without validating the requester’s identity. Effectively, they publicly broadcast their capabilities.

This issue extends beyond a mere configuration oversight. The MCP specification, especially in its earlier versions, does not require authentication by default. As a result, insecure deployments are common. 

Why It Matters

Without intervention, organizations may continue deploying MCP services that expose sensitive functionality to unauthenticated users.