How exposed are MCP servers, really? What the 2025-2026 scans found.

There is a gap between how MCP server risk gets discussed and what independent scans actually measured. The discussion leans toward exotic attacks: tool poisoning, prompt injection through descriptions, cross server confusion. The measurements point somewhere more boring and more urgent. When several teams pointed scanners at real servers in 2025 and 2026, the same finding came back each time. Most servers are not being subverted by clever inputs. They are wide open because nobody put an authorization layer in front of them.

This is a meta-analysis, not a new scan. It reads across six public studies with different samples and methods, then asks what they agree on.

How many servers ship without authentication?

Start with the credential picture. Astrix, in its State of MCP Server Security 2025, scanned 5,205 repositories. Only 8.5% used OAuth. 53% relied on static API keys, and 79% passed those keys through environment variables. That last number matters because environment variables leak into logs, crash dumps, and child processes without anyone deciding they should.

Then look at what is reachable from the open internet. Trend Micro found 492 MCP servers exposed with zero authentication, collectively exposing 1,402 tools, and reported that over 90% allowed direct read access. Knostic mapped 1,862 internet exposed servers and sampled 119 of them. All 119 had no authentication. Not most. Not a worrying majority. Every single sampled server.

Are the vulnerabilities exotic or ordinary?

Vulnerabilities beyond missing auth do exist, and it helps to size them honestly. Enkrypt AI scanned 1,000 servers. Around 32% had at least one critical vulnerability, and the average server carried 5.2 vulnerabilities. That is a real backlog, but the shape is familiar to anyone who has run a web application scan: many servers, ordinary flaws, no authorization boundary containing them.

The average of 5.2 issues per server tells you these are not one off mistakes by careless authors. They are systemic defaults. When a whole ecosystem ships with the same gaps, the problem is the pattern the ecosystem copied, not the individual maintainers.

What about tool poisoning?

Tool poisoning is the attack that gets the most attention, so it deserves careful numbers. MCPTox tested 45 real MCP servers covering 353 tools across 1,312 test cases. Against the strongest target, o1-mini, the attack success rate reached 72.8%, and refusal rates stayed under 3%. So when a model is fed a poisoned tool description, it very often complies. That is a genuine finding and worth defending against.

But how common is poisoning in the wild? Here you have to read the study carefully. MCP at First Glance studied 1,899 servers and reported that 5.5% showed tool poisoning. That 5.5% is easy to misquote. It is not 5.5% of all 1,899 servers. It is 5.5% of a 73 server subset that received dynamic analysis. The large denominator makes the number sound like a population estimate. It is a slice of a slice.

Poisoning is potent when it lands, but the scans do not show it as the common case. The common case is a server anyone can reach with credentials that let them read whatever they want.

The order of operations matters. A poisoned tool description is dangerous because it steers an agent that already has access. Remove the missing authentication problem and you shrink the blast radius of the poisoning problem at the same time. The reverse is not true. Perfect poisoning detection on a server with no auth still leaves the server open.

Does our own monitoring agree?

Our data points the same way. Oktsec monitors more than 58,000 published skills and MCP servers, and the recurring finding is absent authorization and missing provenance, not exotic exploits. It is the same signal the external scans report, from a different vantage point and a much larger sample. When six studies with different methods and one continuous monitor all land on the same conclusion, the conclusion is not a sampling artifact. It is the state of the ecosystem.

None of this is a knock on MCP as a protocol. It is what an ecosystem looks like in its first eighteen months, before secure defaults become the norm. Package registries went through the same phase. The useful move is to name the dominant failure precisely so the fix targets it.

What follows from this?

If the dominant failure across every independent scan is missing authentication and over-broad credentials, then the fix is authorization, not more detection. Detection matters, and tool poisoning is worth catching. But you cannot detect your way out of a server that anyone can reach with a static key that reads everything. The controls that address what these scans actually found are the unglamorous ones: require authentication at the connection, scope credentials to the minimum the tool needs, keep secrets out of environment variables, and put a policy layer between an agent and the tools it can call.

For the mechanics of why an MCP server exposes more than its tool list suggests, see what an MCP server actually exposes. For why we keep returning to authorization over detection, see detection versus authorization. And for where servers sit in the wider set of artifacts an agent pulls in, see the agent supply chain.

Oktsec grades MCP servers on what they expose and what stands in front of them, so the missing authorization these scans keep finding shows up before an agent connects. See Signal →