Safety checks from the run of 14 October 2026, everything else as of 15 October 2026.
The short version
- 18 of 65 popular MCP servers and agent skills pass every check that applies to them.
- The most common gaps: no private way to report a vulnerability (19 of 65) and high-severity advisories in dependencies (18 of the 36 projects the check applies to).
- 56 of 63 pass the four checks for the patterns behind recent incidents. All 7 fails are the same one: a shell command built from input, or a URL opened without checking it, in half of the 14 MCP servers.
- Two of the 88 MCP servers and skills on our lists that we have dates for went 6 months without a commit or a release.
- We recorded no license changes on either list since we started recording licenses on 13 October 2026.
- CVEs that name an “MCP server” went from 4 in the second quarter of 2025 to 120 in the third quarter of 2026.
Why look at this now
When you add an MCP server or a skill, your coding agent loads code and text someone else wrote and acts on it. Three incidents since July 2025:
- postmark-mcp, September 2025. A copy of a real email server on npm added one line in version 1.0.16 that sent a blind copy of every email to an outside address. Koi Security called it the first malicious MCP server they had seen in the wild.
- CVE-2025-6514, July 2025. mcp-remote, a widely used bridge to remote MCP servers, passed a URL from the server straight to the system’s “open” call. A malicious server could run commands on the user’s machine. CVSS 9.6, fixed in 0.1.16.
- ClawHavoc on ClawHub, February 2026. Koi read all 2,857 skills on ClawHub and found 341 malicious ones. Most had a “prerequisites” step that asked the user to download a password-protected zip or paste a script into a terminal.
How many CVEs name an MCP server?
The National Vulnerability Database had 120 CVEs published in the third quarter of 2026 whose text contains the phrase “MCP server”, up from 61 the quarter before and 4 in the second quarter of 2025.
| Quarter | CVEs |
|---|---|
| Q1 2025 | 0 |
| Q2 2025 | 4 |
| Q3 2025 | 25 |
| Q4 2025 | 16 |
| Q1 2026 | 27 |
| Q2 2026 | 61 |
| Q3 2026 | 120 |
| Q4 2026, 1 to 15 October | 13 |
A keyword count is rough. It catches CVEs in MCP servers and in tools that mention one, and it misses records that say “Model Context Protocol” without “MCP server”. The trend is the same with either phrase.
Do popular MCP servers and agent skills pass our checks?
The run of 14 October covered the 65 popular ones listed on Best of Vibe Coding that day (51 skills and plugins, 8 MCP servers, 6 that are both; the smallest has 17k GitHub stars). We run the same 18 checks on every listed MCP server and skill once a week, so the next run picks up projects added since.
18 of the 65 pass every check that applies. A skill has no npm package to trace and a server may have no skill folder to scan, so between 5 and 17 checks apply to each project, 10 on the median.
- Of the 14 MCP servers (including the 6 that are also skills), 2 pass every check.
- Of the 57 skills and plugins, 17 do.
- Of the 47 that fail something, 28 fail one check, 8 fail two, 6 fail three, 2 fail four and 3 fail five.
| # | Check | Fail | Applies to |
|---|---|---|---|
| 13 | A private way to report a vulnerability | 19 | 65 |
| 4 | No advisories at CVSS 7 or higher with a fix available | 18 | 36 |
| 7 | No binaries or archives in agent or server folders | 9 | 64 |
| 2 | Listed in the official MCP Registry under the owner’s name | 7 | 14 |
| 9 | No download-and-run lines in files the agent reads | 7 | 60 |
| 17 | No shell commands built from input, no unchecked URL opening | 7 | 14 |
| 3 | Build provenance on the latest release | 5 | 11 |
| 8 | No dangerous CI workflow | 4 | 56 |
| 12 | No override, concealment or secret-file instructions | 4 | 62 |
| 5 | No install-time scripts | 2 | 11 |
| 11 | No hidden Unicode in text the agent reads | 2 | 64 |
| 14 | Maintained | 1 | 65 |
| 1 | The package points back to its repo | 0 | 11 |
| 6 | No hardcoded keys or tokens | 0 | 62 |
| 10 | HTTPS endpoints, no keys in shipped MCP config | 0 | 43 |
| 15 | No fake prerequisite or installer steps | 0 | 63 |
| 18 | HTTP endpoints check auth or stay on localhost | 0 | 4 |
| 16 | No email recipients added since the last version, no hidden BCC | 0 | 0 |
Check 16 compares a project’s code with the version we checked before it, and this is the first run that records addresses, so it applies to none yet. Eight new results in 6 projects (3 for keys in code, 4 for download-and-run lines, 1 for an installer step) are waiting for us to read them and count as “does not apply” here, as they do on the project pages.
The counts include 4 corrections where a check got it wrong; each project page shows the correction and its reason.
Advisories depend on what we can read. For projects that ship an npm or PyPI package, we read the latest version and the dependencies it installs. For the others we read the lockfile at the repo root, which can hold build and test tools that never reach your machine, and a check 4 fail there may sit in one of those.
19 list no private way to report a vulnerability. No security policy, and GitHub’s private reporting is off, so a person who finds a hole has to open a public issue or go looking for an email address.
Each result names what was read. All 65 results carry the commit and a hash of its files; 11 projects also pin the npm or PyPI version and its hash (18 packages, 15 on npm and 3 on PyPI), and the other 54 publish no package we trace. One project’s result changed against the run before it.
Do MCP servers and skills go quiet?
We list 103 MCP servers and skills today and have commit and release dates for 88 of them; we have not measured the 15 newest yet. Of the 88, 2 have gone 6 months without a commit or a release, none of them from the safety run, and none is archived. Across the 544 projects we have dates for on both lists, 41 have gone quiet (26 on Best of Vibe Coding, 15 on Best of Open-Source AI).
That reflects how we pick: we list projects people already use, and their maintainers keep working on them. We have no numbers for a registry with tens of thousands of entries.
Did any licenses change?
We recorded none. We started storing the license GitHub reports for each repo, every day, on 13 October 2026, so this covers three days. The next edition of this report will cover a full quarter.
How the checks work
-
What we read. Each repo’s files on its default branch, and public data about it: npm, PyPI, the official MCP Registry, deps.dev, OSV and the repo’s own GitHub security advisories.
-
What we run. Nothing from the project. The scanners (gitleaks for keys, OpenSSF Scorecard for CI workflows, osv-scanner for lockfiles) read the files as text, and every other check is a fixed rule: a file pattern, a registry field, a date.
-
Which files. Files an agent loads: skill folders, rules, hooks, commands, MCP config. READMEs, docs and tests are left out, so an install line in a README does not count.
-
When. Once a week. This report uses the run of 14 October 2026.
-
What is shown. Each project page lists every check with pass, fail or “does not apply”, and links the file line or registry page behind each result. There is no overall grade, following OpenSSF Scorecard, and no check changes a project’s rank.
-
Corrections. Anyone can dispute a result through an issue form on the list repo; the project page then shows the correction and its reason.
-
Checks for patterns behind incidents. Four checks look for what the incidents above had in common: a “prerequisite” step with a password-protected archive, a paste-site script or antivirus switched off (15); an email recipient added since the last version, or a hidden BCC, in the repo and in the npm or PyPI file (16); a shell command built from input, or a URL opened with no scheme check (17); an HTTP endpoint with no auth check that does not stay on localhost (18).
-
Pinned results. Each result names the commit it read, and for a package the npm or PyPI version and its hash, so a result can be matched to the exact code you install.
-
New findings wait. A new fail of the keys, download-and-run, installer-step or email check shows as “does not apply” until we have read it.
-
How often a check is wrong. We read every line the four new checks flagged on 14 October: 4 of 27 (15%) were false, all from check 17 (a maintainer script, not server code). Checks 15, 16 and 18 flagged nothing that day, so their rate is not measured yet.
What we cannot check
- What an MCP server’s tools say once it runs. Tool descriptions built at runtime need the live server, and we never start one.
- Private alerts. Dependabot and code-scanning results stay with the maintainers.
- What the code does: network traffic, system calls, content a skill downloads when it runs, or whether a vulnerable function is ever called.
- Tool labels such as “read-only”. The MCP spec tells clients not to trust them, so we don’t treat them as permissions.
A pass means we did not find that pattern in the files on the day we read them.
About this report
We had no sponsor for this edition. The checks are the public ones on our methodology page, and the numbers come from the same weekly run every project page shows. If a later edition has a sponsor, its cover and the top of the report will name it. A sponsor sees the results when readers do and changes no number and no word of the findings, and a sponsor with a project on our lists gets the same checks as everyone else.
If a result looks wrong, tell us and we’ll fix it. The method, the sources and every check are on the methodology page.