All posts
· 11 min read ·

Why reading the MCP spec won't tell you if a server is safe

Anthropic says MCP STDIO injection is by design; four independent scans of thousands of servers say a third have command-injection flaws. The two claims describe different objects.

The Model Context Protocol's biggest disclosure of the year came on April 15, when OX Security published a coordinated advisory covering arbitrary command execution across more than 7,000 publicly accessible MCP servers and 150 million SDK downloads. The flaw is in how Anthropic's official SDK handles STDIO transport: the command field in an MCP configuration is passed straight to a process launcher with no validation. CVE-2026-30623 is one downstream instance, which LiteLLM patched with a command allowlist; additional high- and critical-severity CVEs were filed against tools including Windsurf, LangChain-Chatchat, and Flowise.

The CVEs are not the interesting part. The interesting part is that the spec author and the researchers do not agree on whether anything broke. Anthropic told OX that the STDIO execution model is "expected" behavior and that sanitization is the implementer's responsibility. OX Security countered that responsibility-shifting is a sleight of hand: "shifting responsibility to implementers does not transfer the risk. It just obscures who created it." Neither position is empirically falsifiable from the spec text. Both are checkable against the install base, and the install base has been measured.

The two claims that can't both be true at the population level

Anthropic's defense reduces to a conditional: if every implementer sanitizes correctly, then the STDIO model is safe. That is a coherent statement about the protocol. It is not a statement about the field of MCP deployments. The field has been scanned independently four times.

Equixly's assessment, conducted against the most popular MCP server implementations, found that 43% contained command injection vulnerabilities. Enkrypt AI scanned 1,000+ MCP servers over three months and reported 32% with at least one critical vulnerability, 28% with command injection, and 41% with authorization bypass. Endor Labs surveyed 2,614 implementations and found 34% using sensitive APIs susceptible to command injection (CWE-78), with 82% touching file-system operations vulnerable to path traversal. Knostic catalogued 1,862 MCP servers exposed to the public internet; every manually verified instance accepted unauthenticated requests to list internal tools.

Source Population Command-injection rate Other notable findings
Equixly, Mar 2025 "Most popular" MCP servers 43% —
Enkrypt AI, Oct 2025 1,000+ scanned 28% 32% critical, 41% auth bypass
Endor Labs, 2026 2,614 implementations 34% (CWE-78) 82% path-traversal-prone
Knostic, 2025 1,862 exposed — 100% unauthenticated of verified
Command-injection rates across three independent MCP scans Horizontal bar chart. Equixly found command-injection vulnerabilities in 43% of scanned MCP servers, Endor Labs in 34%, Enkrypt AI in 28%. A dashed violet line at the left axis marks the implicit protocol-spec claim of zero non-conformant servers. COMMAND-INJECTION RATE · INDEPENDENT MCP SCANS Equixly 43% Endor Labs 34% Enkrypt AI 28% SPEC CLAIM: 0% 0% 50% 100%

Four methodologies, four sample sets, four different ways to score what counts as a vulnerability. The convergent finding is that command-injection-class flaws appear in roughly a third of MCP servers in the wild. That is not a result one would expect if the implementer-sanitization model were holding.

It is also not a result that can be rebutted from the spec. The spec describes intended behavior. The scans describe observed behavior across the population that adopted it. They are different objects.

Why "by design" stopped being a security property here

"Secure by design," as the term is used in security literature, describes a system whose safe operation does not depend on the correctness of every implementer. PKCE in OAuth 2.1 is secure by design in that sense; a client that integrates incorrectly fails closed. STDIO transport in MCP has the opposite shape. A client that omits sanitization fails open, on a transport the SDK encourages, with no detection at the protocol layer.

The contrast with MCP's own enterprise direction makes the point sharper. At the MCP Dev Summit in April 2026, the Agentic AI Foundation approved a formal project lifecycle policy, MCP crossed 97 million monthly SDK downloads, and Uber disclosed that it runs 1,500+ monthly active agents executing 60,000+ tasks weekly across its internal services. The same summit included researcher Jonathan Leitschuh demonstrating a DNS rebinding 0-day in Google's MCP Database Toolbox that had gone unpatched for over 90 days. If a Google project shipping in production cannot patch a classic web-rebinding flaw inside three months, the assumption that every MCP implementer in the world will sanitize STDIO inputs correctly is not a load-bearing assumption.

This is not a moral claim about developers. It is an observation about populations. Any protocol whose security properties depend on every implementer being correct has the same problem in the limit. The web learned this with SQL injection; the fix did not arrive in the form of better SQL specs.

The probe is the answer the spec can't give

A registry that publishes "this MCP server claims compliance with spec version X" is encoding the spec author's intended behavior. That is a useful claim, and it is not the same claim as "this server, when probed today, did not respond to a known command-injection pattern." The first is cheap to produce and trivially falsifiable against the population data above. The second is more expensive, has to be repeated continuously, and is the only kind of claim that survives contact with the install base.

The split between "claim" and "evidence" is the load-bearing distinction in the Agenstry registry. A card a server published last week is a claim. A probe run this morning is evidence. We publish both, separately, because a consumer making a trust decision needs to know which input they are acting on. The four scans cited above all converge on the same underlying fact: at the MCP population scale, claims and evidence diverge by tens of percentage points.

A few practical implications for builders, none of which require a change to the spec:

  • If your agent calls an MCP server you do not control, the spec version it advertises is not a safety signal. It is metadata about the server's intent, which is a different object from the server's behavior.
  • If your platform aggregates MCP servers for end users, the published claims of those servers are not a substitute for a periodic probe. The population data is clear that one input is roughly a third wrong about the other.
  • If you maintain an MCP server, the most useful thing you can do for downstream trust is publish probe results alongside your claims. The spec does not require this, and most servers do not, which is precisely why it would be a legible credibility signal.

What we're watching

Three observable things over the next two quarters, all relevant to whether the spec/probe gap closes or widens:

  1. Whether the AAIF MCP Registry roadmap absorbs a probe layer. The foundation's enterprise readiness goals include SSO-integrated authentication and standardized audit trails. They do not yet name continuous conformance probing as part of the registry's mandate. If the registry stays publication-only, downstream consumers will have to run their own probes or rely on third-party services that do.
  2. Whether the next independent scan finds the same numbers. Equixly, Enkrypt, and Endor converged on roughly a third of servers being vulnerable. If a 2026 H2 scan finds the rate dropping under 10%, the developer-sanitization model is working at scale and the "by design" position becomes empirically defensible. If the rate holds, the position becomes structurally unable to address the population problem.
  3. Whether the OAuth 2.1 + PKCE authorization layer reduces the relevant attack surface. The spec standardizes how clients obtain tokens, but does not specify how the non-human MCP server itself is identified to the authorization server. That gap is a different shape of the same population-vs-spec problem: the protocol describes how to do something right, and the work is done by everyone else.

The April 15 disclosure will get described as an Anthropic story or as a researcher story. It is more usefully read as a measurement story. A protocol's intended behavior and the population's actual behavior are two different objects, and only one of them is the object your agent talks to.

Sources

← Back to blog Agenstry