State of MCP server security, November 2026

We looked at every active entry in the official MCP Registry on 5 November 2026, using public data only. Each finding gives the count with its base, what it means, and what to do about it.

19,765 of 55,934 active entries (35.3%) can be checked for known advisories. OSV tracks advisories by package and version, for ecosystems such as npm and PyPI. The other 36,164 (64.7%) can't be checked that way. They aren't shown to be safe or unsafe. We just can't say.

The 36,164 that can't be checked break down like this:

• 33,297 are remote endpoints only. You connect to a URL that someone else runs, and there's no package for anyone to look up.
• 2,214 ship only as a container image or an mcpb bundle. OSV doesn't track these by version.
• 653 list no package type and no remote at all.

A further 5 entries pin a tag such as latest instead of a version, so OSV can't check those either. We left them out of the checkable base.

For 18,188 entries there's nothing to match on at all: no OSV-covered package and no GitHub repo. The rest of the 36,164 have a GitHub repo, which can only link them to a CVE that cites that repo.

What this means: most of the registry is hosted services and images, not packages. The advisory databases were built for packages. Until a remote server publishes its security record somewhere checkable, a clean scan tells you very little about it.

Registry-listed version has a known advisory: 9 of 19,765 entries (0.05%). That's low partly because only the checkable entries are in the base, and partly because OSV covers the package itself, not its dependencies.

"Registry-listed" matters. For only 3 of the 9 is the listed version also the package's newest release. In the others, the package has moved on while the registry still lists the affected version. One of the 9 is a malware flag rather than a flaw: that version was removed from npm, and the registry record still lists it. We can't tell why it was flagged or who was behind it.

We read all 9 by hand against the advisory text, and 8 hold as written. In the other one, the advisory covers the package version pinned in the registry record, not the server version the record shows. We ran no exploits, so this doesn't prove each flaw can be exploited. We didn't check the other 19,756 entries one by one, so 9 may not be complete.

We don't name the 9 entries or any publisher here. This report is about the registry, not about individual maintainers.

What this means: the registry record and the package can drift apart. A client that installs the version the registry lists can get an older, affected release even when a fixed one exists.

19,146 of 55,934 entries (34.2%) have no source link. 17,915 of those are remote-only, and some are hosted products that were never going to publish source. So this is a limit on checking, not proof of neglect.

3,965 of 29,540 linked GitHub repos (13.4%) don't resolve, and 4,800 registry entries link to one of them. A deleted repo, a private repo and a renamed repo whose redirect has gone all return the same 404, so we can't tell you which is which. We retested a random 50 without logging in, and 50 of them still returned 404. We don't list these repos, because a list of dead names could help someone take over a name.

Entries aren't projects. The 4 largest publishers account for 6,476 entries (11.6%), and one repo backs 2,356 entries on its own. That's why we count repos once each in the next section.

What this means: for 23,946 of 55,934 entries (42.8%) you can't read the code behind them, because there's no link or the link is dead. A dead link is also a risk on its own: if the old name can be registered again, the link could one day point at someone else's code.

• Security policy: 17,399 of 25,575 reachable repos (68%) have none, and 22,720 entries link to those repos. This shows that a policy exists, not that anyone answers it. Organisation-level policies count.
• Stale repos: 1,957 of 25,575 (7.7%). That's lower than many people assume. Stale means no push for 180 days, or archived (228 are archived). A push to any branch counts.
• Plain http: 0 of 37,722 listed remote endpoints use plain http on a public host. We read the URLs as published and didn't connect to them.

What this means: the basics of hosting look fine: remotes use https, and most repos are still alive. What's missing is process. Two in three repos publish no security policy, so someone who finds a flaw may not know how to report it privately.

CVEs mentioning MCP not matched to a registry entry by repo: 273 of 331, published 8 Jul 2026 to 5 Nov 2026.

This is not a coverage number. It doesn't mean that this share of MCP flaws sits outside the registry. Many are in SDKs and apps rather than listed servers, and some listed servers have no repo link to match on. CVEs also cluster: 10 of the sample below are one product, so a share of CVEs isn't a share of products.

We sampled 60 at random and read each one. 54 are really about MCP, 1 is borderline, and 5 only mention it. The sample came from our rebuild of the list from public NVD data, which found 271 unmatched where our scan found 273.

What this means: a server can be fine on its own and still inherit a flaw from the SDK it's built on or the app that hosts it. Those advisories never show up against a registry entry.

Besides the registry-wide checks, we grade selected servers by hand on four checks worth 100 points: authentication (30), maintenance (25), known CVEs (25) and transport safety (20). The grade is the total: A is 85 or more, B 70 to 84, C 50 to 69, D under 50. It's our editorial opinion from public signals. We picked these servers ourselves, mostly popular and vendor-backed ones, so they're not a sample of the registry. Our own MCP server is left out of every count here.

• Snapshot (5 Nov): 31 A, 27 B, 19 C and 5 D, of 82. Sign-in on by default for 55, optional for 12, none for 15. 3 had a known CVE on record.
• Sign-in (30 points): 150 of 207 listings (72.5%) lack full sign-in marks. Only 57 have scoped, revocable sign-in on by default. All 72 A grades have some sign-in, and none of the 35 listings with no sign-in grades above C (27 C, 8 D).
• Maintenance (25 points): the next weakest check, with 67 of 207 at full marks. 90 of 207 are active but rest on a single maintainer, which costs part of the marks.
• Known CVEs (25 points): the strongest check, with 196 of 207 at full marks. 7 have a known CVE on record: 2 B, 2 C, 3 D, no A. A CVE costs most when it stays open with no fix or mitigation.
• Transport safety (20 points): 134 of 207 at full marks.

