MCP security hot potato

Introduction

Model Context Protocol (MCP) is the new shiny thing everyone is talking about. Every company wants its API to be available via MCP so LLMs can access it. Most companies either already have some MCP servers in place or plan to implement them.

As usual, it comes with a ‘feature first, security comes later attitude’. More than a decade in application security has taught me the ‘Path of AppSec’ that all major technologies must follow.

First – a disruptor appears (LLM in this case, followed by MCP protocol). 

Second – there is a lot of new code being written (MCP servers and clients) and written quickly, so there will be security issues. 

The given technology gets a spotlight, and mass adoption follows. Somewhere here, the security research gets on stage, and those security vulnerabilities are found, lots of them. 

Then, in the end, those vulnerabilities are fixed, and the technology gets mature, let’s say.

The same thing happened with the cloud providers and their services, by the way.

Connect with the author on LinkedIn!

MCP core concepts

The Model context protocol was created by Anthropic on 25th November 2024: https://www.anthropic.com/news/model-context-protocol

It is meant to simplify and standardize how LLMs interact with external components (files, resources, APIs). It can work on the same machine (over stdio) and remotely via good old HTTP.

We have two players here: the MCP server, which basically provides the API through so-called capabilities, and the MCP client, which can interact with a given server. Applications or tools such as Visual Studio Code or Cursor are MCP hosts that can host multiple MCP clients.

MCP defines three capabilities that the MCP server can provide: resources, tools, and prompts. 

Resources can be files, APIs, databases, or other data sources. The protocol defines 4 quite straightforward API methods to interact with the resources:

• resources/list
• resources/templates/list
• resources/read
• resources/subscribe

Resource templates allow the exposure of parametrized resources based on the URI, where arguments can be auto-completed for the sake of usability.

Next, we have tools meant to be invoked by LLMs, providing the possibility to interact with external systems. Basically, tools allow an API call with JSON containing parameters as input, which ends with JSON returned as output.

Available API:

• tools/list
• tools/call

Also, no surprises here.

The third possibility is prompts, which are reusable templates that demonstrate how the MCP server’s other capabilities should be used. These are meant to be used by the end user, who can list and customize available prompts.

API:

• prompts/list
• prompts/get

More details about the protocol can be found here: https://modelcontextprotocol.io/specification/2025-11-25

Vulnerable vs. malicious

We can have vulnerable MCP servers. It’s an API in the end, fancy yes, but an API.

We, of course, can have vulnerable MCP clients. 

And obviously, we can have malicious MCP clients. If you have public facing API, you know.

What’s interesting in the case of MCP is that we can also have malicious MCP servers. This is because MCP lists server capabilities dynamically (resources/list, tools/list, prompt/list), and the implementation can change between 2 calls. This brings new vulnerability classes to the table.

If someone hacks your API, they can do the same, but usually it’s not the case.           

Vulnerable MCP servers

Here we see good old API vulnerabilities reborn. RCE, Command Injection, SSRF, Information Disclosure… Pick a vulnerability name, and you will find the MCP server being vulnerable to it.

Here is just a bunch of CVEs from 2025:

CVE-2025-53100 – Command Injection in codehooks-mcp-server MCP Server

CVE-2025-59834 – Command Injection in adb-mcp MCP Server

CVE-2025-54994 – Command Injection in MCP Server due to unsafe `exec` API 

CVE-2025-53818 – GitHub Kanban MCP Server vulnerable to Command Injection

CVE-2025-52573 – iOS Simulator MCP Command Injection allowed via exec API 

CVE-2025-53107 – Command Injection in @cyanheads/git-mcp-server (several tools)

CVE-2025-53967 – Command Injection in Framelink Figma MCP Server

Vulnerable MCP clients

In the case of MCP clients and the application that uses those clients, using the MCP server may backfire. I would say most cases are related to the data validation issues – either missing or not strict enough (think injection vulnerabilities).  

Here are three interesting examples: 

CVE-2025-6514

A mcp-remote tool is exposed to OS command injection when connecting to untrusted MCP servers due to crafted input from the authorization_endpoint response URL. To simplify, it’s spawning a new child process with the authorization_endpoint value as a parameter.

https://research.checkpoint.com/2025/cursor-vulnerability-mcpoison/

CVE-2025-49596

Another interesting case is MCP Inspector CVE-2025-49596, where we have two issues:

• possibility to make a CSRF attack on 0.0.0.0, here more info about this problem: https://www.oligo.security/blog/0-0-0-0-day-exploiting-localhost-apis-from-the-browser
• https://localmess.github.io/
• MCP Inspector proxy listens on 6277 port for commands without any authentication

When the developer who runs MCP Inspector will visit a malicious site, this CSRF will trigger and cause OS command execution on developer’s machine.

Very similar issue (CVE-2026-23744) was discovered in MCPJam inspector recently:

https://github.com/MCPJam/inspector/security/advisories/GHSA-232v-j27c-5pp6

Here, there is no need for CSRF.

Exposing an API locally without authentication is never a good idea.

MCP Poison

This is the first MCP issue with a catchy name and logo, CVE-2025-54136. The issue was discovered in the Curson IDE. 

https://research.checkpoint.com/2025/cursor-vulnerability-mcpoison/

Each time a project is opened, Cursor scans for the MCP configuration and requires the user to approve it, but there is no required user approval when given a previously approved configuration that has changed. If someone modifies that in a malicious way and such a project is opened in Cursor, then the malicious stuff could silently execute.

Malicious MCP server 

This is where things get interesting. 

First, the MCP server can be a source of direct and indirect prompt injections. That’s because either the capabilities description returned to a MCP client or the results of the use of those capabilities by the client. Input validation 101.

The one with a description in case of a MCP tool is called Tool Poisoning. The payload (malicious instruction) is placed in the tool description (it may be invisible to the end user), and it can execute an event before the malicious tool gets called.

Interesting consequence of the MCP protocol behavior, which lists capabilities on the fly, is that the MCP behavior may be changed to malicious between tor example, two tools\list calls. So we think we’ve integrated a legitimate MCP server. We’ve reviewed the tool descriptions, and the first time we try to use that MCP server, the tool descriptions get flagged as malicious. This behavior is called Rug Pul.

Last, but I think the most interesting case, is Tool Shadowing, where we consider two MCP servers connected to a Cursor, for example, with one of them being malicious. The malicious one can apparently affect how Cursor uses tools from the benign MCP server. How cool is that?

See more details here:

https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks

Summary

So, what to do, how to survive?

First, acknowledge the state of MCP as a technology – it’s still in the cradle, still developing and growing, and security research is ongoing, so new high-risk issues may arise. 

Be sure to follow the protocol specification.

Be ready to update MCP related stuff quickly.

Do code review, update libraries with known issues, run penetration testing, and all the usual stuff you do when it comes to the security API; this is no different. Stay secure!

This article is a summary of my talk at the Germany OWASP Day 2025 – and if you prefer to watch rather than read, the video is available as well.

For over 20 years, Securing has been helping the finance industry safeguard apps, networks, and services. If you’d like to discuss the security of your product or service, simply book a call or complete our contact form – we’ll get back to you shortly.

Mateusz Olejarka Principal IT Security Consultant
Head of Web Security