We Scanned 101 MCP Server Configs. Two-Thirds Had Security Issues.

We scanned 101 MCP server configurations pulled directly from official documentation — the exact configs users copy-paste when setting up a server. 63 of them (62%) had at least one security finding. We found 9 critical issues, 4 high-severity issues, and 51 medium-severity issues. Here is what is broken and exactly how to fix it.

The Model Context Protocol is becoming the default way to connect AI agents to external tools — filesystems, databases, APIs, cloud infrastructure. Adoption is moving faster than security. MCP servers get capabilities that most software never touches: reading and writing files, executing code, making network requests, and holding credentials. A misconfigured server is not just a bug. It is a foothold.

We wanted to know: how bad is it in practice? Not by auditing source code or scanning npm registries, but by looking at what users actually deploy — the configs they build by following the README.

What we scanned

We collected 101 MCP server configurations sourced directly from each server's official documentation. These are the configs that appear in README files, setup guides, and quickstart tutorials. They represent what a user actually creates when they install and configure a server for the first time.

We ran every config through mcprotect, our static analysis tool for MCP configurations. mcprotect checks for unpinned package versions, hardcoded secrets, excessive filesystem permissions, and other misconfigurations — without executing anything or touching a network.

Results: 63 of 101 configs (62%) had at least one security finding. In total we found 77 individual findings: 9 critical, 5 high, and 63 medium severity. The 38 clean configs were almost entirely servers that used uvx (Python), Docker, or remote hosting — they avoided the npm supply chain pattern entirely.

Finding 1: Unpinned package versions

63 of 101 servers (62%). Severity: medium. This is the single most common issue in the MCP ecosystem.

Nearly every npm-based MCP server's documentation tells you to run via npx -y without specifying a version:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/Documents"]
    }
  }
}

The -y flag auto-confirms the install. No version pin means every launch pulls whatever is currently latest on npm. If a package is compromised — via hijacked maintainer credentials, a dependency confusion attack, or a registry-level incident — your next session silently runs the attacker's code with whatever permissions the server has.

This is not theoretical. The postmark-mcp typosquat and the SANDWORM_MODE campaign (19+ malicious npm packages) both exploited exactly this pattern. The npm ecosystem has seen hundreds of supply chain attacks. MCP servers are a high-value target because they often hold API keys and have filesystem access.

"args": ["-y", "@modelcontextprotocol/server-filesystem"]

"args": ["-y", "@modelcontextprotocol/server-filesystem@2025.11.18"]

npm view @modelcontextprotocol/server-filesystem version

Finding 2: Hardcoded secrets in config files

9 servers had hardcoded credentials. Severity: critical. These were not test fixtures or placeholder values — they were real tokens with recognizable provider prefixes.

We detected:

• GitHub personal access tokens (ghp_)
• Slack bot tokens (xoxb-)
• Postgres passwords in connection strings
• Notion API tokens (ntn_)
• Supabase JWT service role keys
• Stripe secret keys (sk_test_ / sk_live_)
• Sentry auth tokens (sntrys_)
• Brave Search API keys (BSA)
• Tavily API keys (tvly-)

MCP config files live in predictable locations (~/Library/Application Support/Claude/, .cursor/mcp.json). They get synced to iCloud, backed up to Time Machine, and committed to dotfile repos. A hardcoded ghp_ token in your MCP config is one careless git push away from exposure. Independent research from Astrix confirms the pattern at scale: 53% of MCP servers use plaintext API keys, and only 8.5% use OAuth.

"env": {
  "GITHUB_TOKEN": "ghp_abc123def456..."
}

# Store the secret in your macOS keychain (one-time):
security add-generic-password -s "github-token" -a "$USER" -w "ghp_abc123def456..."

# Then in your shell profile (.zshrc / .bashrc):
export GITHUB_TOKEN=$(security find-generic-password -s "github-token" -w)

# .env (add this file to .gitignore!)
GITHUB_TOKEN=ghp_abc123def456...

"env": {
  "GITHUB_TOKEN": "${GITHUB_TOKEN}"
}

Finding 3: Excessive filesystem permissions

2 servers were configured with root (/) or home directory (~) access. Severity: high. This gives an MCP server — and the AI agent controlling it — read and write access to your entire filesystem.

When you grant a filesystem server access to /, the agent can read your SSH keys, browser cookies, credentials files, and every document on your machine. When you grant ~, it is nearly as bad. The server's README might show / as a convenient example, but users copy it verbatim.

