MindFort now pen tests MCP servers. You add your server as a target, and swarms of AI agents test it like an attacker would. They check auth and sessions, abuse each tool for injection, SSRF, and file access, and test whether an AI client can be steered into leaking data. Every finding comes with a working exploit.
MindFort now pen tests MCP servers. Add your server as a target, and swarms of AI agents test it end to end. They check its auth, abuse its tools, and test what an AI client can be tricked into doing through it. Each finding is proven with a working exploit.
We know MCP from both sides. Our own platform runs an MCP server that customers connect to from Claude Code, Cursor, and Codex. Below, we cover why MCP servers have become a target in 2026, why they are hard to test, and how our agents do it.
Why are MCP servers a target in 2026?
Because adoption outran security. The Model Context Protocol launched in November 2024. It now connects AI apps to databases, code hosts, ticketing, and cloud APIs. Every one of those connections is a new door.
Reported flaws have exploded. One count found 90 MCP vulnerability advisories in all of 2025 and 686 in the first nine months of 2026. 60% were rated critical or high (host0 ).
Published MCP vulnerability advisories
Public security advisories for MCP servers, SDKs, and clients. 2026 covers January to September. Source: host0, MCP security in 2026.
Many servers are wide open. A November 2026 scan of the official MCP registry found that 55.7% of remote servers answer without any login. 102 of them offered command execution or file access to anyone (mcpprobe ).
Remote MCP servers in the official registry
Share of servers with each issue. The second bar is servers whose tools read private data, take in untrusted input, and can send data out, a risky mix but not a proven attack. Source: mcpprobe, State of MCP server security, November 2026.
What recent MCP attacks should teams know about?
Attackers are already exploiting MCP flaws, and they move fast once a fix ships.
| Incident | What happened | Source |
|---|---|---|
| MCPwnfluence (mcp-atlassian) | Two bugs chained into remote code execution on servers that took requests without auth. A working exploit hit a cybercrime forum 20 days after the patch, and six days after the CVEs reached NVD. | Pluto Security |
| Grafana MCP server (Aug 2026) | A forged session ID let attackers call tools with the server's Grafana service account. An SSRF bug then reached internal systems and cloud metadata. CVSS 9.1. | CSA |
| Official MCP SDKs (Sep 2026) | A malicious MCP server could make clients built on either official SDK send their OAuth secrets and codes to the attacker. That meant full account takeover. | Cycode |
| Langflow (Sep–Oct 2026) | Any signed-in user could add an MCP server whose command ran on the host. Honeypots logged 1,423 exploit attempts from 27 IPs. | OSINTsights |
| MCP Inspector and opencode (Oct 2026) | A remote MCP server could run code on a developer's machine through a crafted OAuth sign-in URL. No prompt injection was needed. | Corgea |
Most of these are not exotic AI attacks. They are missing auth, SSRF, path traversal, and command injection, the same bugs we find in web apps and APIs. They just sit behind a new protocol that most security tools don't speak.
Why is MCP server testing so hard?
Because an MCP server is two targets at once.
- It is a network service. It speaks JSON-RPC over HTTP, with its own sessions and its own OAuth flow. Auth is optional in the spec, and many servers ship with it off. Web scanners don't know how to start an MCP session, list tools, or call them.
- It is input to an AI model. Tool names, descriptions, and results all go into the model's context. A poisoned description or a malicious result can steer the model into calling other tools. In the MCPTox benchmark, poisoned tool descriptions worked 36.5% of the time on average across 20 model settings (host0 ).
The worst bugs live where the two meet. One tool reads private data. Another fetches untrusted content. A third can send data out. Each looks safe alone. Chained together by a model, they leak your data. You can only find that by testing the tools the way a real AI client uses them.
How does MindFort test MCP servers?
With swarms of agents that work together in parallel and share what they find. Setup is simple. You add your MCP server's URL as a target, plus a test account or token if it needs sign-in. Our agents connect as an MCP client, read the tool list, and start testing.
From there, swarms of specialized agents work together in parallel, each swarm owning one part of the attack surface:
- Auth and session swarms test who can connect and what they can reach. They try unauthenticated calls, forged or reused session IDs, OAuth flaws, and one user's token against another user's data.
- Tool abuse swarms call every tool with hostile input. They look for command injection, SSRF to internal hosts and cloud metadata, path traversal, SQL injection, and tools that do more than their description says.
- AI client swarms test the model side. They check tool descriptions and results for poisoning and prompt injection, and try to steer a real AI client into chaining tools to leak data.
The swarms share context as they work, so they can chain findings. Say an auth swarm finds that a forged session gets in. A tool abuse swarm then turns a URL parameter into SSRF against cloud metadata. That is one critical finding with a working exploit, not two separate notes. Like all MindFort findings, each one comes with proof, which keeps false positives under 1%.
What happens after MindFort finds an MCP flaw?
The same loop we run on web apps, APIs, and infrastructure. Agents write the code patch or config fix, open a pull request, and retest to confirm the hole is closed. We call this Autonomous Exploitation and Remediation (AXR).
MCP servers change fast. Tools get added, descriptions get edited, and auth settings drift. So test them on a schedule, not once. For why we build around swarms, read Why Are Agent Swarms the Future of Security?
Book a demo and we'll run a first test against your MCP server.
FAQ
What is an MCP server?
An MCP server exposes tools, data, and prompts to AI applications through the Model Context Protocol. An AI client such as Claude, Cursor, or an in-house agent reads the server's tool list and calls those tools on a user's behalf.
Why do MCP servers need their own pentest?
They mix two attack surfaces. They are network services that can have broken auth, injection, and SSRF like any API. They also feed text straight into an AI model, which opens up tool poisoning and prompt injection. Web scanners don't speak MCP and don't test the model side.
What do I need to start testing my MCP server?
The server's URL and, if it requires sign-in, a test account or token. Our agents connect as an MCP client, read the tool list, and start testing. No SDK or code changes on your side.
Does MindFort fix the MCP issues it finds?
Yes. As with web apps and APIs, agents write the code patch or config fix, open a pull request, and retest to confirm the hole is closed.
About the author
Akul Gupta
Co-Founder & CTO · MindFort
AI researcher focusing on LLMs in cybersecurity. Red-teamed models for OpenAI and Anthropic as part of their safety programs. Published multiple conference papers. M.S. Computer Science, UIUC.