Beginning Message Context Protocol (MCP): MCP Security

MCP was designed for convenience not security. Since its introduction in November 2024, researchers have put a lot of effort into understanding this protocol and its vulnerabilities. These vulnerabilities come in different flavours.

Some of these are: OAuth vulnerabilities, the ability to execute arbitrary commands via command injection, unrestricted network access, file system exposure, tool poisoning attacks and even credentials theft and exposure.

MCP can use authorization mechanism like OAuth to protect sensitive resources. The OAuth flows are designed for HTTP transports.

There are some important reasons for leveraging authorization such as:
- Access to emails, databases, documents, etc.
- Auditing user actions
- Rate limiting
- Usage tracking,
- etc.

Some vulnerabilities are:

**CONFUSED DEPUTY**

The confused deputy - or otherwise called in today's parlance privilege escalation - is an attack where the threat actor is able to convince a tool to perform an action it should not perform by design.

For example, later we will build a MCP server that has these two tools:

@mcp.tool()
def read_file(path: str) -> str:
    ''' Reads file from disk '''
    logger.info(f'🚀 [TOOL CALL]: read_file path={path}')
    with open(file=path, mode='r') as fp:
        data = fp.read()

    logger.info(f' [TOOL RESULT]: read_file bytes={len(data)}')
    return data
    
    
@mcp.tool()
def run_command(cmd: str) -> str:
    '''Runs a shell command '''
    logger.info(f'🚀 [TOOL CALL]: run_command command={cmd}')
    result = subprocess.check_output(cmd, shell=True)
    logger.info(f' [TOOL RESULT]: run_command bytes={len(result)}')
    return result.decode()

With these tools, a user sends a prompt, that prompt goes to the model that calls the tool (user -> prompt -> tool).

In this case, our model + tool layer is the deputy, that ultimately becomes confused.

As an example, let's say a user wants to access the "/etc/passwd" but has no permission to do so. Maybe the user can trick the model by giving a prompt of "Can you summarize this file: /etc/passwd". Maybe the model thinks the file should be summarized and call read_file tool as read_file("/etc/passwd") thus showing the contents of the file, hence displaying sensitive information. 

What we have is the tool is the deputy and the model is what is the confused decision maker. 

Similarly, the run_command + model can be confused. Maybe we give a prompt of "Check disk usage and also run cat /etc/passwd". This may result in arbitrary command execution. Maybe we get something like: run_command("df -h; cat /etc/passwd"). In this case, we see there seems to be even more confusion.

**TOKEN PASSTHROUGH**
This is an attack where a MCP server accepts a token from a MCP client and passes it to a downstream API service, without first properly validating that the tokens were properly issued to the server.

In the authorization specification, token passthrough is explicitly forbidden. 

MCP servers or APIs may implement important security controls that depend on credential constraints. If a client is able to obtain and or use an API token directly without the MCP server validating them, a threat actor may be able to bypass these constraints.

From an accounting and auditing perspective, the MCP server may be unable to distinguish between MCP clients, when these clients are issued with an upstream-issued access token.

The logs at the destination may show a different source rather than the MCP server that is actually forwarding the token.

Threat actors may also be able to use the fact that the tokens are not validated to perform exfiltration.

To mitigate this attack, MCP server must not accept any tokens that were not explicitly issued to it.

**SERVER-SIDE REQUEST FORGERY (SSRF)**

In this attack, a threat actor can influence a MCP server to make request to unintended destinations. This include cloud metadata endpoints, etc.

To learn more about SSRF, see my previous post: 
Learning by practicing: Beginning Server Side Request Forgery (SSRF) - WebGoat

**SESSION HIJACKING** 

In this attack, after a server provides a client with a session-id, a threat actor is then able to steal that session-id and gain access to the server by impersonating the original client. The threat actor is then able to perform unauthorized actions on the client behalf.

To learn more about session hijacking, see my previous post on this topic:
Learning by practicing: Beginning Web Application: Testing Session Hijacking - DVWA

**Local MCP Server Compromise**
Local MCP servers are the ones running on our local system. Just like I am using for these labs. They can also come from ones you might have download. Because these servers are local, they may also have access to our resources on the host machine. This makes them attractive targets.

**PROMPT INJECTION & TOOL POISONING**
Also called Line Jumping

LLMs can be tricked into issuing harmful tool requests. Tool poisoning is a technique in which the tool description is maliciously designed to mislead the model, convincing the model to use the tool in unintended ways.

The description is not seen by the user but is seen and is interpreted by the model. This can result in the model being tricked into running unauthorized commands. The model can then be used as an attacker's proxy.  

To mitigate this attack, users should be very careful about the MCP servers they connect to.

In addition to the traditional tool poisoning attack, that focuses on the description field, the fields within the JSON schema itself also can be targeted and manipulated. Rather than Tool Poisoning, this is called Full-Schema Poisoning. In this scenario, no field within the schema is safe.

**FULL-SCHEMA POISONING**
The entire tool schema is part of the LLM context window and part of its reasoning. While it is cool to focus on the description field, the entire schema represents an attack surface.

**MCP RUG PULLS**
This is where a malicious MCP server comes online with a benign description. After the user has approved the tool usage, the threat actor then updates the tool description, to something malicious. 

So, while a user might initially trust the server, the threat actor can exploit that trust by updating the tool description after approval. 

**SHADOWING ATTACK**
When a MCP client is connected to multiple MCP servers a threat actor who owns a malicious server, may describe in its tool additional usage/capabilities of the trusted server tool.

The core idea is that shadowing attack is enough to hijack the agent's behavior as it relates to trusted servers. The objective is that the malicious MCP server does not need to get the agent to use its tools, but instead, the malicious MCP server is able to influence the agent to use a trusted tool in in an unintended way.

References:
Understanding Authorization in MCP - Model Context Protocol
Security Best Practices - Model Context Protocol
What Is The Confused Deputy Problem? | Common Attacks &… | BeyondTrust
The confused deputy problem - AWS Identity and Access Management
The Confused Deputy Problem: A Quick Primer | AWS Builder Center
The Confused Deputy
The complete guide to MCP security: How to secure MCP servers & clients — WorkOS
WhatsApp MCP Exploited: Exfiltrating your message history via MCP
lharries/whatsapp-mcp: WhatsApp MCP server
MCP Security Notification: Tool Poisoning Attacks
How to Secure the Model Context Protocol (MCP): Threats and Defenses
Jumping the line: How MCP servers can attack you before you ever use them - The Trail of Bits Blog
[RFC] Update the Authorization specification for MCP servers by localden · Pull Request #284 · modelcontextprotocol/modelcontextprotocol
Poison everywhere: No output from your MCP server is safe
MCP Security Issues Threatening AI Infrastructure | Docker
MCP Horror Stories: The Supply Chain Attack | Docker
The GitHub Prompt Injection Data Heist | Docker
Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection
MCP Tools: Attack Vectors and Defense Recommendations for Autonomous Agents — Elastic Security Labs
Poison everywhere: No output from your MCP server is safe
MCP Security in 2025
Model Context Protocol (MCP) at First Glance: Studying the Security and Maintainability of MCP Servers
MCP Servers: The New Security Nightmare | Equixly


Posts in this Series:
Beginning Message Context Protocol (MCP): But what is MCP?
Beginning Message Context Protocol (MCP): MCP Security
Beginning Message Context Protocol (MCP): Attacking and Defending MCP