MCP Server Security for Public Documentation
Trend Micro scanned publicly reachable MCP servers in July 2025 and found 492 running with no client authentication and no traffic encryption. By April 2026, that number had nearly tripled to 1,467. Of those, 1,227 were still running the long-deprecated SSE transport, meaning operators had not adopted more secure implementations even as the spec moved on without them.
Enkrypt AI's scan of 1,000 MCP servers in October 2025 found that 33% carried critical vulnerabilities. GitGuardian's State of Secrets Sprawl 2026 turned up 24,008 secrets in MCP-related configuration files on public GitHub, 2,117 of which were still valid at publication. The unofficial mcp.so registry was indexing over 16,000 servers as of early 2026, most without any vetting process.
These are not projections. They are a snapshot of what teams are actually shipping.
A public documentation MCP server is, by definition, reachable from the open internet, which places it inside this landscape rather than at its margins. Shadow servers compound the problem considerably: developers spin up documentation instances for experimentation, leave defaults in place, and those instances persist outside any governance structure. The surface area is larger than most security teams realize, because much of it was never formally provisioned to begin with.
The Credential Problem Underlying Most MCP Authentication Failures
Astrix Research's "State of MCP Server Security 2025" analyzed over 5,200 open-source MCP server implementations. Eighty-eight percent require credentials of some kind, which sounds encouraging until you look at the composition: 53% rely on long-lived static secrets, and only 8.5% use OAuth or a comparably modern method.
Static secrets dominate because they are operationally easier. No token rotation infrastructure to build, no authorization server to configure. You set an environment variable and move on. That tradeoff feels reasonable in the moment, and I understand why teams make it, having watched many of them do exactly that under deadline pressure. The cost accumulates quietly: long-lived secrets can be retrieved through prompt injection, exposed in debug traces, or leaked into protocol logs. OWASP designates this the top risk class in its MCP Top 10 (MCP01:2025), and the pathway from leaked token to full system compromise is well-documented.
The November 2025 spec revision formalized OAuth 2.1 as the authentication standard for remote MCP servers. That is a meaningful maturation of the protocol. The 2026 scan data shows most deployed servers have not updated. Worth noting also that a remote MCP server may still require no authentication under the revised spec; OAuth 2.1 governs servers that authenticate, but authentication itself remains optional by design.
For public documentation deployments, the temptation is to treat read-only tools as low-risk and therefore not worth securing rigorously. That reasoning breaks down when you consider that a documentation server is rarely the only server connected to a given agent. Credentials that unlock a read-only documentation tool may share infrastructure with credentials that unlock considerably more.
Prompt Injection Through Documentation Content and Why It's Hard to Detect
The mechanism here is less intuitive than a traditional injection attack. Content stored in a documentation system can contain hidden instructions, embedded in text, metadata, or formatted markup, that an MCP tool surfaces directly into the model's context window. The model treats tool responses as trusted input. There is no editorial review at runtime; the instruction appears in context and the agent acts on it.
Hidden instructions in a document chunk can redirect the agent, exfiltrate data from other connected tools, or override constraints established in the system prompt. The NSA's May 2026 MCP security advisory characterized this threat as "systemic rather than isolated" in multi-agent workflows, observing that one agent's output becomes another's input. A poisoned documentation page read by one agent can propagate malicious instructions to downstream agents in the same chain.
Detection is difficult, for compounding reasons that are worth unpacking. Users typically do not see complete tool descriptions or tool responses during execution, making injection invisible at the UI layer. Where clients do surface tool metadata, approval fatigue tends to set in; users approve habitually rather than reviewing carefully. Empirical testing found that five of seven evaluated MCP clients do not implement static validation of server-provided metadata at all.
Public documentation is a specifically exposed surface here because the content is often community-contributed, updated frequently, and reviewed for factual correctness rather than for whether it might contain executable instructions. The attack vector is the trust we already extend to familiar, legitimate-looking text. A documentation page that reads entirely normally to a human reviewer may contain instructions that an agent follows without surfacing any visible anomaly.
Tool Poisoning and Rug Pulls: How Trusted Tools Become Attack Infrastructure
Tool descriptions are reviewed at connection time. Tool responses enter the LLM context with no equivalent check at runtime. That asymmetry is the foundation of tool poisoning: a malicious server makes its tools look normal on inspection, then embeds instructions in responses. One poisoned tool affects every session where it is called.
The rug pull variant is more insidious. Nothing in the base MCP protocol prevented a server from changing a tool's description after initial approval. The spec's June 2025 revision added a tools/list_changed notification mechanism to allow clients to detect mutations. Enforcement remains client-side and inconsistently implemented; many clients receive the notification and do not act on it.
The Postmark MCP backdoor, disclosed in September 2025, clarified the stakes for a lot of security teams. An unofficial server with 1,500 weekly downloads was quietly modified to add a BCC field to its send_email function. Every email sent through that tool was silently copied to an attacker-controlled address. Users with auto-update enabled saw no behavioral change. The attack was invisible to operators because the interface looked identical to what had been approved, which is precisely the point: there was nothing to notice.
Invariant Labs demonstrated a related escalation pattern with the official GitHub MCP server. A malicious repository issue could instruct the model to access private repositories through a trusted, co-connected server and exfiltrate content into a public pull request. Research found a 72.4% cascade rate when multiple MCP servers are compromised. OWASP's MCP03:2025 covers the full family of related attacks, including rug pulls, schema poisoning where tampered contract definitions cause agents to execute destructive commands, and tool shadowing where duplicate tools intercept interactions.
For documentation deployments, the risk concentrates when the documentation server shares an agent with higher-privilege servers. The docs server becomes the soft entry point. Getting the docs tool accepted is step one; the payload executes through whatever else the agent can reach.
Command Injection, Path Traversal, and SSRF in MCP Server Implementations
Endor Labs analyzed 2,614 MCP implementations and found that 82% use file operations prone to path traversal, 67% use APIs related to code injection, and 34% use APIs susceptible to command injection. These are not fringe configurations; they are the majority pattern in deployed servers.
CVE-2025-6514 puts a concrete face on those percentages. The vulnerability was a critical OS command injection flaw in mcp-remote, an OAuth proxy with over 437,000 downloads that appeared in integration guides from Cloudflare, Hugging Face, and Auth0. A malicious MCP endpoint could send a crafted authorization URL that mcp-remote passed directly to the system shell, achieving remote code execution on the client machine. The vulnerability existed in infrastructure teams had assumed was safe precisely because it was widely recommended. That assumption is what made it dangerous.
BlueRock disclosed a severe server-side request forgery vulnerability in Microsoft's MarkItDown MCP server. A 2026 analysis of more than 7,000 servers estimated that a comparable exposure pattern may be latent in approximately 36.7% of all MCP servers on the web. Anthropic's own Git MCP server accumulated three disclosed CVEs: CVE-2025-68143, CVE-2025-68144, and CVE-2025-68145. The researcher commentary on those disclosures was pointed. If Anthropic gets MCP security wrong, the field has no grounds for confidence that anyone else will.
For documentation-specific deployments, path traversal in file-serving tools can expose files well outside the intended documentation directory. SSRF can turn a documentation retrieval tool into a pivot point for internal network reconnaissance, which matters considerably if the server is deployed inside a corporate network boundary rather than in fully isolated infrastructure.
Supply Chain Risk From Third-Party and Community MCP Servers
The SmartLoader registry poisoning, disclosed in February 2026, is the supply chain incident that should recalibrate how teams think about community servers. The operation spent three months building five fake GitHub accounts with AI-generated developer personas before submitting a trojanized MCP server to a legitimate registry. The malicious fork was functionally identical to the legitimate version. The payload, a StealC infostealer, silently exfiltrated browser passwords, cloud session tokens, SSH keys, and API keys.
What is worth sitting with here is not the sophistication of the attack but its patience. Three months of persona cultivation before a single malicious commit. That is not opportunistic. That is a deliberate exploitation of the social trust that open-source ecosystems depend on, and it suggests that registry vetting processes built around code review alone are insufficient against adversaries willing to construct credibility over time.
The Shai-Hulud npm worm, which surfaced in late 2025, compromised 796 npm packages representing roughly 132 million monthly downloads. It specifically targeted mcp-server-named packages and injected prompt-injection payloads aimed at AI coding assistants. The Smithery platform compromise in October 2025 exploited a path traversal vulnerability in a major MCP hosting platform to expose builder credentials, specifically Docker configuration and Fly.io API tokens, potentially giving attackers control over thousands of deployed applications.
What these incidents share is that the attack surface in each case was not the protocol itself but the ecosystem of packages, registries, and hosting platforms that teams rely on to deploy quickly. The protocol's composability is its greatest practical strength and also what makes the supply chain so consequential. A documentation MCP server that uses a community plugin for retrieval, chunking, or search inherits the full dependency chain of that plugin as attack surface. Auto-update is a risk decision, not a convenience default. The Postmark backdoor and Shai-Hulud worm both exploited teams that had not made it consciously.
Concrete Mitigations for Public Documentation MCP Deployments
Authentication and access control. Implement OAuth 2.1 rather than static API keys or personal access tokens. The 53% of servers still relying on long-lived secrets, per Astrix Research, is a distribution to consciously exit. Enforce authentication even for ostensibly read-only documentation tools: the risk is not the read operation in isolation but the read operation performed by an agent also connected to tools with write access. Hard-coded secrets in config files and environment variables should be treated as a deployment blocker, not a debt item.
Content validation before context entry. Treat documentation chunks as untrusted input. Sanitize all content before it enters the model's context window, with particular attention to embedded instructions in structured formats like markdown, HTML, and JSON. Implement client-side validation of tool descriptions and metadata. Monitor for tools/list_changed notifications and re-validate tool descriptions on mutation. Initial approval at connection time is not permanent authorization.
Principle of least privilege on tool scope. Expose only the tools a documentation server actually requires. Search and retrieval are the core capabilities; file system access, SQL execution, and shell operations are not. Trend Micro found execute_sql tools on dozens of exposed hosts. That is not a documentation use case; it is an over-permissioned configuration that expands blast radius. Isolate the documentation MCP server from servers holding sensitive data wherever architecture permits.
Transport and network hardening. Migrate off deprecated SSE transport. The April 2026 data showing 1,227 of 1,467 exposed servers still running it means this is the prevalent configuration, not an edge case someone else has already solved. Enforce TLS on all MCP endpoints. Validate and sanitize all URLs passed to any tool making outbound requests; SSRF via documentation retrieval tools is a realistic attack path, not a theoretical one. Log tool calls with sufficient fidelity to reconstruct what happened after the fact.
Supply chain hygiene. Pin dependencies and review third-party MCP servers with the same scrutiny applied to any production dependency. In practice, that means reading the source rather than trusting the description. Treat auto-update as a risk decision requiring deliberate sign-off, not a default to leave enabled.
The argument against applying this rigor to documentation deployments is familiar: read-only tools serving public content simply do not warrant the same scrutiny as tools with write access or access to private data. It is a reasonable-sounding argument. What the 2025 and 2026 incident record suggests, though, is that the sensitivity of the documentation content is largely beside the point. What matters is what else the agent can reach, and what instructions that documentation content can inject into that agent's behavior. The distinction between a readable surface and an executable one is where the risk actually lives, and it is a distinction the agent does not make on your behalf.
