MCP servers power every AI agent you use. Nobody is checking if they're safe.
The Model Context Protocol ecosystem has exploded past 19,000 servers. Developers are plugging these into Claude, GPT, Copilot, and custom agents — giving them access to databases, file systems, APIs, and cloud infrastructure. One compromised MCP server means an attacker controls what your AI can see, do, and exfiltrate.
We decided to find out how bad it actually is.
The Problem Nobody Is Talking About
In March 2026, Microsoft patched CVE-2026-26118 — a server-side request forgery vulnerability in Azure MCP Server Tools rated 8.8 CVSS. An attacker who could interact with an MCP-backed agent could submit a malicious URL in place of a normal Azure resource identifier. The MCP server would send an outbound request to that URL, leaking its managed identity token. That is privilege escalation via your AI agent.
This was not a theoretical attack. Microsoft confirmed it and shipped an emergency patch.
Meanwhile, thousands of MCP servers are being deployed daily with zero security review. No CVE checks. No dependency audits. No maintenance verification. Developers search "MCP server for [X]," pick the first result, and plug it into their agent. That is the current state of MCP security.
What We Did
We built an automated scanner that indexes MCP servers from GitHub, major registries, and community directories. For each server, we evaluate:
- Known CVEs in the server and its dependency tree
- Maintenance status — when was it last updated? Are issues being addressed?
- License clarity — is the licensing unambiguous?
- Code quality signals — dependency hygiene, build configuration, test presence
- Language and framework — to cross-reference against known vulnerability classes
We indexed 5,618 servers across 15 categories and scored each one Green (safe to deploy), Yellow (needs review), or Red (known vulnerabilities).
The Numbers
Here is what 5,618 MCP servers look like under a security lens:
Security scores:
- 143 servers scored Green — verified safe, maintained, no known CVEs
- 5,067 servers scored Yellow — insufficient metadata, stale dependencies, or needs manual review
- 408 servers were unscored — too little public metadata to evaluate
That means 2.5% of MCP servers passed a basic security check. The rest are varying degrees of "we don't know."
Categories (top 5 by count):
| Category | Servers |
|---|---|
| AI / LLM | 1,186 |
| Code / Dev Tools | 612 |
| Memory / Knowledge | 414 |
| Data / Databases | 387 |
| Web / Browser | 352 |
Languages: Python dominates the ecosystem, followed by TypeScript, Go, and Rust. Python servers had the highest rate of dependency-related flags — unsurprising given the size of the average Python dependency tree and the frequency of CVEs in ML/AI libraries.
What We Found
Beyond the aggregate numbers, we went deeper. We manually triaged the most popular servers and submitted vulnerability reports for what we found. Here is what we can disclose:
FAISS — Arbitrary File Read/Write via Crafted Index Files
Facebook's FAISS library is the backbone of most vector search implementations. We found that crafted index files can trigger arbitrary file read and write operations on the host system. If your MCP server loads user-supplied or externally-sourced FAISS indexes, an attacker can read your environment variables, SSH keys, or write a reverse shell. Submitted to Huntr, currently in review.
TorchServe — SnakeYAML Remote Code Execution
TorchServe's YAML parsing uses SnakeYAML in a configuration that permits arbitrary object instantiation. An attacker who can supply a model configuration file gets full RCE on the inference server. Submitted to Huntr.
Ollama — Stored SSRF
Ollama's model management accepts URLs that are fetched server-side without adequate validation. A stored SSRF allows an attacker to probe internal network resources through the Ollama instance. Submitted to the Ollama security team.
Microsoft Azure MCP — SQL Injection (CVE-2026-26118)
Beyond the SSRF that Microsoft patched, we identified SQL injection vectors in the Azure MCP server's resource query interface. Submitted to MSRC, acknowledged, and in review.
The Pattern
Every vulnerability we found maps to a well-understood web security class: SSRF, path traversal, injection, unsafe deserialization. These are not novel AI attacks. They are 2010-era web vulnerabilities showing up in 2026 AI infrastructure because MCP server authors are systems engineers and ML engineers, not security engineers. The attack surface is familiar. The defenders are not.
Our scans flagged a 36.7% SSRF exposure rate across servers that accept external URLs — meaning more than a third of URL-accepting MCP servers do not validate or restrict outbound requests.
What Protodex Shows
We built protodex.io to make this data actionable. Every server in the directory carries a security badge:
- Green — no known CVEs, actively maintained, clear license, clean dependency tree
- Yellow — needs review; may have stale dependencies, unclear licensing, or insufficient metadata
- Red — known vulnerabilities; do not deploy without mitigation
The /security page explains exactly how scores are calculated. No black box. You can search servers by category, language, and security score. If you are building a RAG pipeline, an agent with tool access, or a database integration, you can filter to only Green-scored servers.
We also run a "What are you building?" recommendation engine that suggests verified server stacks for common use cases.
Why This Matters Now
MCP is not a niche protocol anymore. Anthropic, OpenAI, Microsoft, and Google all support it or are building toward it. Enterprise teams are deploying MCP servers in production pipelines that touch customer data, financial systems, and cloud infrastructure. Every MCP server is an attack surface that inherits the permissions of the AI agent calling it.
When your agent calls an MCP server to query a database, that server has database credentials. When it calls a server to read files, that server has filesystem access. When it calls a server to manage cloud resources, that server has cloud IAM tokens. A single SSRF in any of these servers means an attacker can pivot from "send a message to the AI" to "exfiltrate the database" in one hop.
The MCP specification does not mandate security reviews, dependency auditing, or vulnerability disclosure. There is no app store review process. There is no signing. A developer publishes a server to GitHub, someone lists it in a directory, and thousands of agents start calling it. The trust model is: "it's on GitHub, so it's probably fine."
It is not fine. Our data shows it is not fine.
What You Should Do
- Check your current MCP servers. Search for them on protodex.io and see their score. If you are using a Yellow-scored server in production, audit it manually or switch to a Green alternative.
- Pin your dependencies. MCP servers pull in large dependency trees. Pin versions and audit regularly. A single transitive dependency update can introduce a vulnerability.
- Never load untrusted index files. FAISS, ChromaDB, and other vector stores deserialize data. Treat index files like executables. If your pipeline ingests external embeddings, validate the source.
- Validate all URLs. If your MCP server fetches external resources, implement strict allowlists. Block private IP ranges (10.x, 172.16.x, 192.168.x). Block cloud metadata endpoints (169.254.169.254). This alone would have prevented CVE-2026-26118.
-
Monitor for CVEs. Subscribe to advisories for every library in your MCP server's dependency tree. Tools like
pip-audit,npm audit, and Snyk can automate this. -
Assume breach. Run MCP servers with minimum necessary permissions. If a server only needs to read from a database, do not give it write access. If it only needs one S3 bucket, do not give it
s3:*.
For Security Researchers
We are actively looking for security researchers to help audit MCP servers. If you find a vulnerability in a server listed on Protodex, report it through the standard channels (Huntr, vendor security teams) and let us know — we will update the server's score and credit you on the listing.
The MCP ecosystem is growing faster than anyone is auditing it. That gap is where the breaches will come from.
Check your MCP servers at protodex.io.
Top comments (0)