MCP Server Pentesting: How to Test the Attack Surface Your AI Agents Just Opened Up

Your MCP servers are internet-facing, credential-bearing, command-executing infrastructure — and most of them have never been tested by a human. Here's what MCP server penetration testing actually involves, and why your existing web app pentest didn't cover any of it.

Key takeaways

• A February 2026 NVD search for "MCP" returned 116 CVE records, of which researchers identified 35 as directly affecting open-source MCP servers — and three of those were in Anthropic's own reference implementation, published on a single day in January.
• Endor Labs' static analysis of 2,614 MCP implementations found 82% use file system operations prone to path traversal (CWE-22), 67% use APIs related to code injection, and 34% use APIs related to command injection. These are code patterns awaiting a trigger, not confirmed exploits — which is precisely why they need a human to assess.
• Only about 8.5% of MCP servers use OAuth, and 53% rely on long-lived static API keys or personal access tokens — per Astrix Security's October 2025 audit of 5,200+ MCP servers — despite OAuth 2.1 with PKCE being mandatory for remote servers since the November 2025 spec revision.
• Automated MCP scanners are noisy. In one April 2026 audit of 33 servers, only 6 of 27 scanner detections were genuine — the rest fired on ordinary tool documentation. Scanning is triage, not assurance.
• The 2026-07-28 specification — the largest MCP revision since launch, and one containing breaking changes — removes protocol-level sessions and hardens authorization. Every remote MCP server in production needs re-testing against it.

What is an MCP server, in security terms?

The Model Context Protocol (MCP) is the open standard that lets AI models call external tools, read data sources and act on live systems through a single, uniform interface. An MCP server is the component that exposes those tools.

Strip away the AI framing and look at what you've actually deployed:

• An API endpoint that accepts instructions and returns data.
• A credential holder — it usually carries the tokens, keys or database connections needed to do real work.
• A command executor — the primary local transport, STDIO, spawns subprocesses by design.
• A trust boundary that a language model decides how to cross, based on text it reads at runtime.

That last point is the one that breaks conventional threat models. In a normal API, the caller is code you wrote. In an MCP deployment, the caller is a model whose next action is influenced by whatever content it just ingested — a Jira ticket, a support email, a README, a web page. Tool descriptions and returned data are attacker-influenceable inputs, not documentation.

The ecosystem scaled faster than anyone reviewed it. Anthropic reported 97M+ monthly SDK downloads and over 10,000 active public servers in its December 2025 ecosystem update. A separate pull of the official MCP registry API in May 2026 counted roughly 9,650 server records — a lower figure, but not a shrinking ecosystem: the registry API and Anthropic's broader estimate use different inclusion criteria, and the wider aggregator landscape (including some 15,900 GitHub repositories tagged as MCP servers) runs well past both numbers. Endor Labs recorded weeks in which more than a thousand new MCP servers were created. Security review did not scale at the same rate.

Why your last penetration test did not cover this

Most organisations we speak to have a recent web application or cloud pentest, and reasonably assume the MCP layer is inside that scope. It almost never is. Standard scopes miss MCP for four structural reasons:

• The vulnerability lives in semantics, not syntax. A tool description that quietly instructs the model to also send a copy of every file to an external endpoint is valid JSON, passes schema validation, and looks fine to a SAST engine. It is malicious in meaning only.
• Authorisation is enforced at the wrong layer. The protocol has repeatedly pushed enforcement onto implementers. Your gateway sees a well-formed request with a valid token; it cannot see that the agent is combining three individually authorised tool calls into a data exfiltration pipeline.
• The exploit path crosses systems. Injected instructions land in system A (a ticket, an inbox), the agent reads them, and the damaging action happens in system B (a repo, a database). Two separately scoped assessments will each declare their side clean.
• The target moves weekly. A point-in-time test ages badly here. Tool metadata changes, servers get added to a config file by a single developer, model versions shift, and the effective attack surface changes without a deploy.

Real disclosures already follow this shape:

