Three weeks ago I published a single-night scan of the top 500 MCP servers. Then I left the scanner running: every night it re-ranks the official MCP Registry by last-week downloads, re-checks OSV, and diffs against the night before.
This is what changed between October 20 and November 9, 2026 — and why an advisory "appearing" or "disappearing" on a tracker is usually not what it sounds like.
The headline, then the asterisk
| Oct 20 | Nov 9 | |
|---|---|---|
| Unique OSV records in the top 500 | 222 | 11 |
| Distinct vulnerabilities (aliases merged) | — | 7 |
| Servers with any advisory | 6 | 4 |
| Servers whose current version is still affected | 1 | 0 |
| Median score | 93 | 93 |
| Mean score | 92.4 | 89.6 |
If you only look at the left column of that table, it looks like a security miracle. It isn't. Almost none of those advisories were withdrawn, and almost none of the packages "healed" overnight. What moved was the set of servers I track.
Why 200+ advisories left the board
On October 20, one server accounted for nearly all of the noise: PraisonAI (io.github.MervinPraison/praisonai). It had 207 OSV records, 159 of which still matched its then-current version (2.3.42), on 2,722 weekly downloads — enough for the top 500.
By the October 31 scan it was gone. The 500th server that night had only 78 weekly downloads. PraisonAI didn't get a mass fix; it fell below the cutoff. When a package leaves the tracked set, every advisory leaves with it. That's how 222 records became 4 overnight, and how "servers currently affected" went from 1 to 0.
The same thing happened, smaller, to Ouroboros, Windows-MCP and stata-mcp — historical advisories only. They rotated out on download rank. Nothing was withdrawn; they left scope.
Advisories that flicker in and out
Once you start watching nightly, you see the same IDs come and go with the ranking. Three examples I verified against OSV:
GHSA-j98m-w3xp-9f56 / PYSEC-2026-331 — excel-mcp-server
A path traversal in PyPI excel-mcp-server (CVE-2026-40576). OSV: introduced in 0, fixed in 0.1.8.
On October 20 the registry listed 2.2.1, so it already didn't affect the current version. The server then dropped out of the top 500 (Oct 24–28), reappeared Oct 30 at 2.2.3, vanished on the 31st, and is back today at 2.2.9. The advisory didn't toggle — weekly downloads did (~91k → ~33k → ~45k), enough to cross a cutoff this dense at the long tail.
GHSA-fvh2-gm75-j4j7 — dynoxide
DNS rebinding / cross-origin CSRF via dynoxide's MCP HTTP transport (CVE-2026-42559). OSV: npm dynoxide from 0.9.3, fixed in 0.9.13.
Absent on October 20. It showed up on November 9 when dynoxide entered the top 500 at 1.6.0 (~20k weekly downloads) — well past the fix. From the tracker it "appeared." From the package, the bug was fixed months ago.
ha-mcp's four moderate findings
io.github.homeassistant-ai/ha-mcp entered the set on October 29 and is in today's scan at 9.1.2. It brings four distinct issues (six OSV records once you count the PYSEC mirrors):
-
GHSA-fmfg-9g7c-3vq7/PYSEC-2026-2507— OAuth DCR error-oracle recon, fixed in 7.0.0 -
GHSA-pf93-j98v-25pv/PYSEC-2026-2508— XSS in the OAuth consent form, fixed in 7.0.0 -
GHSA-g39v-cvjh-8fpf— YAML config backups served unauthenticated under/local/, fixed in 7.5.0 -
GHSA-q855-8rh5-jfgq— unauthenticated add-on settings at the bare root path, fixed in 7.10.0
None of them hit 9.1.2. Same pattern: the package crossed into the top 500; the historical record came with it.
What the rest of the board looks like today
After merging aliases, today's top 500 carries 7 distinct vulnerabilities across 4 servers. Severity, from the GHSA side: 2 critical, 1 high, 4 moderate. Zero affect the version currently published in the registry. The critical pair is the familiar browser-use allowed_domains bypass (GHSA-x39x-9qw5-ghrf / CVE-2025-47241, fixed in 0.1.45, current 0.13.11) and the excel path traversal above.
No new OSV advisory published this month matched a tracked package. The "new" rows on the board are new membership, not new CVEs.
The top 500 itself is restless
Between October 20 and November 9, only 122 of 500 servers stayed; 378 left and 378 entered. Dramatic until you see the floor: the 500th server sometimes has under 100 weekly downloads, and the npm/PyPI candidate pool swung from ~6,800 to ~4,200 as the registry churned.
Mean score dipped 92.4 → 89.6; median held at 93. Almost entirely compositional — new entrants skew toward missing licenses and older last-pushes, not open advisories. Of the 122 that stayed, 37 changed score, mostly ±3. The "strong" band (85–100) went 475 → 398; "fair" went from 1 (PraisonAI) to 0.
Risky-change alerts stayed quiet: still just the October 18 archived-repo pair. Version bumps and description edits land in each timeline; they don't page anyone.
What I'd actually do with this
-
Treat "advisory appeared on the tracker" as a prompt, not a verdict. Check the affected range against the version you run.
excel-mcp-server@2.2.9anddynoxide@1.6.0are both clean relative to their listed fixes. -
Pin versions.
npx pkg@1.2.3/uvx pkg==1.2.3, not@latest. Ranking churn and version churn are different problems; pinning only solves the second, but it's the one that decides whether an old advisory applies to you. - Don't over-read a high historical count. A package with fixed advisories was looked at. A package with zero advisories might be safe, or it might just not have been looked at.
- Watch the package after install. The thing that still worries me more than old CVEs is a quiet change to the command, host, or required secrets. That's what the nightly diff is for.
Caveats
Still a heuristic: OSV matched by package name, no source review, a clean result is not an audit. The top-500 cut is last-week downloads, so the long tail is noisy by design. "11 records / 7 vulnerabilities" is GHSA and PYSEC describing the same CVEs.
Keep watching with me
Live board: MCPWatch — scores, timelines, alert feed. For nights when something actually moved, the weekly digest.
If you maintain one of these and a row looks wrong, tell me. Ranking churn is expected; bad data isn't.
Top comments (0)