60% of MCP Servers Have Security Issues: The Checklist Before You Expose Deploy/Rollback to an Agent

Scan 9,695 real Model Context Protocol servers and 5,832 of them come back with a security issue. That's 60% — not a fringe finding from a handful of hobby projects, but the majority of a production ecosystem that AI vendors are actively wiring into coding agents, IDEs, and now deploy pipelines.

If your MCP server only reads a calendar or searches documentation, a vulnerability there is embarrassing. If it exposes deploy, rollback, scale, or restart — the exact pitch of an agent-operable PaaS — the same class of bug lets an attacker mutate production, not just misinform a chatbot. Before the numbers, here's the compressed version of what a deploy-capable MCP server needs to get right by default:

• Require real auth on every tool, not just the connection. A logged-in agent session isn't the same as an authorized deploy call.
• Never let a tool shell out or touch the filesystem with unsanitized input. Command injection is the single largest confirmed-exploitable category in the census below.
• Block egress to private IP ranges and cloud metadata endpoints. SSRF is how a "read-only" tool becomes a credential-theft tool.
• Put a human-confirmation gate in front of anything destructive. Read and mutate should never share one trust tier.

The Census, Broken Down​

The numbers above come from a census published in early July 2026: researchers crawled four major MCP directories — GitHub, Glama, Lobehub, and PulseMCP — between November 2025 and March 2026, correlating directory metadata against known and newly discovered vulnerabilities across 9,695 unique servers.

Of those, 5,832 showed some form of security weakness. Strip out the 3,573 servers flagged solely for missing authentication — a real gap, but not by itself an exploit — and 2,259 servers remain with confirmed, actively exploitable issues: arbitrary file access, command injection, SSRF, SQL injection, and more. Across those servers, researchers logged 4,982 distinct issues, breaking down like this:

Two details make this worse than a long tail of abandoned side projects. First, the census found no meaningful correlation between a server's popularity — GitHub stars, download counts, "verified" badges on directory listings — and whether it was safe to run. A well-known, actively maintained server was about as likely to carry a confirmed vulnerability as an obscure one. Second, a separate analysis of over 10,000 real-world MCP servers found credentials, API keys, and PII leaking at rates exceeding 10% — not a hypothetical risk, but data actively sitting in logs, configs, and tool outputs today. In January 2026, security researchers found more than 42,000 exposed OpenClaw instances on the public internet, with over 1,000 of them running unauthenticated MCP endpoints that leaked API keys, Slack credentials, and full chat histories to anyone who found the open port. Nothing about that incident required a novel exploit — it was default configuration meeting the open internet.

Authentication itself is close to non-existent as a default. A March 2026 review of the official MCP registry found only 8.5% of listed servers used OAuth; the other 91.5% relied on static API keys, long-lived personal access tokens, or nothing at all.

Two Flaws That Matter Most for a Deploy-Capable Server​

Aggregate statistics are useful for triage, but two specific 2026 disclosures show exactly what "confirmed exploitable" looks like when the tool on the other end can touch infrastructure — not just data.

The MCP STDIO transport design flaw. In April 2026, OX Security disclosed a systemic issue in the STDIO transport used by Anthropic's official MCP SDKs across Python, TypeScript, Java, and Rust. When a host initializes an MCP STDIO connection, it reads a command string from configuration and hands it to the shell — and it does so unconditionally, even if the target MCP server binary doesn't exist. An attacker who can influence that configuration string (through a shared config file, a compromised dependency, or a poisoned template) gets arbitrary shell execution, whether or not the intended server ever starts. Researchers estimated roughly 200,000 vulnerable deployments and 7,000 publicly reachable servers exposed to it. Anthropic's response was to call the behavior "expected" and leave input sanitization as the downstream developer's problem — which means every team running an MCP host inherits a shell-injection surface the protocol's own reference implementation won't close for them.

The mcp-atlassian SSRF-to-RCE chain. CVE-2026-27826 (CVSS 8.2) is a straightforward SSRF in the popular mcp-atlassian server: a tool argument that should only ever point at a configured Atlassian instance can be redirected to an internal address instead, including cloud metadata endpoints that hand back IAM credentials on a plate. On its own, that's a serious information-disclosure bug. Chained with CVE-2026-27825 (CVSS 9.0), an arbitrary file write in the same server, it becomes unauthenticated remote code execution — no valid session, no phished token, just two tool arguments that were never validated against where they were allowed to point. This is the pattern the census's SSRF and arbitrary-file-access categories look like in practice: individually medium-severity, chainable into full compromise.

The Checklist: What a Deploy-Capable MCP Server Must Get Right​

Take the census categories, the OWASP MCP Top 10, and the two disclosures above together, and the checklist for a self-hosted PaaS exposing deploy/rollback/logs/scale as agent-callable tools stops being generic advice and becomes a specific, testable list:

