Public MCP studies document several risks: internet exposure without authentication, credential handling, software vulnerabilities and tool poisoning. Their samples and methods differ. This review distinguishes deployment scans from repository analysis and controlled attack benchmarks; none alone measures the security of the entire MCP ecosystem.
This is a reading across studies, not a new scan. It takes six public studies with different samples and methods, then asks what they agree on.
Servers 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 can be inherited by child processes or exposed through logs and crash dumps. Whether they leak depends on the application and operating controls.
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. How many had no authentication? All 119.
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. Those are scanner-reported findings that need validation against the affected versions and deployment conditions.
The reported average describes Enkrypt’s scanned sample and its scanner’s findings. It does not by itself establish a systemic default across all MCP servers or show that every finding is exploitable. Reproduce relevant findings before prioritizing remediation.
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. For o1-mini, the highest reported target result, the attack success rate reached 72.8%, and refusal rates stayed under 3%. That result shows the impact of poisoned metadata on the tested model and harness; it does not give a failure rate for models in general.
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. The MCP specific scan in the paper, run with mcp-scan, covered 73 servers, and the paper does not state which denominator the 5.5% is measured against. The 1,899 headline makes the number sound like a population estimate. Treat it as a slice of a slice.
MCPTox measures attack success under controlled conditions. It cannot be used to estimate how often deployed servers are poisoned. Likewise, unauthenticated-server scans do not show that tool poisoning is rare; the studies measure different things.
Require authentication for protected server access and constrain credentials. An authenticated agent can still consume a poisoned tool description, so identity checks do not replace tool-content review, permission limits or execution isolation.
What can these studies establish?
Oktsec Signal reviews MCP servers, skills and packages. We are not presenting a new Signal dataset or population estimate here. The conclusions in this article are limited to the cited studies and their disclosed samples.
When reviewing a server, separate reachable deployment configuration from package capabilities and demonstrated exploits. Record the version and environment so a finding can be reproduced.
What this means for defenders
For a deployed MCP server, first verify network reachability, authentication and least privilege. Then test known vulnerabilities and hostile tool content. Store secrets using the controls appropriate to the environment, limit inheritance into child processes and avoid logging them. Add explicit tool and parameter policies where supported, and test paths that bypass those policies.
For the mechanics of why an MCP server exposes more than its tool list suggests, see what an MCP server actually exposes. For how authorization and detection complement each other, see detection versus authorization. And for where servers sit in the wider set of artifacts an agent pulls in, see the agent supply chain.