MCP Server Security: Attack Vectors and Best Practices

Last Updated on May 14, 2026 by Arnav Sharma

Security researchers analyzed over 5,200 open-source MCP server implementations in 2025 and found that 53% rely on hard-coded static secrets like API keys and Personal Access Tokens. Only 8.5% use OAuth, the authentication method the MCP specification actually recommends. If you are deploying or evaluating MCP servers in a production environment, those numbers frame the problem clearly: the ecosystem grew fast, and security did not keep pace.

This guide covers the MCP security risks that matter most, the real-world incidents and CVEs you need to know, and the specific controls that reduce your exposure across both local and remote MCP deployments.

---

What Is MCP and Why Does Security Matter Now

Model Context Protocol (MCP) is an open standard introduced by Anthropic in late 2024 that gives AI agents a structured way to connect to external tools, databases, APIs, and services. Instead of writing custom integration code for every system an agent needs to access, teams use a standardized client-server interface.

Adoption was rapid. By 2025, tens of thousands of MCP servers had been deployed in enterprise environments. That scale created a correspondingly large attack surface, one that most organizations were not prepared to govern.

The core security problem is architectural. MCP was designed to maximize capability and interoperability. It was not designed with enterprise security as a first principle. The original specification shipped without a mandatory authentication framework. The implicit trust model assumed that MCP servers were benign. The tools those servers exposed were treated as outputs of well-behaved systems, not as a new attack surface.

How the MCP Architecture Creates Risk

MCP uses a three-layer architecture: a host application (such as Claude Desktop or an IDE), an MCP client within that host, and one or more MCP servers that expose tools and data sources. The client does not interact directly with external systems. It passes requests to the server, which then executes actions against databases, APIs, file systems, or shell commands.

This separation provides some security benefit. The AI model never directly handles an API key; the MCP server manages that credential instead. But it also means a single compromised or malicious MCP server has a direct bridge to every connected system in its scope. The server is both a trust boundary and a high-value target.

Local vs. Remote MCP Servers: Different Threat Models

Understanding the distinction between local and remote MCP servers is essential for accurate threat modeling.

Local MCP servers run on infrastructure you control. They typically execute OS commands, run custom code, and access files or local credentials directly. The attack surface includes: command injection into shell calls, access to the local file system and credential store, and lateral movement potential if the server has broad OS-level permissions. A compromised local MCP server can access SSH keys, cloud credentials, environment variables, and any file the host user can read.

Remote MCP servers are hosted by third parties and accessed over a network. They do not run on your infrastructure, which removes the local code execution risk. But they still access your data. A malicious or compromised remote server can exfiltrate authorized resources, return manipulated outputs to your AI agent, or serve as a pivot point for further attacks.

The practical takeaway: local MCP servers require sandboxing and strict OS-level permissions. Remote MCP servers require strong authorization, token scoping, and careful provider vetting.

---

The Core MCP Security Risks You Need to Know

Prompt Injection via MCP Servers

Prompt injection is ranked the number one vulnerability in the OWASP Top 10 for Large Language Model Applications (2025). In the MCP context, the attack embeds hidden instructions in content that the AI agent processes through the server. Those hidden instructions redirect the agent’s behavior in ways the user never intended and never sees.

The attack path: a user asks their AI assistant to summarize a document retrieved via an MCP server. An attacker has placed hidden instructions inside that document, formatted to look like system commands to the LLM. The model processes the document content and the injected instructions together, treating both as authoritative. The agent then executes the injected command, potentially exfiltrating credentials, sending data to an external endpoint, or modifying system files.

The MCP specification acknowledges this risk directly, stating there “SHOULD always be a human in the loop with the ability to deny tool invocations.” In production agentic workflows, that SHOULD is frequently not enforced.

Tool Poisoning and the Rug Pull Attack

