The State of MCP Security in 2025: Key Challenges and Emerging Defenses

Model Context Protocol (MCP) is becoming the standard for communication and operation between external applications, LLMs, and AI agents. Think of it like USB-C, a standard and a protocol for communication and power transfer. MCPs are also a standard for communication between large language models (LLMs) and other applications, databases, etc.

It hasn’t been a year (MCP was introduced in November 2024), and the adoption of the protocol has been great so far. We are seeing a wide adoption from giant corporations like Atlassian, AWS, Google, GitHub, Cloudflare, and Supabase. etc., they all have their MCPs available to try and download. And more enterprises are looking forward to being more AI-ready by building MCPs for their LLM stack. As of January 2025, more than 1000 community-made MCPs are available for end-users to try. Model Context Protocol is becoming the standard for enabling data in apps to communicate with LLMs.

While the hype and adoption are going great, we also need to consider the security, vulnerability, and other issues associated with MCPs. While APIs have been around for more than a decade, we’ve developed security patterns, rate-limiting, and other measures. MCPs must undergo cycles of improvement on the security front. The current goal is to discuss security issues in MCPs and raise awareness among readers.

The Core Security Challenge: The "Confused Deputy" Problem

The confused deputy is a classic security flaw that is highly relevant to MCP. An MCP server, acting on behalf of a user, might have more permissions than the user. An attacker could potentially trick the LLM into requesting that the MCP server execute with its elevated privileges, leading to unauthorized actions. For example, an LLM could be manipulated into telling a high-privilege MCP server to delete a file that the user shouldn't have been able to delete. The AI doesn't realize it's being manipulated because the malicious instructions come through normal channels like tool descriptions, user inputs, or data it reads from files.

Prompt Injection Vulnerabilities

This is a major attack vector for any LLM-based application, and MCP creates new opportunities for it. Attackers can embed malicious instructions in documents, emails, or any data that the MCP processes. When the AI reads this content, it interprets the hidden commands as legitimate instructions. Some of the common tricks for prompt injection are:

Hijack the AI's behavior: Make the model ignore previous instructions or perform unintended actions.
Data exfiltration: Trick the AI into revealing sensitive information it has access to through other MCP connections.
Trigger malicious actions: Instruct the AI to use one of its connected tools to send spam, delete data, or purchase items.

Supply Chain Risks and Unverified Third-Party Tools

Since anyone can develop an MCP server, there's a significant risk from unverified or malicious third-party tools. You can discuss the following points:

Malicious MCP Servers: Attackers could create and distribute MCP servers that appear legitimate but are designed to steal data, credentials, or execute malicious code.
Typosquatting: Similar to domain name typosquatting, an attacker could name their malicious MCP server something very similar to a trusted one, hoping users will mistakenly connect to it.
Lack of a Central Vetting Process: Unlike an app store, there isn't a universal, mandatory security review for all MCP servers. This places a heavy burden on users and organizations to vet the tools they use.

Tool Poisoning Attacks

Attackers embed malicious instructions within tool descriptions that are invisible to users but interpreted by AI models. These attacks can manipulate AI behavior to exfiltrate sensitive data, read SSH keys, or execute unauthorized system commands. The scary part is that these instructions can be hidden in any part of the tool definition, not just descriptions.

Credential and Token Exposure

MCP servers need to connect to various external services, and they often do so using API keys, OAuth tokens, and other credentials. This creates a centralized point of failure. If an MCP server is compromised, an attacker could gain access to all the credentials it stores, potentially giving them the "keys to the kingdom" to a user's or a company's various connected services (like email, cloud storage, code repositories, etc.).

Over-Privileged Access and Excessive Permissions

Developers of MCP servers might request broad permissions to make their tools as flexible as possible. This violates the principle of least privilege. An MCP server with read, write, and delete access to a user's entire email account, when it only needs to read subject lines, poses a significant and unnecessary risk.

Lack of Granular Monitoring and Auditing

Since MCP is in the early stage, it does not have robust, built-in mechanisms for detailed logging and auditing of all actions performed through it. This can make it difficult to detect malicious activity, investigate security incidents, and understand what data has been accessed or modified.

What makes this especially dangerous is that MCP servers often store tokens for multiple services all in one place. Suppose an attacker breaks into one MCP server. In that case, they potentially get access to your Gmail, Google Drive, Calendar, and everything else you've connected, creating what security researchers call a "keys to the kingdom" scenario.

What has been done so far?

A new specification was released on June 18, 2025, which introduces numerous features and clarifies that all MCP servers are classified as OAuth 2.0 Resource Servers.

Here are some of the details shared by the team on authorization:

Authorization Flow Architecture

Key Roles:

MCP Server: Acts as an OAuth 2.1 resource server
MCP Client: Acts as an OAuth 2.1 client, making requests on behalf of users
Authorization Server: Issues access tokens (may be hosted with resource server or separately)

Implementation Requirements

Authorization Servers:

