DEV Community: aisolutions323-ux

Three weeks of watching MCP advisories appear and disappear

aisolutions323-ux — Mon, 09 Nov 2026 12:30:33 +0000

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.9 and dynoxide@1.6.0 are 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.

What I found scanning the top 500 MCP servers for security

aisolutions323-ux — Wed, 21 Oct 2026 00:24:40 +0000

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

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).
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.
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.
Prefer a public repo with a license. It's not a guarantee, but it means someone can look.
Check if it's maintained. An archived repo means no one will fix the next bug.
Remote servers: know the host. If the URL changes domain, treat it as a new server.
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: aisolutions323-ux

Three weeks of watching MCP advisories appear and disappear

The headline, then the asterisk

Why 200+ advisories left the board

Advisories that flicker in and out

GHSA-j98m-w3xp-9f56 / PYSEC-2026-331 — excel-mcp-server

GHSA-fvh2-gm75-j4j7 — dynoxide

ha-mcp's four moderate findings

What the rest of the board looks like today

The top 500 itself is restless

What I'd actually do with this

Caveats

Keep watching with me

What I found scanning the top 500 MCP servers for security

The setup

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

Scores across the board

Why I only alert on changes that matter

What I check now before installing an MCP server

Caveats

Try it

`GHSA-j98m-w3xp-9f56` / `PYSEC-2026-331` — excel-mcp-server

`GHSA-fvh2-gm75-j4j7` — dynoxide