Tool poisoning is a variant of indirect prompt injection that targets the MCP server’s tool metadata rather than user inputs. When an MCP client connects to a server, it requests a list of available tools via the tools/list command. The server returns tool names, descriptions, and parameter schemas. The AI agent uses this metadata to decide which tools to call and how to call them.

In a tool poisoning attack, an attacker embeds malicious instructions inside a tool’s description field. These instructions are not visible to human users during normal operation, but the AI model reads them as part of its context window. The model then executes the hidden directives, bypassing input validation layers that only inspect user-facing content.

The “rug pull” variant makes this particularly dangerous. Tool definitions in hosted MCP servers can change after initial deployment. A server operator, or an attacker who has compromised the server, modifies a tool’s description weeks or months after users approved it. Users approved a safe-looking tool on day one; by day thirty, that tool quietly reroutes API keys to an external endpoint. Invariant Labs demonstrated a proof-of-concept in 2025 where a malicious MCP server’s tool description contained directives that caused the agent to exfiltrate data without any visible indication to the user.

Credential Exposure and Hard-Coded Secrets

The Astrix Research team’s 2025 analysis of 5,200 MCP servers found that approximately 88% require credentials to operate. Of those, 53% use long-lived static secrets: API keys, Personal Access Tokens, and hard-coded OAuth tokens stored in environment variables or configuration files. These credentials rarely rotate and are frequently over-provisioned.

Hard-coded credentials in MCP server configuration files create compounding risk. Configuration files are committed to version control, shared across team members, copied into container images, and sometimes inadvertently exposed in public repositories. A single leaked API key in an MCP configuration file can provide persistent access to everything that key covers.

Researchers also identified 492 publicly exposed MCP servers lacking basic authentication or encryption in production environments. These servers accepted connections from any client with no credential validation.

The Confused Deputy Problem

MCP servers act as intermediaries between AI models and external systems. When a server executes an action in response to a model-generated request, it acts with its own credentials and permissions, not the user’s. If the server has broader privileges than the user should have, it can be coerced into taking actions the user was never authorized to perform.

An attacker crafts an input that causes the legitimate server, acting in good faith, to execute a privileged action on the attacker’s behalf. The server becomes an unwitting deputy. Red Hat’s security analysis notes that correct MCP implementation requires explicit mitigation: the server must enforce that every action executes with the user’s explicit permission and strictly scoped credentials, not with the server’s service account.

Supply Chain Risk and Malicious MCP Servers

A systematic arXiv study from May 2025 examined thousands of MCP servers on aggregator platforms. Researchers successfully deployed malicious MCP servers through those platforms, with existing audit mechanisms failing to detect them. Proof-of-concept servers accessed private files and triggered unintended system commands while appearing as legitimate tools in server directories.

Engineers often install MCP servers from public repositories without review, especially when the server appears to come from a recognizable publisher. Name or branding does not guarantee integrity. Name collision attacks extend this further: a malicious server registers a tool with a name identical or similar to a trusted server’s tool. When multiple servers connect to the same agent, the malicious tool may intercept calls intended for the legitimate one.

---

Real-World Incidents and CVEs

Incident	Date	Impact	Root Cause
Supabase/Cursor agent breach	Mid-2025	Sensitive integration tokens exfiltrated via public support thread	Privileged service-role access combined with untrusted input processed as commands
CVE-2025-6514 (mcp-remote)	2025	Remote code execution; access to API keys, SSH keys, local files	OS command injection via crafted OAuth URL; 437,000+ downloads affected
CVE-2025-49596 (MCP Inspector)	2025	RCE via webpage visit	CSRF vulnerability in developer utility
Anthropic SQLite MCP SQL injection	2025	Supply chain exposure across 5,000+ forks	SQL injection flaw in reference implementation; widely copied before archiving
Asana MCP data exposure	June 2025	Internal data surfaced to LLM agents	Overly broad tool scope; CRM data accessible via MCP connection

