~ 6 min read

Evaluation Framework for MCP Security Threats and Risks

share this story on
How to evaluate and categorize security threats and risks associated with Model Code Protocol (MCP) in light of recent security incidents.

In the wake of the recent MCP (Model Context Protocol) related security incidents including the notable Cursor + Jira MCP 0-click attack, GitHub MCP Server exploitation and significant vulnerabilities discovered in various MCP implementations, it is crucial to establish a comprehensive evaluation framework for assessing the security threats and risks associated with MCPs.

I’ve mapped out a structured framework that categorizes and evaluates the various security threats and risks linked to MCPs. This framework encompasses multiple dimensions including threat vectors, and potential vulnerable and threat scenarios.

Hopefully, with this framework, developers and organizations can more thoroughly analyze the threats and risks around MCP security when they adopt and roll-out its use across the company.

MCP Security Threats and Risks Evaluation Framework

In this proposed framework that I’ve put forward, I categorized security threats and risks into several key dimensions that reflect prior security incidents from supply-chain security domain and on to inherent agentic workflows for developers.

The four dimensions are:

  • Malicious MCP Servers
  • Consuming MCP Servers
  • Agent’ing MCP Servers (yes I realize I’m making up the “agenting” word here, just a hobby, won’t be something big)
  • Building secure MCP Servers

mcp security threats and risks overview

How do these dimensions break down into practical threat vectors and scenarios? Let’s explore each dimension in detail.

1. Malicious MCP Servers

Malicious MCP Servers, just like we’ve learned from malicious npm packages (and PyPI packages), can introduce a variety of threats to the systems that consume them.

How do malicious MCP servers operate and what are the potential threat vectors? Here are some key examples:

  1. Tool poisoning: Tool poisoning involves injecting malicious code or behavior into the MCP server itself as part of the tool instructions. You should actually be scanning MCP servers for tool poisoning as part of your security practices.
  2. Tool shadowing: Tool shadowing occurs when a malicious MCP server provides tools that mimic legitimate ones but perform harmful actions instead. The “shadowing” aspect refers to the deceptive nature of the malicious tool definition to appear (named) as another trusted tool. This is somewhat akin to typosquatting tools.
  3. Malicious dependencies: Malicious MCP servers may depend on other compromised or malicious MCP servers, or just regular dependencies, to propagate harmful code or behavior: Since installing MCP servers often involves reliance on package managers and dependencies, this can be a significant threat vector.
  4. Malicious post-install scripts: Given that MCP servers are often “just packages”, most commonly, npm packages, they have the inherent capability of defining and running post-install scripts. These scripts can be exploited to execute malicious code during the installation process, leading to system compromise.

2. Consuming MCP Servers

How do you consume an MCP Server today? what are the potential threats and risks associated with consuming MCP servers? Are they just like consuming open source packages from npm? How do you integrate them?

Here are a few threat vectors and scenarios to consider:

  1. Trusted upstream sources: Where are you installing the MCP Server from? There are various MCP directories including PulseMCP, Cursor.Directory and others. Are you installing an MCP Server directly from GitHub? from npm? from a Docker Hub? how do you vet authenticity, ownership, trustworthiness?
  2. Rug pulls and version pinning: MCP servers can be subject to rug pulls, where a previously trusted MCP server is suddenly removed or replaced with a malicious version. Version pinning and integrity checks can help mitigate this risk. Are you practicing this today?
  3. Local vs Remote: The risk impact varies significantly based on whether the MCP server is run locally or remotely. Local MCP servers can have more direct access to system resources, while remote MCP servers may introduce network-related vulnerabilities and data exposure risks.
  4. Authentication: How do you authenticate and authorize access to the MCP server? Are you using API keys, OAuth tokens, or other mechanisms?

3. Agent’ing MCP Servers

MCP Servers are utilized in agentic workflows (btw not only code, but also end-user common productivity like booking flights), where they can autonomously perform tasks and make decisions.

The risks laid out in this section are more about the way the MCP Servers are integrated into existing tools and workflows, commonly known as MCP Clients or MCP Hosts, per the Model Context Protocol specification.

Some of these risks include:

  1. Indirect prompt injection: Possibly the most common attack vector for agentic workflows is the security concern of context injected into a conversation, message history or otherwise consumed information by the MCP Server (or its underlying LLM). This can lead to unintended behavior, data leakage, or manipulation of the agent’s actions.
  2. Toxic Flow analysis: Toxic Flow Analysis, pioneered by Snyk security researchers (formerly Invariant Labs)
  3. Secure use of MCP server credentials: The current need for some MCP Servers to use an API token or API key credential as part of the definition of MCP Server configuration is a potential time-bomb as it is stored in plain-text on disk as part of the MCP servers configuration file.

4. Building Secure MCP Servers

MCP Servers are incredible for enabling agentic workflows. You add a new MCP Server to Claude Code, to Cursor and Qodo Command, but wait, MCP Servers are just… code, yes? So the logical conclusion is that tool, resource and other capabilities in the way that they are implemented in MCP Servers can be flawed and subject to insecure code, hence introducing security vulnerabilities.

Some note-worthy examples of types of security vulnerabilities that can be introduced when building MCP Servers include:

  1. Secure MCP code: Vulnerable MCP Tool implementation or vulnerable MCP Resource implementation can lead to security vulnerabilities. For example, an MCP Tool that executes shell commands without proper sanitization can be exploited for command injection attacks.
    1. Example evidence: SQL Injection and Bypassing “Read-Only” Mode in Xata’s MCP Server
    2. Example evidence: GitHub Kanban MCP Server Command Injection Vulnerability Threatens Developer Workflows
  2. Access control (& permissions): In continuation to the Authentication risk vector mentioned in the Consuming MCP Servers section, Access Control and Permissions are critical aspects to consider when building secure MCP Servers. Ensuring that only authorized users and systems can access and utilize the MCP Server’s capabilities is essential to prevent unauthorized actions and data breaches. Are you properly separating user data? improper authentication and authorization can lead to unauthorized access and potential data breaches.
  3. Secure dependencies: MCP Servers are often packaged and distributed via package managers like npm or uv which means they can inherit vulnerabilities from their dependencies. Regularly auditing and updating dependencies is crucial to maintaining the security of the MCP Server.