MCP Ecosystem Report · May 25, 2026

1in3

MCP servers in the wild run with known CVEs in their production dependencies.

How we measured this →Free tools below ↓

14,762

MCP servers scanned

Across npm, official, Smithery, mcp.so, PulseMCP, Glama

37%

5,522 have a CVE finding

At least one known vulnerability in production deps

33%

4,825 run a CVE-laden SDK

Pinned to a vulnerable version of @modelcontextprotocol/sdk

The single largest source of MCP ecosystem CVEs is the official SDK itself.

Most CVEs were disclosed after publishers pinned to a version. The fix is a one-line dep bump — but nobody's been notifying publishers.

@modelcontextprotocol/sdk

Top affected SDK versions

1.0.0
1,810
1.12.1
895
1.0.4
598
1.12.0
572
0.6.0
380
0.5.0
358
1.7.0
316
1.8.0
309

Free tools

Three free tools — pick yours

All free. No signup. Built for the three audiences this report reaches.

I built an MCP

Pre-flight your server in 15 seconds. CVE status, OAuth correctness, tool annotations, submission-readiness.

Run pre-flight

I want to connect to one

Paste any GitHub URL or npm name. See the trust score, top findings, and verdict before connecting.

Check an MCP

I want to browse

Walk through all 14,762 scored MCPs. Filter by registry, trust grade, or popularity.

Browse the index

For the curious

How we measured this

What does the corpus include?+

14,762 canonical MCP servers indexed from six registries (npm, the official Anthropic registry, Smithery, mcp.so, PulseMCP, Glama). Deduplicated by GitHub URL or npm package name so the same MCP listed in multiple registries counts once. Filter applied: tool_extraction_status is either ‘found’ or ‘pattern_unmatched’, current grade A–F, public GitHub URL. Same denominator we publish on /verified and the home page.

How do you detect CVEs?+

For each MCP we clone the public source and parse package.json declared dependencies. Each package@version is queried against OSV.dev — the public open-source vulnerability database that backs npm audit, GitHub Dependabot, Google's scanners, and most enterprise security tools. A “CVE finding” means at least one declared dependency has a published advisory with severity high or critical.

Can I verify the SDK CVEs myself?+

Yes — two specific advisories anyone can confirm directly via OSV.dev or github.com/advisories:

Important caveat: do you check lockfiles?+

No — we check declared dependency versions in package.json, not resolved versions in package-lock.json. Some MCPs with caret-range declarations (e.g. "^1.12.1") install a patched newer version at npm install time even though the declared minimum is vulnerable. Our 4,825 count is therefore “MCPs whose declared SDK version has a published CVE” — not “MCPs that are necessarily exploitable today.” Lockfile-aware counting is on our roadmap.

Severity vs. actual exploitability?+

A “high severity” CVE in a transitive dependency doesn't mean the MCP exposes the affected code path. Our scan is conservative — every version match is flagged. Real-world risk requires deeper taint analysis we don't do at scale.

When was this snapshot taken?+

May 25, 2026. The numbers on this page are frozen as of that scan — published as a citable artifact rather than a live dashboard. Continuous re-scans pick up new CVE disclosures and dep bumps daily, so current-state counts have already drifted. Trend data lives in our internal monthly snapshots and will surface in the quarterly State of MCP Trust reports.

For the full trust-scoring methodology (the four layers of analysis, what we check, and what we can't detect), see /verified/verify/methodology.