The Supabase incident is instructive because it combined three amplifying factors: privileged service-role credentials (far broader than needed), untrusted user input processed without sanitization, and an external communication channel that became the exfiltration path. Each factor alone would have been manageable. Together, they produced a critical breach.

CVE-2025-6514 in mcp-remote demonstrates the supply chain dimension. This was not an obscure or fringe server. It was an OAuth proxy used in integrations 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.

---

MCP Server Security Best Practices

Credential Management: Move Beyond Static Secrets

The single highest-impact change for most teams is replacing long-lived static credentials with short-lived, scoped tokens provisioned just-in-time.

• Audit all MCP server configuration files for hard-coded API keys, PATs, or OAuth tokens.
• Migrate to OAuth 2.0 wherever the connected service supports it. The MCP authorization specification is built on OAuth 2.1.
• Implement credential rotation policies. Credentials that never rotate become persistent liabilities when leaked.
• Use a secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) to inject credentials at runtime rather than storing them in environment variables or config files.
• Add MCP configuration files to .gitignore as a baseline. Use pre-commit hooks to detect secrets before they reach a repository.

Input Validation and Injection Defense

Every MCP server that passes user-influenced input to a shell command, database query, or API call is a potential injection sink.

• Validate and sanitize all inputs before passing them downstream. Any server calling subprocess, os.system, or equivalent functions is at elevated risk.
• Use parameterized queries for all database interactions. Never interpolate user-supplied strings directly into SQL.
• Implement a server-side content inspection layer to detect injected instructions in external content before it reaches the model context.
• Treat all content retrieved from external sources (documents, web pages, API responses) as untrusted input, even when the source appears legitimate.

Least Privilege and Scope Management

A July 2025 arXiv paper analyzing over 2,500 real-world MCP plugins found widespread evidence of over-provisioned access patterns leading to privilege escalation and data tampering risks.

• Apply least privilege to every MCP server: scope credentials to only the operations that specific workflow requires.
• Start with read-only or discovery-level scopes. Escalate only when a specific workflow demonstrates the need.
• Avoid wildcard OAuth scopes. Log all scope elevation events with correlation IDs for auditing.
• Review and reduce permissions on a scheduled basis, not only at initial provisioning.

Tool Allowlisting and Integrity Verification

Tool metadata is the attack surface for tool poisoning. Controlling which tools your agent can invoke, and verifying tool definitions have not changed, are both necessary controls.

• MCP clients should deny tool invocations by default and require explicit per-tool authorization via allowlists.
• Verify tool definition integrity at startup and on each connection by comparing cryptographic hashes of tool descriptions against a known-good baseline. Any change triggers a re-review, not automatic trust continuation.
• Require MCP server packages to be cryptographically signed. Validate signatures before installation.
• Monitor for tool description changes in connected servers. A changed description after approval requires investigation.

Session Security and Authorization

The MCP authorization specification, built on OAuth 2.0/2.1, defines the controls that prevent session hijacking, token passthrough, and confused deputy attacks at the protocol layer.

• MCP servers must verify all inbound requests. Sessions must not be used as authentication tokens.
• Session IDs must be cryptographically random (UUID-class entropy). Sequential or predictable IDs are explicitly prohibited by the spec.
• Bind session IDs to user identity using the format <user_id>:<session_id>. This prevents cross-user session abuse even if a session ID is compromised.
• Validate that tokens were explicitly issued for your MCP server. Never accept upstream tokens passed through without re-validation.
• Enforce HTTPS for all OAuth-related URLs in production. Reject http:// connections except on loopback addresses.
• Block requests to private and reserved IP ranges to prevent SSRF attacks.

Sandboxing Local MCP Servers

Local MCP servers run on your infrastructure and typically execute OS-level commands. Unrestricted, a compromised local server has access to the entire host machine.