1. OAuth 2.1 with mandatory PKCE, on by default. Not the 91.5%-of-the-registry default of static keys or no auth at all — and validate the token audience so a token minted for one tool can't be replayed against another.
2. No ambient filesystem or shell access from a tool handler. Every command a tool runs should come from an allow-listed, parameterized set — never a string built from agent-supplied input and handed to a shell. This is the single largest confirmed-exploitable category (command injection, ~10% of issues, and the STDIO transport flaw above) and the easiest one to close by construction rather than by sanitizing after the fact.
3. Block egress to private IP ranges and cloud metadata addresses at the network layer, not just in application code — SSRF (422 cases) is how a tool meant to hit one external API ends up reading your cloud provider's IAM credentials instead.
4. Validate and allow-list every tool argument against a strict schema, and parameterize any query built from it — this closes the SQL injection and code injection categories (312 combined cases) that command-level allow-listing alone won't catch.
5. Rate-limit and cap resource consumption per tool call. DoS was the second-largest category in the census (490 cases) — an unbounded log tail or an unthrottled rollout-status poll is a resource-exhaustion vector, not just an annoyance.
6. Treat tool output as untrusted before it re-enters the agent's context or renders as UI. Strip instruction-shaped content (markdown headers, fake system messages) to blunt prompt injection (185 cases), and encode/escape anything that reaches a rendered surface to close XSS (155 cases) — increasingly relevant as MCP Apps lets servers return interactive HTML instead of raw JSON.
7. Never store or log credentials in plaintext, including in tool-call history, debug traces, or model context — the leak rate that exceeded 10% in independent testing, and the exact failure mode behind the OpenClaw exposure.
8. Gate every destructive or irreversible call behind explicit human confirmation — deploy and rollback are not the same trust tier as list-services or get-logs, and collapsing them into one blanket "the agent is authorized" decision is how a single compromised tool call becomes a production incident.
9. Pin and verify tool descriptions, and re-check them on every connection rather than trusting a one-time approval — a server that can silently rewrite what a tool claims to do after a user approves it is a rug-pull waiting for the right moment.
10. Pin and audit your MCP server's own dependencies. A compromised transitive dependency can alter tool behavior or inject a backdoor without touching a single line of the server's own code — supply-chain hygiene applies to the MCP layer exactly as it does to any other production service.

None of these ten items are exotic. They're the same discipline any internet-facing API has needed for a decade — scoped auth, input validation, egress controls, rate limits, output encoding, secrets hygiene, least privilege, integrity checks, dependency pinning. What's changed is the blast radius: a GET endpoint returning a JSON blob and a deploy tool an agent can call unattended are not equivalent failure modes, even when the underlying bug — an unvalidated SSRF target, a shell command built from user input — is identical.

Why This Is a Security Claim Now, Not a Feature Announcement​

MCP crossed 97 million monthly SDK downloads by March 2026 — a roughly 970x increase in under two years — with Anthropic, OpenAI, Google, Microsoft, and AWS all shipping first-class client support. As of mid-2026, 78% of enterprise AI teams report MCP-backed agents already in production. That adoption curve is exactly why the census numbers matter: "ship an MCP server" used to be a weekend integration project with a small blast radius. At today's scale, it's infrastructure that 78% of enterprise AI stacks are already routing agent actions through — which means every gap in the checklist above isn't a bug report, it's a claim about what an unattended agent is and isn't allowed to do to production.

A self-hosted platform doesn't get to treat its MCP server as an afterthought bolted onto an existing dashboard API. If deploy-from-chat is the pitch, the MCP server has to clear the same bar as the REST or GraphQL API sitting next to it — scoped auth, validated input, and a confirmation gate in front of anything that can't be undone.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with deploy and rollback exposed as auditable, confirmation-gated tools rather than a blanket "the agent can do anything." Star the repo on GitHub or deploy your first app today.

Sources​

• 4,982 Security Issues Expose 2,259 Public MCP Servers to AI Agent Attacks — Cyber Security News
• Update on Exposed MCP Servers: The Threat Widens to the Cloud — Trend Micro
• MCP Security Statistics 2026: CVEs, Vulnerabilities & Breach Data — Practical DevSecOps
• The risks of MCP servers leaking PII and PHI — MCPcat
• Your MCP Config Is Leaking Secrets — William Collins
• 200,000 MCP servers expose a command execution flaw that Anthropic calls a feature — VentureBeat
• MCP STDIO Design Flaw Enables Systemic AI Supply Chain RCE — Cloud Security Alliance
• RCE by design: MCP architectural choice haunts AI agent ecosystem — CSO Online
• MCP Security — OWASP Cheat Sheet Series
• OWASP MCP Top 10
• MCP Adoption Statistics 2026: Model Context Protocol — Digital Applied
• Anthropic's Model Context Protocol has crossed 97 million installs in just 16 months