MUST implement OAuth 2.1 with security measures for both confidential and public clients
MUST provide OAuth 2.0 Authorization Server Metadata (RFC8414)
SHOULD support Dynamic Client Registration Protocol (RFC7591)

MCP Servers:

MUST implement OAuth 2.0 Protected Resource Metadata (RFC9728)
MUST use WWW-Authenticate header when returning 401 Unauthorized
MUST validate access tokens and ensure they were issued specifically for them
MUST NOT accept or transit tokens issued for other resources

MCP Clients:

MUST use OAuth 2.0 Authorization Server Metadata and Protected Resource Metadata
MUST parse WWW-Authenticate headers and respond to 401 responses
MUST implement PKCE (Proof Key for Code Exchange)
MUST include resource parameter in authorization and token requests (RFC 8707)
MUST NOT send tokens other than those issued by the MCP server's authorization server

Security Requirements

Token Security:

MUST use Authorization: Bearer <token> header for all requests
MUST NOT include tokens in URI query strings
MUST validate token audience binding
MUST implement secure token storage
Authorization servers SHOULD issue short-lived access tokens

Communication Security:

All authorization server endpoints MUST use HTTPS
All redirect URIs MUST be either localhost or use HTTPS

Additional Protections:

MUST implement exact redirect URI validation
SHOULD use and verify state parameters
MUST obtain user consent for each dynamically registered client (for proxy servers)
MUST follow OAuth 2.1 security best practices

Security Best Practices shared by the MCP team at Anthropic

You can read the full specification for the security best practices shared here. It details how to implement the MCPs to avoid falling

Core Security Principles

Token Management:

MCP servers MUST NOT accept tokens that were not explicitly issued for the MCP server (avoid "token passthrough")
Always validate that tokens have the proper audience and were issued specifically for your MCP server

Authorization and Authentication:

MCP servers that implement authorization MUST verify all inbound requests
MCP servers MUST NOT use sessions for authentication
Always obtain proper user consent before accessing third-party services

Session Security

Session ID Generation:

MUST use secure, non-deterministic session IDs
SHOULD use secure random number generators (avoid predictable or sequential identifiers)
Consider rotating or expiring session IDs to reduce risk

Session Binding:

SHOULD bind session IDs to user-specific information
Use key formats like <user_id>:<session_id> to prevent impersonation
Combine session data with information unique to the authorized user

Proxy Server Security

Consent Management:

When using static client IDs with third-party services, MUST obtain user consent for each dynamically registered client
Implement proper consent flows to prevent confused deputy attacks

Implementation Guidelines

Security Controls:

Implement proper rate limiting, request validation, and traffic monitoring
Maintain clear audit trails and accountability mechanisms
Validate token claims (roles, privileges, audience) and metadata
Preserve trust boundaries between services

These practices are designed to prevent the three main attack vectors identified: confused deputy problems, token passthrough vulnerabilities, and session hijacking attacks.

Recent Security Issues for MCPs

The community has reported numerous security issues affecting top companies like GitHub and Supabase. These issues highlight that, despite its rapid adoption, the protocol's security is still maturing and requires immediate and careful attention from all developers.

GitHub MCP Exploit: The GitHub MCP exploit was discovered in May, allowing unauthorized access to private repositories and the ability to exfiltrate sensitive information. You can read about it in detail here.
Supabase MCP: The Supabase MCP was found to leak all of your private SQL database. Read the Hackernews discussion and the original article, showcasing the attack.
Asana MCP Workspace Data Leak: Asana’s MCP allowed users to look into other users’ workspaces. The company took two weeks to fix the issue, ensuring it doesn’t happen again. You can read about the fix and the incident here.
SQL Injection & Privilege Escalation: A single SQL injection bug in Anthropic’s SQLite MCP server (forked 5,000+ times) has enabled attackers to inject stored prompts, exfiltrate data, and escalate privileges within production agents. Many downstream agents, due to the use of unpatched code, remain vulnerable, amplifying both supply-chain and agent-wide compromise risks. Read about this here.
Command Injection in mcp-remote Proxy (CVE-2025-6514): JFrog researchers revealed a critical (CVSS 9.6) vulnerability in the popular mcp-remote project, used for integrating LLM hosts like Claude Desktop with remote MCP servers. A malicious MCP server can supply a crafted authorization endpoint to the client, resulting in arbitrary OS command execution on Windows and arbitrary executable run on Linux/macOS. The vulnerability affects mcp-remote versions 0.0.5–0.1.15 and is now fixed in 0.1.16. Users connecting to untrusted or insecure MCP servers are most at risk. Read about this here.

There are many more instances like these, where MCPs can result in new security vulnerabilities.

Conclusion

While the adoption of Model Context Protocol (MCP) is accelerating, it's crucial to address its inherent security risks. Vulnerabilities like prompt injection and token exposure can undermine the protocol's integrity. The new security specifications, based on OAuth 2.0, provide the necessary tools for defense. Ultimately, the long-term success of MCP hinges on developers consistently implementing these security best practices to create a safe and reliable ecosystem.