MCP Server Security: How to Audit and Harden MCP Deployments

Your AI agent just connected to twelve MCP servers. It can now read your database, search your file system, send Slack messages, and execute shell commands. Every one of those connections is an attack surface that did not exist six months ago.

The Model Context Protocol has become the default integration layer for connecting LLMs to external tools. Adoption has been rapid: thousands of MCP servers are publicly available, and enterprises are building custom servers to connect agents to internal systems. But the security model has not kept pace with the adoption curve. Research in early 2026 found that up to 43% of MCP servers contain command injection vulnerabilities, and roughly a third allow unrestricted network access.

This guide covers the six critical vulnerability classes in MCP deployments, walks through real CVEs that demonstrate the impact, and provides a practical audit checklist for teams running MCP servers in production.

Key Takeaways

• MCP servers grant AI agents direct access to external systems, making each tool connection an attack surface
• Six vulnerability classes dominate: tool poisoning, prompt injection via sampling, session hijacking, unauthenticated endpoints, path traversal, and command injection
• Real CVEs in Anthropic's own MCP servers demonstrate that even first-party implementations are vulnerable
• The MCP specification uses SHOULD (recommended) rather than MUST (required) for most security controls, creating a gap between intent and implementation
• A 15-item audit checklist can identify the most critical exposures before they are exploited

Why MCP Expands the AI Attack Surface

Traditional LLM applications have a relatively contained attack surface: user input goes in, text comes out. MCP fundamentally changes this by giving the LLM the ability to discover tools at runtime, read their descriptions, decide which ones to call, and pass parameters to them.

This creates several new trust boundaries that did not exist before.

Tool metadata is processed as input. When an MCP client connects to a server, it receives tool definitions including names, descriptions, and parameter schemas. The LLM reads all of this metadata to decide what tools are available and how to use them. This metadata becomes part of the prompt context, which means it is subject to the same prompt injection risks as any other untrusted input.

Tools execute with server-side privileges. MCP tools run on the server with whatever permissions the server process has. If the server runs as root, every tool call runs as root. If the server has network access to internal services, every tool call can reach those services.

Dynamic tool registration enables rug-pull attacks. In hosted MCP environments, tool definitions can change after a user has approved them. A tool that was benign at approval time can be modified to include malicious instructions later.

The Six Critical MCP Vulnerability Classes

1. Tool Poisoning

Tool poisoning is the most novel attack class specific to MCP. Attackers embed hidden instructions in tool descriptions that are invisible to human users but processed by the LLM. Invariant Labs demonstrated this by creating a tool with a benign visible description and a hidden instruction that exfiltrated WhatsApp message history through an apparently innocent "random fact of the day" tool.

CyberArk expanded on this with Full-Schema Poisoning (FSP), showing that the attack surface extends beyond description fields to the entire tool schema, including parameter names, types, and validation rules.

2. Prompt Injection via MCP Sampling

