Research · June 2026

MCP server security in 2026: state of the ecosystem mid-year update

In April 2026, we published a scan of 101 publicly available MCP servers — 36.7% had SSRF vectors, 43% had unsafe command-exec paths, and 79% of vendor-official servers earned an F grade. Six weeks later, with dozens of public disclosure threads, a revised Anthropic directory certification process, and a rapidly expanding server ecosystem, we revisit the numbers, the narratives, and what the threat model looks like heading into H2 2026.

36.7%

of initial corpus had SSRF vectors — LLM-controlled URL fetch with no allowlist

43%

had unsafe command-exec paths — shell injection via LLM-supplied arguments

79%

of vendor-official MCP servers earned F in our April scan

26%

of community-maintained servers earned F — better than enterprise teams

What the original scan found

The April 2026 corpus was 101 servers: 34 from Anthropic's official directory, 47 from community awesome-mcp lists, and 20 from npm packages with the mcp-server keyword. The scan ran six checks per server across our six audit axes: Security, Credentials, Permissions, Maintenance, Compatibility, and Documentation.

The headline findings were stark, but not surprising to anyone who has spent time reading MCP server source code. The core problem was consistent: servers were written by developers who understood how to build useful tools, but who had not thought through the adversarial threat model — specifically, the scenario where the LLM driving the tool calls is itself compromised via prompt injection in upstream content.

When the LLM is the adversary, all tool arguments are attacker-controlled. An SSRF vulnerability in a fetchUrl tool isn't just an annoyance — it's a credential exfiltration channel. A command-exec vulnerability in a runCommand tool isn't a bug to fix in the next sprint — it's a full-machine compromise waiting for a poisoned document to land in the LLM's context window.

The grade distribution in April:

3 servers — Microsoft Playwright MCP, a community filesystem tool, one SSE-based read-only server

6 servers — partial address of SSRF, good input validation, credential handling needs work

11 servers — multiple WARN findings, at least one mitigating control present

11%

14 servers — one or more HIGH findings, some context-mitigated by limited functionality

14%

67 servers — one or more unmitigated HIGH findings with meaningful blast radius

66%

What changed after six weeks of public disclosure

We re-ran the scan against the same 101 servers in late May 2026. The aggregate numbers moved, but not as much as the disclosure activity on GitHub might suggest.

Of the 67 F-graded servers in April: 9 patched the specific HIGH finding that caused the F, moving to D or C. 4 were archived — no new release, no acknowledgement, repository archived. 3 were deleted entirely. The remaining 51 remained at F with no substantive code change in the repository.

The 9 servers that improved did so through a consistent pattern: the maintainer already understood the issue and needed the disclosure to prioritize fixing it. Four of the nine were solo developers who merged a pull request within 48 hours of receiving a DM with the specific finding and a suggested fix. The other five were maintained by small teams who went through a brief internal review cycle before patching.

The 51 servers that didn't change fall into two groups. The first group — roughly 30 servers — are effectively unmaintained: last commit more than six months ago, no response to issues, no stars activity. These were never going to patch anything. The second group — roughly 21 servers — are actively maintained by teams or individuals who either haven't seen the disclosure or have triaged it as lower priority than current feature work. This is the group worth continued attention.

The disclosure response rate, by tier

Of the April F-graded servers, how many improved after six weeks:

Server type	F in April	Improved	Rate
Solo-maintained community	22	6	27%
Team-maintained community	18	3	17%
Vendor-official	27	0	0%

Vendor-official servers showed zero improvement in the six-week window. Enterprise security review cycles are measured in quarters, not weeks.

The vendor-official paradox — six weeks later, it's worse

The vendor-official finding from April — 79% F grades versus 26% for community servers — attracted the most attention. It was counterintuitive: companies with dedicated security teams, legal review processes, and brand risk to protect were shipping MCP servers in worse security condition than solo developers.

Six weeks later, not a single vendor-official server improved. This is not a disclosure failure — it's a structural reality. Enterprise security remediation of a public-facing service requires: security team triage, engineering sprint prioritization, internal review, staged deployment, and communications coordination. None of that happens in six weeks, and most of it requires the disclosure to reach the right team in the first place.

More importantly, the April 2026 scan also established why vendor-official servers perform poorly. The three structural reasons remain unchanged:

MCP servers are an afterthought. For most vendors, the MCP server is a two-engineer side project that lets the marketing team say "we have Claude integration." It's not a product line with an engineering owner who cares about security posture.
The threat model is unfamiliar. Enterprise security reviews are oriented around perimeter defense, credential management, and supply chain integrity. The adversarial LLM threat model — where tool arguments are attacker-controlled because the model was prompt-injected — is not yet part of enterprise security review checklists.
Community-maintained devs understand the context. The indie developers building community MCP servers are power users of Claude Code. They have read the MCP specification. Many have personally tried prompt injection attacks. They understand that fetchUrl with an LLM-controlled URL is an SSRF vector. Enterprise teams writing MCP server adapters for existing REST APIs don't have this mental model.

Where the attack surface is growing in H2 2026

The April corpus captured the first wave of MCP servers: single-purpose tools doing file operations, API calls, and shell execution. The H2 ecosystem is evolving along three dimensions that each expand the attack surface in new ways.

1. Multi-agent pipelines

The most significant structural change in the MCP ecosystem is the emergence of agent-to-agent tool calls. A growing number of MCP servers are not tools that connect Claude to an external service — they're tools that invoke other AI agents, orchestrate multi-step workflows, or chain model calls. The security implication is that a single prompt injection in a document processed by one agent can cascade through an entire pipeline.