• Run local MCP servers inside Docker containers with explicit capability restrictions. Limit volume mounts to only the directories the workflow requires.
• Apply seccomp profiles to restrict available system calls.
• Run servers as non-root users with minimal OS-level permissions.
• Use network policies to restrict which external endpoints the container can reach.
• For high-security environments, consider dedicated VMs or microVMs (Firecracker, gVisor) for hardware-level isolation.

Monitoring and Audit Logging

Without visibility into MCP server activity, detecting a breach or attributing an incident is nearly impossible.

• Log all tool invocations at the MCP server level: tool name, parameters, requesting identity, and timestamp.
• Log all credential access and scope elevation events.
• Implement anomaly detection on MCP traffic: unusual tool invocation sequences, unexpected data volumes, or calls to previously unseen endpoints are all indicators of compromise.
• Retain audit logs in an environment separate from the MCP server. Logs on the same host as a compromised server can be cleared.
• Alert on: new MCP servers connecting to your environment, tool description changes in existing servers, and any outbound connections to new external endpoints.

---

Securing MCP Configuration Files

MCP configuration files (commonly mcp-config.json, claude_desktop_config.json, or equivalent platform files) specify connected servers, authentication parameters, and tool settings. They are a frequent source of credential exposure.

Configuration Risk	Description	Mitigation
Hard-coded credentials	API keys stored in plaintext	Use environment variables; inject secrets at runtime from a secrets manager
Overly broad permissions	Server granted full file system or all API scopes	Restrict paths and scopes to workflow-specific minimums
Unverified server URLs	Remote server URLs not validated	Pin server URLs; validate against an allowlist on startup
Auto-approval of new tools	Client silently accepts changed tool definitions	Require explicit human approval for any new or changed tool
Config files in version control	Credential exposure via committed configs	Add all MCP config files to .gitignore; use pre-commit hooks
Excessive server count	Many servers connected; large aggregate attack surface	Maintain an inventory; disable inactive servers

In multi-user or shared environments, MCP configuration files on macOS and Linux often have world-readable default permissions. Restrict these to 600 (owner read/write only) to prevent local privilege escalation through credential access.

---

MCP Authorization: What the Specification Requires

The MCP authorization specification is built on OAuth 2.0 and aligns with OAuth 2.1 and RFC 9728. The following summarizes the distinction between mandatory requirements and recommendations.

Mandatory (MUST):

• Servers implementing authorization must verify all inbound requests before executing any tool.
• Sessions must not be used as authentication tokens.
• Session IDs must be cryptographically secure and non-deterministic.
• Servers must bind session IDs to user-specific information to prevent cross-user session abuse.
• MCP clients must evaluate SSRF risks when fetching OAuth-related URLs.

Strong recommendations (SHOULD):

• HTTPS for all OAuth-related URLs in production.
• Blocking requests to private and reserved IP ranges.
• Session ID rotation and expiration to limit the vulnerability window.
• Human-in-the-loop controls for tool invocations.

Known gaps (community remediation in progress):

• The current authorization specification includes implementation details conflicting with some enterprise OAuth deployment patterns. Revisions are in progress.
• The token passthrough pattern (forwarding an upstream token to a downstream service without re-validation) is explicitly called out as a risk. Avoid it in all MCP implementations.
• The authorization server and resource server concepts defined in the spec should function as separate logical boundaries even when deployed together.

---

Conclusion

MCP server security is not a future concern. The incidents, CVEs, and research from 2025 confirm the attack surface is being actively exploited. The credential hygiene problem alone, with over half of deployed servers using hard-coded static secrets, represents a systemic vulnerability across the entire ecosystem.

The security controls are well understood. Least privilege, input validation, tool integrity verification, proper OAuth implementation, sandboxing, and audit logging are all established practices. The challenge is applying them to a protocol that was initially deployed without these requirements in mind.

Start with a credential audit of every MCP configuration file in your environment. Add tool allowlisting and integrity checks as a second priority. Layer monitoring and sandboxing on top. Those fundamentals will reduce your MCP security risk materially, regardless of how the MCP ecosystem evolves.