tool & methodology

I could not read every MCP server by hand, so I built something that could

There is a moment in any security review where you realize the thing you are reviewing is growing faster than you can read it. For me, with MCP servers, that moment came early in 2026. New servers were appearing daily. Every AI vendor, every database, every SaaS product was shipping one. And they were all making the same handful of mistakes, in code I had not opened yet.

Manual review does not scale to that. So I wrote a scanner. This is the story of mcp-safeguard: why it exists, what it checks, what it found, and how the findings turned into an IETF draft.

The problem with reviewing MCP servers by hand

An MCP server is small. Most are a few hundred to a few thousand lines. You can read one in an afternoon. The problem is that there are not one of them. There are thousands, and the number goes up every day, and the interesting bugs are not in any single server. They are in the pattern across all of them.

When I reviewed servers manually, I kept finding the same categories. A tool description that could be edited to inject instructions into the model. A credential passed where the model could see it. A URL parameter that went straight to an HTTP client with nothing in between. An OAuth scope that was broader than the tool needed. After the fifth or sixth server, I was not learning anything new about the servers. I was learning that the ecosystem had a shared set of blind spots, and that the fastest way to find the next instance was to encode the blind spots as rules and run them everywhere.

What mcp-safeguard is

mcp-safeguard is an open-source static analysis security scanner for MCP servers. It is published on PyPI under the MIT license, source at github.com/SyedAnas01/mcp-safeguard.

It runs around 150 rules across seven categories:

Prompt injection. Tool descriptions, resource content, and other model-facing text that could carry instructions the model will follow.
Credential leaks. Secrets in places the model or the client can read, hard-coded keys, tokens passed through tool results.
Endpoint exposure. Servers or tools that expose more surface than they should, or expose it without authentication.
Tool poisoning. Ways an attacker could modify a tool’s definition or behavior to redirect the model.
SSRF. User-influenced URLs reaching HTTP clients without allowlists, IP-range checks, or redirect policies.
OAuth scope. Tokens requested or accepted with broader scope than the server’s function requires.
Source audit. General code-quality and dependency issues that create security exposure.

It is static analysis. It reads code, it does not run it. That makes it fast and safe to point at anything, and it means the output is a list of places a human should look, not a list of confirmed exploits. Every finding I have disclosed publicly went through manual verification after the scanner flagged it. The scanner’s job is to make sure I am looking in the right place.

What it found

The SSRF category is where the scanner earned its keep. It flagged the same shape in servers from four different vendors, and each flag turned into a confirmed finding.

In Google’s MCP Toolbox for Databases, an HTTP client with no CheckRedirect policy and no target IP validation. That became CVE-2026-14540, CVSS v4.0 8.0 High, fixed in v1.5.0. I was credited as the finder.

In Anthropic’s mcp-server-fetch and Microsoft’s playwright-mcp, arbitrary URL acceptance with no internal-address filtering, and in the fetch server a handler that bypassed the server’s own safety check. Disclosed together on Full Disclosure on 2026-05-25. Fix status unconfirmed as of disclosure.

In Weaviate’s Google-backed modules, an apiEndpoint field that had escaped two rounds of baseURL hardening and let a read-only user redirect a credential-bearing request to their own host. Confirmed by Weaviate Security, fixed in PR #12961 on 2026-09-07.

A separate finding, noted in the mcp-safeguard README, was a token-attachment issue in github/github-mcp-server, fixed via PR #3056, merged August 2026.

Each of these has its own writeup. The point for this piece is that none of them were found by reading the vendor’s code cold. They were found because a rule fired, and the rule fired because I had seen the shape before.

From findings to guidance

Finding bugs one at a time is useful. Explaining why they keep appearing is more useful, because it lets the next engineer avoid the bug before it is written.

In June 2026 I filed an IETF Internet-Draft, draft-mohiuddin-mcp-security-considerations-00, titled “Security Considerations for Model Context Protocol (MCP) Implementations in AI Agent Systems.” The draft generalizes what the scanner and the disclosures taught me into guidance for implementers.

It lays out six vulnerability classes that recur across MCP implementations, and it introduces a concept I call Protocol Pivoting. The idea is simple. An MCP server sits between two protocols: the model-facing protocol on one side, and whatever the server actually does on the other (HTTP, SQL, a browser, a cloud API). An attacker who can influence the model-facing side can pivot through the server into the other side. The server is the pivot point, and most servers are not built to be one.

SSRF is Protocol Pivoting where the second protocol is HTTP. Prompt injection into a database-backed server is Protocol Pivoting where the second protocol is SQL. Once you see the servers as pivot points rather than as tools, the trust boundary becomes obvious: it is every parameter the server accepts, because every parameter is on the attacker’s side of the pivot.

Why this is open source

I could have kept the rules private and run assessments as a service. I released it under MIT because the ecosystem problem is bigger than any one reviewer. Thousands of servers are being written by people who have never thought about what happens when a model is steered. A free scanner they can run in CI does more to close the gap than any number of individual disclosures.

The four findings above are what one person with one tool surfaced in nine months. I would rather the next hundred be caught before they ship.

Timeline

2026-05-25Anthropic mcp-server-fetch and Microsoft playwright-mcp SSRF disclosed on Full Disclosure
June 2026draft-mohiuddin-mcp-security-considerations-00 published on datatracker.ietf.org
2026-06-18Google MCP Toolbox PR #3448 merged, v1.5.0 released
2026-07-31CVE-2026-14540 published
August 2026github/github-mcp-server PR #3056 (token attachment fix) merged
2026-09-07Weaviate PR #12961 merged into stable/v1.37

References

About me

I'm Syed Anas Mohiuddin, an AI security researcher based in New York. I built mcp-safeguard, an open-source scanner that checks MCP server code and tool descriptions for exactly this kind of gap. See all my disclosures and papers: publications. More about my work: syedanas01.github.io.