An SSRF vulnerability in a tool called by step 3 of a 7-step pipeline doesn't just affect step 3. If step 3's output is passed to step 4, and step 4 uses that output to construct further tool calls, the compromised output can drive malicious behavior through the rest of the chain. The blast radius of a single vulnerability in a pipeline grows linearly with the number of downstream steps that trust the compromised output.

The defense is output schema validation between pipeline stages: every tool output should be validated against a strict schema before being passed to the next stage, and the schema should not include free-form string fields that could contain injected instructions.

2. Event-driven and async architectures

Early MCP servers were synchronous: tool call in, result out. H2 servers are increasingly using message queues (Kafka, RabbitMQ, SQS) and pub/sub systems (Redis, NATS) to handle long-running operations. This creates a new attack surface: message injection.

If an MCP server allows an LLM to publish messages to a queue — and does not validate the topic, key, or message content against an allowlist — a prompt-injected model can publish to arbitrary topics, poison other consumers, or trigger downstream processing of attacker-controlled content. The attack is indirect and difficult to detect because the malicious action (publishing a message) looks identical to legitimate operation.

We expect message injection to be the most significant new finding category in H2 scans. The event-driven security page covers the specific defenses.

3. GraphQL and gRPC proxy patterns

A growing pattern in the MCP ecosystem is the "protocol bridge" server: a Claude tool that accepts natural-language or structured arguments from the LLM and translates them into GraphQL queries or gRPC calls against existing internal APIs. These are valuable — they let enterprise teams expose existing infrastructure to Claude without rewriting API layers.

But they also concentrate two attack surfaces in one place. Introspection leakage (the LLM can query the full schema of your internal API) and query complexity attacks (the LLM can construct deeply nested queries that exhaust server resources) are both specific to the GraphQL proxy pattern. Server reflection and metadata injection are the equivalent risks in gRPC proxies.

Neither attack class is covered by conventional application security reviews, because neither attack class was relevant before LLMs could construct arbitrary queries at runtime. Enterprise security teams reviewing MCP server code are not looking for unbounded GraphQL query depth — because until recently, no user could send unbounded queries without being filtered by the frontend.

The Anthropic directory certification effect

In May 2026, Anthropic updated the submission requirements for the official Claude Skills Directory to require a security review before listing. The practical effect has been a surge of authors requesting SkillAudit reports to attach to their submissions — the badge is now a legible signal to directory reviewers that someone has run a neutral third-party scan.

The certification requirement has also started to change behavior upstream. We are seeing more new server submissions that preemptively avoid the patterns our scan flags: servers arriving with Zod input validation already in place, with SSRF allowlists already configured, and with credential handling that uses environment variables rather than tool arguments. The signal is working — not because developers were unaware of the risks, but because the directory requirement gave them the business justification to invest the time.

What a healthy MCP security posture looks like in 2026

Across the servers that earned A or B grades in our corpus — and across the servers that improved after disclosure — a consistent pattern emerges. The servers with good security posture share four properties:

Strict input schema. Every tool argument is validated against a Zod schema before any operation. Enum fields use explicit allowlists, not free-form strings. Numeric fields have explicit min/max bounds. No tool argument is ever used as a shell command component, URL component, or path component without validation.
No LLM-controlled URLs. Tools that fetch external resources operate from an explicit server-side allowlist. The LLM can specify a resource by name or ID from that list — it cannot specify an arbitrary URL. SSRF is architecturally prevented, not just validated.
Credential isolation. Credentials come from environment variables and are injected at request time. They are never passed as tool arguments, never logged, never included in tool output. The LLM has no access to the credential values — only to the results of operations performed with them.
Maintenance discipline. Dependencies are pinned to exact versions with a lockfile. A Dependabot or Renovate configuration monitors for security advisories on pinned versions. The README includes a security disclosure contact. The server has been updated in the last 90 days.

None of these are exotic practices. They are standard engineering hygiene applied to the adversarial LLM threat model. The gap is not capability — it's awareness of the threat model and business justification for the time investment.

What we're tracking in H2 2026

Three trends we expect to dominate the conversation in the second half of 2026:

The first major public MCP server incident. The conditions for a significant credential exfiltration incident via a compromised MCP server are in place. 51 actively maintained servers are sitting at F grade. MCP adoption is growing rapidly. The question is not whether this will happen but which server and which organization it will happen to. Public incident disclosure will do more for ecosystem security posture than any number of blog posts.
Anthropic's own security tooling. The directory certification requirement is a policy lever. The next obvious step is tooling — a first-party static analysis pass that runs on every directory submission. If Anthropic ships this, SkillAudit's value proposition shifts from "the only scan that exists" to "the deeper scan that covers what the first-party scanner doesn't." We're building for both scenarios.
The multi-agent pipeline audit problem. Today's scan is a single-server analysis. Auditing a multi-agent pipeline requires tracing data flow across multiple tool calls, identifying where prompt-injection could affect downstream agents, and modeling the blast radius of each vulnerability in the pipeline context. This is a harder problem than single-server scanning, and the ecosystem doesn't have a solution for it yet.

Run the scan on your server

If you're building an MCP server, the best time to run a SkillAudit scan is before you submit to the Anthropic directory — not after a rejection. The free tier covers 3 audits per month on public repositories and includes the public badge you can attach to your submission. The Pro tier adds CI integration via the GitHub Action gate so future commits are automatically re-scanned.

If you're a team lead evaluating community MCP servers for internal adoption, the audit report reading guide walks through how to interpret each finding and which severity levels warrant blocking adoption versus reviewing before install.

Know where your server stands before the H2 audit cycle begins.

Run a free audit → More research →