Sure, but I was expecting more details on what was available. At least some analysis (perhaps using embeddings) on common function names, types, etc. What are people exposing? Is there overlap? What % of the open servers looked the same (indicating a common example / tutorial deployment)? What's the proportion of read/write functions (again using embeddings / word cloud maybe?)...
As is the article feels a bit light on details. I'm not surprised that there are open servers out there, but if you're writing an article about that, at least provide interesting details.
> 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.
The tool listings are not necessarily a secret, so not sure how this is "exposed". We have a public MCP, anyone can read our tool listings, but to actually use the tools you need to authenticate.
I’m with @NitpickLawyer on this; the scan is cool, but I was hoping for a bit more detail on what’s actually being exposed. Even something like a breakdown of common tool names or clustering by function type would’ve been really insightful.
That said, it’s still surprising (and a little funny) to see how fast these things end up public. Probably lots of default setups left running without realizing they’re wide open.
Hmmm. I thought that's the idea of MCP server - give LLM an interface to use your service. Why would it require authentication?
One of the tools could be to authenticate.
Please destroy this position if I'm wrong.
That only makes sense if models were autonomously adding MCP servers and managing accounts themselves. Currently, users add MCP servers to their clients (like Cursor or Claude Desktop), so authentication should happen at that level. If the model handled auth, you'd still need to provide credentials to the LLM for it to provide it to the MCP server anyway. It's better to pass auth data as for example headers in requests - this way your credentials never get sent to the model provider (unless you're running locally).
The two things I can think of are MCP servers with functions that make calls to a database with sensitive information, or are easy to pwn due to propping them up in a hasty and irresponsible manner.
The article would actually be interesting if they tried either of those with the servers they found.
Yep, if you put something on the open internet it needs authentication or it is public to everyone. This isn't a vulnerability unique to MCP - plenty of databases, REST APIs, S3 buckets, and other sorts of resources have been left open before. MCP is just the latest shiny thing people can leave unsecured.
Readit News
As is the article feels a bit light on details. I'm not surprised that there are open servers out there, but if you're writing an article about that, at least provide interesting details.
The tool listings are not necessarily a secret, so not sure how this is "exposed". We have a public MCP, anyone can read our tool listings, but to actually use the tools you need to authenticate.
That said, it’s still surprising (and a little funny) to see how fast these things end up public. Probably lots of default setups left running without realizing they’re wide open.
The article would actually be interesting if they tried either of those with the servers they found.
In that case, limiting the remote IPs would also be useful. I haven't played around with MCP, but it's on my todo list.