What this means: the servers people pick first are mostly active (169 of 207), and few carry CVEs. Where they fall short is how you sign in: many rely on one broad API key, on sign-in that's off by default, or on no sign-in at all. Whoever holds a broad key gets everything it can reach.

Each listing's page explains its grade and its biggest gap. Browse them in the MCP server directory, or read how we grade MCP servers.

The headline numbers come from the 5 November snapshot, because that's the run we checked by hand. To see whether they still hold, we read two newer sources. Here is exactly what was re-run:

• Re-run in full on 11 November: every registry check in the table below, with the same code as the snapshot.
• Read from our live registry mirror on 15 November: entry counts, the can't-be-checked split and source links only.
• Not repeated: the hand check. The newer figures haven't been read by a person.

The registry grew by a net 6,744 active entries in 10 days, about 674 a day, from 55,934 to 62,678. The number of entries that can't be checked rose by a net 4,800, to 40,964: 37,930 remote-only, 2,358 images or bundles, and 676 that list neither. That net rise is a different figure from the 4,800 entries that link to a dead repo; the two happen to match.

New advisories: our nightly scan, to 14 November, found 32 advisory records published since 5 November (31 distinct once aliases are merged): 30 from NVD and 2 from OSV. 14 matched 3 registry entries by package or repo. 18 matched no entry. None hit a server we grade. Neither OSV advisory affects the version the registry lists. NVD gives no reliable version for registry entries, so we can't say that for the NVD matches.

What this means: 10 days is short, but nothing moved the main figures. If anything, the gap is widening: about 7 in 10 of the net new entries (71.2%) can't be checked, more than the 64.7% at the snapshot. Most of them are remote-only.

If your team is adopting MCP servers

• For a remote-only server, read "no known advisories" as "unknown", unless you have other evidence. Ask the vendor who to contact about security, and how they sign you in.
• Open the source link before you install. If it's missing or dead, ask why.
• Compare the version a registry lists with the package's newest release. They can differ, and pin the one you checked.
• Prefer scoped, revocable sign-in over one broad API key. It's the check our graded listings fail most.
• Watch advisories for your MCP SDK and client as well as the server, and re-check every month.
• Our MCP server security checklist covers the rest, how to check an MCP Registry entry walks through one, and the MCP Registry watch list shows what our scan finds for each entry.

If you maintain an MCP server

• Add a security policy, or turn on private vulnerability reporting on GitHub, so people can tell you about a flaw privately.
• Publish a new registry version when you release, so the registry doesn't keep listing an old, affected version.
• Link your source repo in the registry record, and update the link if you rename or move the repo.
• If you run a remote-only server, say publicly where security fixes are announced. Nobody can look you up in OSV.

If you build a registry or an MCP client

• Show "can't be checked" as its own state. Don't show it as a clean result.
• Flag entries whose listed version trails the package's newest release, and entries whose source link no longer resolves.
• Surface known advisories at install time, from OSV for packages and from the publisher for remote servers.

• Official MCP Registry: 55,934 active entries, as mirrored on the snapshot date. Deleted and deprecated entries are left out.
• OSV (which includes GitHub Security Advisories): advisories for each npm, PyPI, NuGet or cargo package, at the version the registry record pins.
• NVD: CVEs that mention MCP, over 120 days, matched to an entry only when a CVE reference cites the entry's GitHub repo.
• GitHub API: last push, archived status and security policy for each of 29,540 distinct repos. Monorepos back many entries, so each repo counts once.
• Hand check: we read every entry flagged with an affected version against the advisory text, retested a random 50 dead repos without logging in, and read a random 60 of the unmatched CVEs.
• Our grades: four checks, authentication (30 points), maintenance (25), known CVEs (25) and transport safety (20), scored from each server's public repo, docs and advisories, and re-scored when something changes. The grade is our opinion, from public signals.
• Since the snapshot: the 11 Nov re-run is the same command on newer data. The 15 Nov figures are read-only counts from our registry mirror, our nightly advisory scan and our listings, with the queries listed in the data download.

Everything comes from public data. We didn't install or run any server, and we didn't connect to any endpoint.

What this doesn't measure

• This isn't an audit. It's a signal from public data, from one snapshot.
• Dependencies: OSV was asked about each package itself, not what it depends on.
• Anything outside the official registry: other directories, and servers listed nowhere.
• Authentication across the registry: stdio servers can't be observed, and probing remote ones would be active scanning.
• Unpinned versions: pinning is set in each client's config, and we don't have that data.
• Broad permissions: we have no tool or scope data.
• Injection and path-traversal rates: these need code analysis. We don't present other people's figures as our findings.
• CVE matching by repo: a CVE that doesn't cite a repo can't be tied to an entry, so some matches are missed.
• Our graded listings: we chose them, so they don't stand for the registry as a whole.

The data behind the November 2026 report, as CSV and JSON, under CC BY 4.0. Start with README.md. No file names a registry entry, a publisher or a dead repo; editorial.csv names only the servers we grade, which are public on their own pages.

How to cite this report

TrustedMCP. "State of MCP server security, November 2026." Registry snapshot 5 November 2026, published 15 November 2026. https://trustedmcp.io/reports/2026-11. Data under CC BY 4.0.

Quote a figure with its base, for example "19,765 of 55,934 entries can be checked" or "36,164 of 55,934 can't, 33,297 of them remote-only", and link back to this page so readers can see the method and limits. The newest edition is always at trustedmcp.io/mcp-security-report.

Found a mistake?

Tell us and we'll correct it. That goes for maintainers who dispute anything here, too: contact us. We'll note every correction on this page. To hear about the next report, sign up below. Every month's report stays online at State of MCP server security reports.

We build MCP servers for clients. If you want one built, or your own server reviewed against these checks, get in touch.