MCP Server Security Assessment: How We Pentest Model Context Protocol Servers

An MCP server security assessment is a penetration test of the Model Context Protocol servers that connect your AI agents to real systems. We test authentication and token handling, every tool’s inputs and outputs, tool descriptions, the transport, and the client side, because an MCP server is a privileged API that a manipulable language model drives on your behalf.

That last point is the whole story. A normal API trusts its caller to be a program you wrote. An MCP server’s caller is a model that will follow instructions hidden in any text it reads, including the text your own server returns. So an MCP test has to cover classic API flaws and the new ways a model can be steered into misusing them.

Why are MCP servers such a high-value target?

Because they hold the keys. An MCP server for your ticketing system, cloud account, Git host or API gateway typically has a token with real permissions. Whoever can steer the agent can borrow those permissions.

The public CVE record already shows what goes wrong:

Sources: OSV record for CVE-2026-13341 (advisory GHSA-7767-3m3w-2p44), The Hacker News on the Git MCP server flaws, and NVD-derived records for the mcp-remote and Inspector CVEs. Note that some aggregators describe CVE-2026-13341 as remote code execution; the vendor and NVD description is unintended API requests via indirect prompt injection, which is what we cite.

Look at the spread. One server-side injection bug, one set of classic argument and path bugs, one client-side bug, and one developer-tool bug. A useful MCP penetration test has to cover all four zones.

How do we pentest an MCP server, step by step?

We run MCP tests as part of our APEX methodology, which already includes an MCP server inventory in its Surface phase. Here is how an engagement breaks down.

1. Inventory and threat model

We list every MCP server the agent can reach, whether it runs locally (stdio) or remotely (HTTP), what each tool does, which credentials it holds, and what data each tool returns to the model. The key question for every tool: can anyone outside your organisation influence the text this tool returns? If the answer is yes (tickets, emails, web pages, logs, analytics, Git issues), that tool is an indirect prompt injection channel.

2. Authentication and token handling

For remote servers we test the OAuth flow against the MCP specification. The spec’s security best practices explicitly forbid token passthrough, where a server accepts a token not issued for it and forwards it downstream. We check:

• Does the server validate the token audience, or will it accept a token minted for another service?
• In proxy servers using a static client ID, can a confused deputy flow send an authorisation code to an attacker’s redirect URI?
• Can a session ID be guessed, replayed or reused across users (session hijacking)?
• Are scopes the minimum each tool needs, or does one token unlock everything?

3. Tool input testing

Each tool parameter is an API input, so we fuzz it like one: path traversal, argument injection, command injection, SSRF through URL parameters, and injection into downstream queries. The Git MCP server bugs are the textbook case: tool arguments passed straight into a library call without validation. Then we test whether the model can be talked into sending those payloads, because in production the model fills the parameters, not the user.

4. Tool output and indirect prompt injection

This is where CVE-2026-13341 lives. We plant instructions in every data source a tool returns (a ticket comment, a log line, an API response, a README) and watch whether the agent treats that content as instructions. We test for unintended tool calls, data exfiltration through tool parameters, and chained actions across servers.

5. Tool description and supply chain review

Tool descriptions are read by the model as instructions. A malicious or compromised server can hide directives in a description, a pattern researchers have called tool poisoning. We review descriptions for hidden instructions, check whether descriptions can change after approval, and look at where third-party servers come from, how they are pinned, and who can update them.

6. Client and developer environment

CVE-2025-6514 and CVE-2025-49596 are reminders that the client side and developer tooling are part of the attack surface. We check client versions, local proxies, exposed debugging tools, and whether a developer connecting to an untrusted server can be compromised.

7. Reporting and retest

Every finding gets a severity, a reproduction, the agent conversation that triggered it, and a fix. We map findings to the OWASP LLM Top 10 and the OWASP Top 10 for Agentic Applications, then retest after fixes.

What does an MCP security checklist look like?

Who needs an MCP security assessment?

Three groups come to us most often:

• Teams shipping internal agents that connect to Jira, GitHub, cloud consoles or databases through MCP. One poisoned ticket should not be able to push code or read secrets.
• SaaS vendors publishing an MCP server for customers. Your server will run inside other people’s agents, so your input validation and output handling are now your customers’ security problem too.
• Regulated firms under CBUAE, DFSA or VARA expectations, and vendors building for Dubai government, where agent tools touch customer or citizen data. See our Dubai government agentic AI checklist.

If you run an AI gateway or proxy in front of your models, the LiteLLM credentials leak write-up covers the neighbouring risk.

How is an MCP test scoped and priced?

We scope per server and per trust boundary. A single internal MCP server with a few tools is similar in effort to a single-application LLM test, which our penetration testing cost guide puts at AED 40,000-80,000 in the UAE market. Multi-server platforms, remote OAuth servers and agents that chain tools across systems move toward agentic red team pricing. Our AI red teaming cost guide explains the drivers.

Book a fixed-scope MCP security assessment

pentest.ae offers a fixed-scope MCP server security assessment: one MCP server (or one client plus its connected servers), tested across authentication, tool inputs, tool outputs, descriptions and client exposure, with first findings in 48 hours and a retest included. For broader agent platforms we fold MCP testing into the agentic red team exercise.