This risk compounds with other vulnerabilities. CVE-2025-53109 and CVE-2025-53110 demonstrated path traversal in Anthropic's own filesystem server — meaning even supposedly scoped access could be escaped. Granting / makes traversal bugs irrelevant because the server already has everything.

"args": ["-y", "@modelcontextprotocol/server-filesystem", "/"]

"args": ["-y", "@modelcontextprotocol/server-filesystem", "./my-project"]

The bigger picture: CVEs and supply chain attacks

Our scan results are consistent with what the broader security community is finding. 30+ CVEs were filed against MCP servers in January and February 2026 alone. Several affect servers with hundreds of thousands of installations.

CVE-2025-6514 is particularly notable: mcp-remote, a transport proxy used by Claude Desktop and other clients, had an OAuth callback vulnerability that allowed unauthenticated remote code execution. It had 437,000 downloads before the patch. This is exactly the kind of server that gets pulled by npx -y without a version pin.

The Anthropic Filesystem and Git server CVEs are significant because they are first-party, officially maintained servers. If the protocol authors' own implementations have path traversal and RCE chains, the ecosystem-wide exposure is predictable.

Active supply chain attacks

postmark-mcp was the first documented malicious MCP server. It typosquatted the legitimate Postmark email API server. When installed, it silently BCC'd every email to an attacker-controlled address. The server functioned normally otherwise — the user and the AI agent saw successful email delivery with no indication of data exfiltration.

SANDWORM_MODE is a campaign involving 19+ malicious npm packages that deploy rogue MCP server configurations to harvest credentials, API tokens, and session data. These are not hypothetical threats — they are in registries today.

The numbers

Our 62% finding rate closely matches AgentSeal's independent analysis of 1,808 servers exactly. The consistency across different methodologies — our config-level static analysis, AgentSeal's server audits, Enkrypt AI's vulnerability assessments — suggests this is the real baseline for the ecosystem.

How to fix your config in 5 minutes

You do not need to wait for the ecosystem to improve. Every issue we found is fixable in your config file right now.

1. Open your MCP config file
   - Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json
   - Cursor: .cursor/mcp.json in your project

2. Pin every npx package version:
   npm view <package-name> version
   Then add @<version> to the args array.

3. Move every secret to environment variables:
   - Remove hardcoded tokens from your config
   - Store them in your OS keychain or a .env file
   - Reference them via ${VAR_NAME} in the config

4. Scope every filesystem path:
   - Replace "/" or "~" with the specific project directory
   - Use relative paths like "./my-project" when possible

5. Remove servers you are not actively using.

6. Run mcprotect to verify:
   npx mcprotect@latest

The single highest-impact change is pinning your package versions. It takes two minutes and eliminates the most common attack vector. Moving secrets out of config files is second. Scoping filesystem access is third. Do all three and you have eliminated every finding category from our scan.

How we built mcprotect

mcprotect is a static analysis tool for MCP configurations. It parses your claude_desktop_config.json, .cursor/mcp.json, or any MCP config format and checks for known misconfigurations — unpinned versions, hardcoded secrets, overly broad permissions, and suspicious patterns.

It runs entirely client-side. Your config is not sent anywhere. There is no account, no telemetry, no backend. The checks are pattern-based and deterministic: the same config always produces the same results.

We built it because we needed it. Every MCP security report we read described ecosystem-wide problems, but none gave users a tool to check their own setup. The findings in this post are the output of running mcprotect against real configs. If it can find these issues automatically, there is no reason to leave them unfixed.

Run it from the command line or use the web scanner.

Methodology

We collected 101 MCP server configurations by visiting each server's official documentation (README files, setup guides, quickstart tutorials) and extracting the recommended configuration. We did not modify configurations, add servers from unofficial sources, or generate synthetic examples. Each config was scanned using mcprotect's static analysis engine, which checks for: unpinned package versions (SC-001), hardcoded secrets matching known provider patterns (CE-001), unrestricted filesystem access (EP-001), and API key patterns for high-value services.

Third-party data referenced in this post comes from published security audits by AgentSeal (1,808 servers), Enkrypt AI (1,000 servers), Astrix (credential and auth analysis), and Invariant Labs (5,125 servers for cross-server data flows). CVE data was sourced from the National Vulnerability Database. The OWASP MCP Top 10 was used as the taxonomic reference.