跳到正文
DEV Community· aisolutions323-ux·· 4 小時前AI 評分69

作者掃描 500 個高下載量 MCP 伺服器,發現只有 1 個現行版本仍受已知漏洞影響

What I found scanning the top 500 MCP servers for security

AI 導讀

作者以自建掃描器檢查 MCP Registry 下載量最高的 500 個伺服器,發現 OSV 列出的 112 項安全公告涉及 6 個伺服器,只有 1 個伺服器的現行版本仍在受影響範圍內。

正文

Every MCP server you add to Claude, Cursor or your own agent is code that runs on your machine. Usually that's npx something or uvx something, and it runs with your environment variables and API keys sitting right there. I wanted to know how worried I should actually be. So I built a small scanner, pointed it at the official MCP Registry, and checked the 500 most-downloaded servers.

This post covers what came back, how I scored it, and what I now check before installing a server. The data is from the scan on October 19, 2026.

The setup

The official registry (registry.modelcontextprotocol.io) listed 22,860 server entries when I scanned it. Of those, 6,557 ship an npm or PyPI package, which means I could look up download counts and match them against vulnerability databases. I ranked those by last-week downloads and kept the top 500.

For each one I collected:

  • Known advisories from OSV.dev, matched by package name, plus a check of whether the currently published version falls in the affected range.
  • Maintenance from GitHub: last push, archived status.
  • Transparency: whether it has a public repo and a detected license.
  • Metadata stability: nightly snapshots of the registry entry, diffed against the previous night's.
  • Adoption: weekly downloads from npm or PyPI.

The headline: it's mostly fine, and the risk is concentrated

Across all 500 servers, OSV returned 112 unique advisories. They hit only 6 servers. By severity, that's 30 critical, 65 high and 17 moderate.

The more useful number is how many servers are affected today. Of those 6, only one server's current version is still affected. The other five had real advisories in the past, and their maintainers shipped fixes. If you're on their latest version, those old advisories don't apply to you.

The one server still affected is PraisonAI (io.github.MervinPraison/praisonai). OSV lists 104 unique advisories against its package, and 80 of them include the current registry version (2.3.42) in their affected range. Fifteen advisories across the dataset were published this month, and all of them are PraisonAI's. Their summaries include an authentication bypass via a spoofed Host header and an unauthenticated jobs API that allows webhook SSRF. To be fair to the project: it's actively maintained (its last push was the day of the scan), it has a public MIT-licensed repo, and a high advisory count partly reflects how much attention it gets. But if you run it, check the advisories against your version and setup first.

The five servers whose current versions are clean are stata-mcp, Ouroboros, browser-use, Excel MCP Server and Windows-MCP. They're the normal case: something got reported and something got fixed. browser-use, for example, has one advisory: a critical allowed_domains bypass (CVE-2025-47241). It's already fixed in the current version.

Scores across the board

Each server gets a 0–100 score. The weights are deliberately simple:

Factor Max points
Known advisories (OSV) 40
Maintenance (GitHub activity) 20
Source transparency (repo + license) 15
Metadata stability (registry diffs) 15
Adoption (weekly downloads) 10

An advisory that affects the current version costs 20 points. A historical one costs 2 points, and historical penalties stop at 8 points total. If I don't have data for a factor, I leave it out instead of guessing, and the server page says it's unknown.

For the 500 servers, the median score is 93 and the mean is 92. 477 land in the "strong" band (85–100), 22 are "good" (70–84), 1 is "fair" (50–69), and none are poor. The single "fair" one is PraisonAI, at 56.

The less obvious findings came from the other factors:

  • 37 servers have a GitHub repo with no detected license, and another 18 have no repo linked at all. If you can't read the source, you're trusting the package blindly.
  • 2 repos are archived, and 1 hasn't been pushed in over a year. 472 were pushed in the last 90 days, so the ecosystem is very active.

Why I only alert on changes that matter

Vulnerability databases only tell you about known bugs. What worries me more with MCP is the rug pull: a server that was fine when you installed it quietly changes what it runs.

So every night the scanner snapshots the registry metadata a client sees and diffs it. A change only counts as a risky alert if it changes what code runs or where your data goes:

  • a new or changed remote host
  • a new package identifier or registry type, or a different Docker image repo
  • a changed runtime command, or new arguments that execute code or redirect package sources
  • a new or removed required secret env var (or something like NODE_OPTIONS)

Version bumps, description edits, tracking parameters and trailing slashes are recorded in each server's timeline but don't alert. I tried alerting on everything early on, and it was all noise.

The first nights produced exactly 2 alerts, both for the same server. Its repo got archived, and its score dropped from 93 to 73 as a result. That's about the volume I'd want: rare, and worth reading.

What I check now before installing an MCP server

  1. Check advisories against the version you'll actually run. A long history isn't the problem; an open advisory on your version is. Pin versions in your client config (npx pkg@1.2.3, not pkg@latest).
  2. Look at the command, not just the name. An npx/uvx line downloads and runs code with your environment. Read the args and env in the config snippet.
  3. Be stingy with secrets. If a server asks for a token, scope it down (read-only, single repo or project). Be suspicious when a new required secret appears after an update.
  4. Prefer a public repo with a license. It's not a guarantee, but it means someone can look.
  5. Check if it's maintained. An archived repo means no one will fix the next bug.
  6. Remote servers: know the host. If the URL changes domain, treat it as a new server.
  7. Watch for changes after install, not just at install time. That's the part people skip.

Caveats

This is a heuristic, not an audit. OSV matching is by package name, and the scanner doesn't read code, so a clean result doesn't prove a server is safe. The registry doesn't publish tool lists yet, so tool-level changes show as unknown for now.

Try it

Everything is public and free at MCPWatch:

  • Per-server pages with the score breakdown and change timeline
  • Alerts feed and RSS at /alerts.xml
  • A README badge for maintainers: https://mcpwatch-zeta.vercel.app/badge/<id>.svg
  • The full rule set at /about/methodology
  • A weekly digest of real changes: /newsletter/

If you maintain one of these servers and something looks wrong, tell me. I'd rather fix the data than defend it.

來源:DEV Community · dev.to