We scanned 8,400+ MCP servers for security issues -- here's what we found

[AgentSeal]

Pre-submission Checklist

• This post follows the MCP community guidelines

What would you like to share?

We built https://agentseal.org, an open-source security scanner for MCP servers, and ran it against every public MCP server we could find. Some stats from the registry:

• 8,400+ servers analyzed with static + LLM-powered analysis
• 87 security issues filed on GitHub repos (including GitHub's own MCP server, AWS AgentCore, Daytona, Chrome DevTools)
• 5 maintainers shipped fixes within days of our reports
• Common findings: missing input validation, annotation mismatches (readOnlyHint on mutating tools), command injection via unsanitized args, unauthenticated WebSocket endpoints

The full registry is browsable at https://agentseal.org -- every server gets a trust score with detailed findings breakdown.

CLI tools (OSS):

• scan-mcp -- scan any MCP server config (stdio or SSE)
• scan-repo -- scan a GitHub repo for MCP security issues
• guard -- runtime protection layer for MCP connections

Happy to answer questions about MCP security patterns we've seen across the ecosystem.

Relevant Links

GitHub: https://github.com/agentseal
PyPI: pip install agentseal | npm: npm install agentseal
We also published a https://agentseal.org/blog on exploiting 6 MCP servers (68K combined GitHub stars) with working PoCs.

[armorer-labs]

This kind of scan is really valuable because the ecosystem needs empirical baselines, not only theoretical best practices. One thing I would love to see in results like this is a split between findings that are primarily capability/auth issues and findings that are primarily context-trust / prompt-injection issues.\n\nThey often get bundled together as "MCP security," but they fail in different ways:\n- over-broad tool exposure or weak auth\n- unsafe handling of tool output / retrieved text / instruction-bearing metadata\n- dangerous default actions without approval boundaries\n- audit gaps where it is hard to reconstruct what actually happened\n\nIf you have enough signal in the data, a breakdown by surface would be incredibly useful for builders deciding where to spend effort first.

[mcpsafe-gh]

Valuable dataset — the breadth here (8,400+ servers) is really useful for understanding ecosystem-wide patterns.

Echoing @armorer-labs' point on the capability/auth vs context-trust distinction: the annotation mismatch category (readOnlyHint mismatches) is particularly insidious because it creates silent privilege escalation paths. We found an instance in GitHub's official MCP server where dynamic toolset mode combined with a readOnlyHint:true annotation on a mutating tool creates an exploitable chain — reported under coordinated disclosure.

The indirect prompt injection pattern is where the highest real-world impact concentrates. Servers that fetch Jira tickets, Confluence pages, GitHub issue bodies, or web content and return them verbatim to the LLM context are effectively granting write access to anyone who can write to those content sources. We found this in Atlassian's official MCP (AIVSS 6.0/7.1), GitHub's MCP, and others — all disclosed under coordinated 30-day policy.

The architectural root cause: MCP has no provenance delimiters for tool output. The LLM cannot structurally distinguish operator instructions from attacker-controlled data returned by a tool. Patches on individual servers help but don't solve the protocol-level gap.

For deeper per-server analysis (vs breadth scanning), MCPSafe (mcpsafe.io) uses a 5-model LLM judge consensus panel and purpose-built AIVSS scoring to produce graded reports with specific finding paths. Different methodology — breadth registry scanning tells you ecosystem state, deep per-repo analysis tells you the specific exploitable paths. Both are needed.