• Anthropic's own mcp-server-git picked up three CVEs published on a single day in January 2026 (CVE-2025-68143/68144/68145): a repository boundary that was never validated, and user-controlled arguments passed straight to the Git CLI. This is reference code that developers are meant to replicate.
• The Framelink Figma MCP server (CVE-2025-53967) carried a command injection in its fetch logic, in a server with over 600,000 downloads — exploitable by planting instructions in a Figma file that a coding assistant would later read.
• mcp-remote (CVE-2025-6514, CVSS 9.6, disclosed by JFrog in July 2025) allowed OS command execution when a client connected to a malicious server, via a crafted authorisation endpoint URL. It had over 437,000 downloads at disclosure. Note the direction of travel: the client was compromised by the server. Trust runs both ways in MCP, and both directions need testing.
• EchoLeak (CVE-2025-32711, CVSS 9.3, disclosed by Aim Security in June 2025) proved zero-click indirect prompt injection could exfiltrate data from a production AI assistant. It was a Microsoft 365 Copilot flaw rather than an MCP one, and Microsoft patched it server-side with no known exploitation in the wild — but it established that the attack class works outside a lab.

None of these were exotic. Unvalidated paths, unsanitised arguments, and blind trust in text arriving from somewhere else.

The MCP attack surface, mapped

Two frameworks give this shared vocabulary, and we map every finding to both: the OWASP MCP Top 10 (MCP01–MCP10), covering protocol-layer issues from token mismanagement to shadow servers, and the OWASP Top 10 for Agentic Applications 2026 (ASI01–ASI10, published December 2025), which classifies agent-level risks such as Agent Goal Hijack, Tool Misuse, Identity and Privilege Abuse, and Rogue Agents.

The MCP Top 10 is currently at Phase 3 — beta release and pilot testing. The categories are stable enough to work from, but the rankings may still move. We track it and tell you when a mapping changes.

Our MCP server penetration testing methodology

We run MCP engagements in seven phases. Testing is manual and adversarial, supported by tooling rather than driven by it.

1. Inventory and attack surface discovery. Enumerate every MCP server your agents can reach — including the ones added to a developer's local config and never reviewed. Build an AI bill of materials: servers, tools, models, credentials, provenance. Most engagements surface servers the security team did not know existed.
2. Protocol conformance and transport review. Verify spec version, transport configuration, exposure, origin and TLS handling, and behaviour under malformed and out-of-order messages. Servers that deviate from the specification tend to deviate in exploitable directions.
3. Authentication and authorisation testing. Test OAuth 2.1 implementation properly: PKCE with S256, Protected Resource Metadata discovery (RFC 9728), Resource Indicators so a token minted for one server cannot be presented to another (RFC 8707), issuer validation on authorisation responses (RFC 9207), token lifetime and scope enforcement. This is where we most often find critical findings, because it is where the specification has moved fastest.
4. Tool inventory and poisoning analysis. Review every tool description as untrusted input: hidden instructions, unicode and comment-based concealment, schema looseness, name collisions with trusted tools, and — critically — whether descriptions can change after user approval without re-consent.
5. Implementation exploitation. Conventional application security work against tool handlers: traversal, injection, SSRF, secret exposure, unsafe deserialisation. Every finding is verified against a live target and reproduced, so you receive confirmed vulnerabilities rather than scanner output.
6. Agentic red teaming. The phase that distinguishes an MCP pentest from an API pentest. We attempt goal hijack through injected content in the systems your agent reads, chain individually-authorised tool calls into unauthorised outcomes, test cross-server interference, and probe whether persisted context can carry attacker instructions into future sessions.
7. Detection and blast-radius assessment. For each successful path, we determine whether your logging would have caught it and how far the compromise could have spread. A finding you can detect and contain is a very different business risk from one you cannot.

Why scanning alone won't give you assurance

Open-source and commercial MCP scanners are genuinely useful for inventory and known-CVE triage, and we use them in phase 1. They are not an assessment.

An April 2026 independent audit ran two popular open-source scanners across 33 MCP servers and 433 tools. They flagged 27 patterns across 10 servers. On manual review, only 6 were genuine security concerns — a false-positive rate around 78% on a small but instructive sample.

