91% of MCP server repositories have at least one security finding. We ran 6,494 scans across 2,896 unique repos with 16 independent engines over the past month. The average trust score was 7.54 out of 10. Thirteen repos scored below 5.0. Half landed between 5 and 7.
This is not a malware problem. It is a hygiene problem. Most repos in the yellow zone are maintained, functional, and used in production. They carry known CVEs in their dependency chains, secrets in commit history, or MCP tool permissions broader than what the tool actually needs. One scanner would call most of them clean.
Key findings
- 91.4% of repos flagged by at least 1 of 16 engines (5,937 of 6,494 scans)
- 49.7% scored yellow (5.0-7.0), 50.1% green (8.0-10.0), 0.2% red (below 5.0)
- 85% of flagged repos are flagged by 2 or more engines independently
- 76.5% of repos have known dependency vulnerabilities (Trivy)
- 43.6% have potential secrets in source (detect-secrets)
- 31.8% flagged by custom YARA rules for MCP-specific threats
Methodology
Sample. 2,896 unique repositories from public MCP registries, official MCP directories on GitHub, and community submissions. Scanned between March 1 and April 2, 2026. This is roughly 13x larger than our first report (216 repos in March).
Engines. 16 independent security engines, each in its own Docker container. No engine sees another engine's output. The full engine list covers five categories:
- Vulnerability scanning: Trivy, Grype, OSV Scanner, npm audit, pip-audit
- Secret detection: detect-secrets, Gitleaks
- Static analysis: Bandit, Semgrep, Checkov
- MCP-specific: Custom YARA rules, MCP Guardian
- Supply chain (informational): Syft (SBOM), ScanCode (licenses), Cisco AIBOM
Scoring. Start at 10.0. For each finding, deduct
severity_weight × engine_weight. Maximum
deduction per engine is capped at 3.0. Three informational engines
(Syft, ScanCode, Cisco AIBOM) produce findings but do not reduce
the trust score. Final score clamped to 0.0-10.0.
Score distribution
| Zone | Score range | Repos | Percentage |
|---|---|---|---|
| Red | 0.0 - 4.0 | 13 | 0.2% |
| Yellow | 5.0 - 7.0 | 3,231 | 49.7% |
| Green | 8.0 - 10.0 | 3,250 | 50.1% |
The yellow zone carries the main finding. These 3,231 repos are not abandoned or broken. Most are actively maintained. They carry dependency vulnerabilities with published CVEs, secrets committed to source, or MCP-specific configuration issues like overly broad tool permissions. A single security scanner would classify most of these as passing.
At the top: 792 repos (12.2%) scored a perfect 10.0, passing all 16 engines with zero scoring findings. That number sets the ceiling for how clean the MCP server ecosystem is today.
Engine detection rates
| Engine | Detection rate | Category |
|---|---|---|
| Trivy | 76.5% | Vulnerability scanning |
| OSV Scanner | 54.9% | Vulnerability scanning |
| Grype | 49.8% | Vulnerability scanning |
| detect-secrets | 43.6% | Secret detection |
| Custom YARA | 31.8% | MCP-specific threats |
| MCP Guardian | 22.6% | MCP-specific checks |
| Gitleaks | 22.3% | Secret detection |
| Bandit | 12.9% | Static analysis (Python) |
The three vulnerability scanners have the highest detection rates. Dependency vulnerabilities are common. CVE databases are extensive and most repos pull in dozens of transitive dependencies.
detect-secrets flagged 43.6% of repos with an average of 99.9 findings per flagged repo. That number is high because it uses entropy-based pattern matching that catches non-standard secret formats. Many of those are false positives. Gitleaks (22.3%, pattern-based rules) is more precise but misses atypical formats. Running both tells you more than running either alone.
Custom YARA rules flagged 31.8% of repos. These rules target MCP-specific patterns: tools that request filesystem or network access beyond what their description implies, tool descriptions containing instruction-like language that could influence agent behavior, and configuration that exposes internal state to callers. General-purpose scanners do not check for these.
Six engines returned zero findings. This is expected. npm audit
only runs on Node.js projects with a package-lock.json.
pip-audit requires Python dependency manifests. Semgrep needs
matching code patterns. A zero detection rate means the engine's
rules did not match this sample, not that the engine failed.
Cross-engine agreement
The strongest signal comes from independent tools agreeing on the same repo.
| Engines flagging | Scans | % of flagged |
|---|---|---|
| 1 engine only | 891 | 15.0% |
| 2 engines | 791 | 13.3% |
| 3 engines | 1,333 | 22.5% |
| 4 engines | 1,272 | 21.4% |
| 5 engines | 752 | 12.7% |
| 6 engines | 593 | 10.0% |
| 7 engines | 268 | 4.5% |
| 8-9 engines | 40 | 0.7% |
85% of flagged repos are flagged by two or more engines. That is the argument for multi-engine scanning. A single tool catches what it was built to catch. Run 16 and the blind spots become visible.
The three vulnerability scanners (Trivy, Grype, OSV Scanner) agree most often: they query overlapping CVE databases. The more interesting signal comes from cross-category agreement. When a vulnerability scanner, a secret detector, and an MCP-specific rule all flag the same repo, the problem is structural.
Top co-occurring engine pairs: OSV Scanner + Trivy (3,167 scans), Grype + Trivy (3,154), Grype + OSV Scanner (2,877). These three form the backbone of high-confidence vulnerability detection across the dataset.
Notable findings
Cline scored 3.5/10 with 8 engines flagging independently, the highest engine count in the dataset. Findings span dependency vulnerabilities across multiple package ecosystems, detected secrets in source, and MCP-specific configuration issues. Cline is one of the most popular AI coding assistants. Developers using it daily should be aware.
Apache APISIX MCP server scored 3.5/10 with 7 engines flagging. Known CVEs in the dependency chain, configuration patterns that expose internal endpoints, broad permission scopes in MCP tool definitions. APISIX is a widely deployed API gateway. Its MCP integration inherits the parent project's large attack surface.
Scan from inside your editor
Today we shipped an MCP plugin. Install with
uvx mcpampel, type "scan my servers" and it discovers
and scans every MCP server in your config. Same 16 engines, same
scoring. Works in Claude Code, Cursor, Windsurf, and Gemini CLI.
50 API calls per day, no credit card.
We built the scanner as an MCP server because developers do not switch tabs to run security checks. If the tool lives where the code lives, it gets used.
Limitations
- Static analysis only. We scan source code, dependencies, and configuration. We do not execute tools or observe runtime behavior.
- Sample bias: repos from public registries tend to be better maintained than internal or ad-hoc MCP servers. The broader ecosystem likely scores lower.
- Three LLM-powered engines (requiring external API keys) were disabled during this scan period. Adding them would likely shift some scores down.
- detect-secrets averages 99.9 findings per flagged repo. Its entropy-based matching produces false positives. Gitleaks is more precise but catches less. We run both and weight accordingly.
- Engine weights are our judgment call. We set them based on signal quality, not an external standard. A different weighting produces different scores. The full methodology is at docs/scoring.
What you can do
Scan before connecting. Paste any MCP server URL into MCPAmpel. GitHub, npm, PyPI. Results in under 60 seconds. Free, no account needed.
Scan from your editor. Install the
MCP plugin
with uvx mcpampel. It finds every MCP server in your
config and scans them.
Automate in CI. The MCPAmpel GitHub Action scans repos on every pull request. Set a minimum trust score and fail builds that drop below it.
Map to compliance. For companies under NIS2, MCP servers are part of your software supply chain. MCPAmpel generates SBOM exports via Syft and maps findings to the OWASP MCP Top 10.
Scan an MCP server now, for free.
Start scanning