Palo Alto's Unit 42 team identified three distinct attack classes that exploit MCP's sampling capability: covert tool invocation (tricking the client into calling tools the user did not request), conversation hijacking (redirecting the agent's behavior mid-session), and resource theft (draining compute quotas). The sampling feature, which allows servers to request completions from the client's LLM, creates a bidirectional channel that attackers can abuse.

3. Session Hijacking

CVE-2025-6515, discovered by JFrog, demonstrated session hijacking in the oatpp-mcp framework. MCP session IDs embedded in URLs or transmitted insecurely can be captured and reused, giving an attacker full control over an established agent session. The MCP specification states that session IDs SHOULD use secure random generation, but does not enforce it.

4. Unauthenticated Endpoints

The MCP specification treats authentication as optional. Many MCP servers, particularly those designed for local development, expose their full tool surface without any authentication. When these servers are inadvertently exposed to the network (a common misconfiguration), anyone who can reach the endpoint can invoke any tool.

5. Path Traversal

CVE-2025-68145, CVE-2025-68143, and CVE-2025-68144 were three chained vulnerabilities found in Anthropic's own mcp-server-git. The first bypassed path validation, the second allowed unrestricted git_init that could turn the .ssh directory into a git repository, and the third enabled argument injection in git_diff. Combined with the Filesystem MCP server, the chain achieved full remote code execution through malicious .git/config files.

6. Command Injection

Command injection is the most common vulnerability class in MCP servers. A gemini-mcp-tool package was found to pass unsanitized user input directly to shell commands with no authentication required (CVSS 9.8). CVE-2025-6514 in mcp-remote achieved arbitrary OS command execution when MCP clients connected to untrusted servers. These are not sophisticated attacks; they are basic input validation failures that the industry solved decades ago in web applications but is repeating in MCP server implementations.

What the CVEs Teach Us

The Anthropic mcp-server-git CVE chain is particularly instructive because it was discovered in a first-party implementation from the organization that created MCP. If the protocol's own maintainers shipped these vulnerabilities, assume that third-party and community-built servers have similar or worse issues.

The Microsoft MarkItDown SSRF vulnerability reveals another pattern. When BlueRock analyzed over 7,000 MCP servers, they estimated that 36.7% may have similar SSRF exposure. Microsoft classified the vulnerability as low-risk despite demonstrated EC2 metadata access, which illustrates the gap between how vendors assess MCP security risk and what attackers can actually achieve.

MCP Server Audit Checklist

Before deploying any MCP server to production, validate these 15 controls.

Authentication and Authorization

All non-local MCP connections require authentication (OAuth 2.1 with PKCE, not static API keys)

Tokens are scoped per-server and per-tool, never shared across MCP servers

Tool-level authorization enforces least privilege (each tool only gets the permissions it needs)

Tool Integrity

Tool descriptions are reviewed for hidden instructions before deployment

Tool schemas are version-locked and changes require re-approval

Dynamic tool registration is disabled, or changes trigger alerts and re-validation

Input Validation

All tool parameters are validated against a strict schema before execution

Shell commands are never constructed from user-controlled input (use parameterized APIs instead)

File paths are validated against an allowlist and cannot traverse outside designated directories

Session Management

Session IDs use cryptographically secure random generation

Sessions have bounded lifetimes and are invalidated on disconnect

Session tokens are never included in URLs or logs

Infrastructure Hardening

MCP servers run in isolated containers as non-root users with dropped capabilities

Network egress is restricted to explicitly required destinations

All tool invocations, parameters, and results are logged to a centralized audit system

The OWASP MCP Security Minimum Bar categorizes items 1-2 and 13-14 as hard deployment gates: any failure should block go-live until remediated.

Practical Recommendations

Treat MCP servers as privileged infrastructure. An MCP server with database access is functionally equivalent to an API with database credentials. Apply the same security controls you would to any service that holds production secrets.

Audit third-party MCP servers before connecting them. The npm/PyPI ecosystem for MCP servers is growing rapidly with minimal security review. Run dependency audits (npm audit, pip audit, OSV-Scanner) and review the server source code, particularly how it handles tool descriptions and user input.

Implement runtime monitoring. Static analysis catches some issues, but tool poisoning and rug-pull attacks are runtime problems. Monitor for unexpected tool calls, unusual parameter patterns, and data flows that do not match expected behavior. This aligns with the OWASP Agentic Top 10 guidance on monitoring autonomous agent behavior.

Include MCP in your AI security assessment scope. Many organizations assess their LLM applications for prompt injection but exclude the MCP layer from testing. If your agents connect to MCP servers, those servers need to be part of your AI security audit.

Conclusion

MCP adoption is accelerating, and the vulnerability surface is expanding with it. The protocol's security model relies on implementers doing the right thing, and the CVE data shows that many are not. The good news is that the vulnerability classes are well-understood, and the controls are straightforward to implement.

If your AI agents are connecting to MCP servers in production, run a Securetom scan to identify exposed surfaces, then book an AI security assessment to validate your MCP deployment end-to-end. The attack surface is real, the tooling exists, and the time to audit is before the first incident.