The reason is worth understanding, because it generalises. One scanner flagged a widely used server for prompt injection because its tool descriptions say a particular function must be called first. That is not an attack; it is how well-written MCP tools declare a dependency between them. The rule matched the phrasing, not the intent.

Two consequences follow. First, someone has to validate every alert, and the volume erodes trust in the tool until it gets switched off. Second, and more serious: pattern matching cannot catch sequence-level attacks, where each individual tool call is authorised and legitimate and the exploit exists only in the combination. That class requires a human adversary who understands both the protocol and your business logic.

The 2026-07-28 spec makes retesting urgent

The MCP specification dated 28 July 2026 is the largest revision since the protocol launched. It removes sessions and the initialisation handshake in favour of a stateless core, deprecates Roots, Sampling and Logging, introduces a formal extension framework, and substantially rewrites authorization to align with how OAuth 2.0 and OpenID Connect are actually deployed.

Six authorization SEPs land in this revision. The ones with direct security consequences:

• Clients must validate the iss parameter on authorization responses per RFC 9207. The maintainers describe this as mitigating a class of mix-up attack that is more prevalent in MCP's single-client, many-server deployment pattern — which is to say, the normal way MCP is deployed.
• Clients bind registered credentials to the issuing authorization server's issuer, and must re-register when a resource migrates between authorization servers.
• Clients now declare their OpenID Connect application_type during Dynamic Client Registration.
• Scope accumulation during step-up authorisation and the .well-known discovery suffix are both clarified — ambiguity in either is where inconsistent enforcement lives.

Alongside these sit requirements that are not new but that most deployments still fail: Protected Resource Metadata for authorization server discovery (RFC 9728) and Resource Indicators (RFC 8707), so that a token minted for one server cannot be presented to another. Both have been required for remote servers for roughly a year. With OAuth adoption at 8.5%, "it's been mandatory for a year" and "it's implemented" are clearly different statements.

The migration risk is concentrated in the stateless rework rather than the deprecations. Roots, Sampling and Logging are annotation-only deprecations — they keep working for at least twelve more months. But removing protocol-level sessions changes how identity and state are carried on every single request, and that is exactly the kind of change that quietly relocates an authorisation check. If your servers were tested before this revision, that report describes a protocol you are about to stop running.

"With OAuth adoption sitting at 8.5%, most MCP deployments haven't even cleared the bar the spec set a year ago — let alone the one it just raised."

What you get from an engagement with ComplyArmor

• Verified findings, not raw output. Every vulnerability is reproduced against a live target with proof of exploitation, business impact and a remediation path.
• Framework mapping. Findings mapped to OWASP MCP Top 10 and OWASP ASI Top 10 for audit, board and customer-assurance use.
• An AI bill of materials. A living inventory of every MCP server, tool and credential your agents can reach.
• Detection gap analysis. Which attack paths your current logging and monitoring would miss.
• Free retest after remediation. Fixes are verified, so you can show a clean result rather than an open finding list.
• Developer-ready remediation. Specific configuration and code guidance, plus a review session with your engineers.

Typical scope and effort

MCP security checklist you can run this week

Before you engage anyone, these five checks cost nothing and frequently find something:

1. Inventory every MCP server your agents can reach, including local developer configs. You cannot secure an undocumented server.
2. Confirm nothing is publicly reachable that does not need to be. Bind local servers to localhost and validate origin headers.
3. Check OAuth status on every remote server. If it is not implementing OAuth 2.1 with PKCE, treat it as unauthenticated.
4. Audit tool permissions against least agency. Not least privilege — least agency. Grant the minimum autonomy and tool access the task requires, and remove standing broad credentials.
5. Verify you have a kill switch and that your logs record tool call sequences, not just individual calls.

Frequently asked questions

If you have deployed AI agents in the last eighteen months, you have production infrastructure that holds credentials, executes commands and takes instructions from a model — and it probably has never been tested by a human adversary.