MCP Just Had Its First Design-Level CVE. Here's What 7,000 Servers Are Actually Built On.

Last month I wrote about CVE-2026-32211, the missing-authentication bug in Microsoft's Azure DevOps MCP server. The headline framing was that one Microsoft team shipped a bad implementation. The followup, which is what this article covers, is that some of the worst MCP problems are not in any single implementation. They are in the protocol itself, and they affect every server built on Anthropic's official SDK.

Two stories matter here. The first is the architectural RCE pattern in the MCP STDIO interface that lets configuration files become code execution by design. The second is CVE-2026-25536, a cross-client data leak in the TypeScript SDK that ships responses from one user to a different user when a server reuses transport instances.

Both are now widely covered in the security press. Neither is a small business owner's normal reading. This article walks through what each one actually means, why it matters even if you don't run an MCP server yourself, and the four questions to ask any vendor whose product has "MCP" in the description.

The architectural RCE: CVE-2026-30623

OX Security published the disclosure on April 15, 2026; the vulnerability has since been assigned CVE-2026-30623. Anthropic's Model Context Protocol gives direct configuration-to-command execution through its STDIO interface. The pattern is built into the official MCP software development kit across every supported language: Python, TypeScript, Java, and Rust. By design, anyone who can place an MCP server configuration on a target system can run arbitrary OS commands if the configuration successfully launches a STDIO server.¹

The exposure is large. Estimates put the number of publicly accessible MCP servers at more than 7,000, with the official SDK packages totaling more than 150 million downloads.¹ The 150 million is across all SDK installations, not all of which are exposed to the internet, but the 7,000 publicly accessible servers are.

The reason this counts as a design issue rather than an implementation bug is that the STDIO interface was meant to do exactly this. The whole point of MCP is to let a model invoke tools that run as local processes. Letting a configuration spawn a process is the feature, not the flaw. The flaw is that the spawning happens with the trust and the access of whoever is running the agent, with no attestation that the configuration came from a source the agent's operator vetted.

This is the agent-ecosystem version of the kind of vulnerability that PyPI and npm have been litigating for a decade. A package manager that runs install scripts on your machine has the same shape of problem; the difference is that the agent's STDIO process runs with whatever access the agent has, which often includes credentials, file systems, and APIs the package manager never touches.

Anthropic's response: this is the intended behavior

The part of the story that did not make most of the security-press headlines is what Anthropic said back. OX Security recommended manifest-only execution, a command allowlist in the official SDKs, and protocol-level mitigation. Anthropic declined all three. The company's public position is that the STDIO execution model is the secure default and that input sanitization is the developer's responsibility, not the protocol's. Only the SDK's SECURITY.md guidance got an update.²

That stance is defensible from a pure protocol-design standpoint. It is also the reason this article exists. If the vendor of the foundational SDK considers configuration-to-command execution to be a property of the protocol rather than a vulnerability of it, every downstream product built on the SDK inherits the assumption that someone else (the integrator, the deployer, the operations team) is responsible for the missing safety controls. In practice, a lot of those downstream products have not added them. The CVEs in the next section are what that looks like in the field.

The downstream CVE pattern

Anthropic's "expected behavior" framing has produced a steady stream of separately-numbered CVEs in products that integrated the SDK without adding the missing controls. The list as of May 2026 includes CVE-2025-49596 in the MCP Inspector debugging tool, CVE-2026-22252 in LibreChat, CVE-2026-22688 in WeKnora, CVE-2025-54994 in the @akoskm/create-mcp-server-stdio scaffold package, and CVE-2025-54136 in Cursor. The LiteLLM project shipped its own fix for the same pattern in v1.83.6-nightly.³

Each of these is a different product with its own development team, but the shape of the bug is identical: a configuration-passed-as-trusted input that the protocol allows to launch arbitrary processes. The cluster is the practical demonstration that "sanitization is the developer's responsibility" doesn't actually distribute the responsibility evenly across the ecosystem. It concentrates the harm in whichever product happened to be on the receiving end when someone tried the attack.

CVE-2026-25536: cross-client response leak in the TypeScript SDK

This one is more subtle and arguably more useful as an explainer of why the agent ecosystem keeps tripping the same wires.

In versions 1.10.0 through 1.25.3 of the @modelcontextprotocol/sdk TypeScript package, a single MCP server that reuses a StreamableHTTPServerTransport instance across multiple clients can leak responses. One client requests data; the server processes the request; the response goes to a different client.⁴

The cause is a JSON-RPC message-ID collision. The MCP client SDKs assign request IDs using an incrementing counter that starts at zero. When two different clients connect to the same server, both produce request IDs starting with 0. The transport maintains an internal map from request ID to client stream. The second client's request overwrites the first client's mapping, and the server-to-client response that was meant for the first client gets routed to the second.⁴

If this lands in the wrong place at the wrong time, the consequences are real. The leaked response could be a customer record, a financial summary, a medical detail, anything the server was asked to return. The fix is to update to MCP TypeScript SDK 1.26.0 or later, which makes the stateless transport throw if reused across requests, plus to avoid reusing transport instances across client connections by configuration.

This is the kind of bug that production-deployed multi-tenant systems have been getting bitten by for forty years. It is showing up now in the agent ecosystem because the agent ecosystem is shipping multi-tenant production systems faster than its frameworks have been hardened.

Why this matters even if you don't run an MCP server yourself

Most small businesses do not run their own MCP servers. They use AI products and agent platforms that, increasingly, do.

Microsoft Copilot connectors are MCP. Claude's tool integrations are MCP. The AI features in your CRM, your accounting software, your helpdesk, your scheduling tool: a meaningful fraction of them are now built on MCP servers run by the vendor. When the vendor's MCP server has a vulnerability, the data flowing through that server is your customer data, even if you have never heard of the protocol.

The two CVEs above are the visible tip. The underlying point is that an entire generation of vendor products is being shipped on top of a protocol whose security model is still being figured out. The protocol's design choices (let configurations spawn processes; let single transports serve multiple clients) make total sense in an isolated developer-machine context. They make less sense in the context they actually shipped into, which is multi-tenant cloud services handling business-customer data.

The four questions to ask any vendor whose product touches MCP

None of these require you to read the MCP spec. They require you to ask the vendor four direct questions and write down the answers.

1. Are you running an MCP server, and which version of which SDK

The vendor should be able to answer this in one email. If they cannot, that is itself the answer to question one. For the TypeScript SDK in particular, anything below 1.26.0 is exposed to CVE-2026-25536 unless they have specifically mitigated. For other languages, the same architectural concerns from the OX Security report apply.

2. Is the server multi-tenant, and how is tenant isolation enforced

If your customer data ever sits in the same MCP server process as another customer's data, the cross-client leak class of bug is in your threat model whether or not the specific CVE-2026-25536 has been patched. The acceptable answers are some combination of per-tenant transport instances, request-scoped server instances, and explicit tenant-tagged routing. The unacceptable answer is "we share the server across customers because it's more efficient."

3. What does the server's STDIO process spawn

If the vendor's MCP server invokes shell commands, scripts, or local binaries based on configuration, the architectural RCE pattern applies. The mitigations are standard: restrict spawnable commands to an allowlist, run the process with minimum privileges, log every spawn, and require provenance attestation for any new configuration source. If the vendor cannot describe these controls, you should assume they don't have them.

4. What does the audit log of MCP tool calls look like, and can I see it

For any AI feature you use that makes tool calls on your behalf, you should be able to see, after the fact, what tools were called, with what arguments, with what response, on whose authority. If the vendor's audit story is "tool calls are logged in our backend, customers can request a record on demand," that is a worse audit story than your CRM probably has. If the answer is "we log model calls but not tool calls," you have a gap.

What I'd do this week

If you have any AI feature in any vendor product that you use for customer data, send the vendor an email with questions one through four. The replies will sort vendors into three buckets. The good ones answer with specifics in a day. The middling ones respond with a marketing answer in a week. The bad ones don't answer at all. Where the vendor lands tells you a lot about how seriously they're taking the agent-security work, and how much of your data is at risk.

If you run anything yourself that includes an MCP server (whether a custom integration or a self-hosted tool), update the TypeScript SDK to 1.26.0 or later, audit your STDIO server configurations, and put an allowlist on what they can spawn. The piece on the OpenClaw + n8n hybrid architecture describes the broader pattern of separating the agent's reasoning from the agent's ability to take action; the same pattern applies one level down, between the agent and the MCP server it talks to.

Sources

1. CVE-2026-30623 architectural command-execution in the official MCP SDK; ~7,000 publicly accessible servers; 150M+ SDK downloads. Per OX Security's analysis, The Hacker News coverage, VentureBeat's writeup, and Unit 42's MCP attack vectors writeup. ↩
2. Anthropic's public response: behavior is expected, sanitization is the developer's responsibility. Per BDTechTalks's coverage of Anthropic's response and The Register's reporting. ↩
3. Downstream CVE pattern (MCP Inspector, LibreChat, WeKnora, akoskm scaffold, Cursor) and the LiteLLM same-pattern fix. Per the LiteLLM advisory and patch notes and aggregated coverage at the Salt Security MCP attack surface report. ↩
4. CVE-2026-25536 details: affected versions (1.10.0 to 1.25.3), JSON-RPC message-ID collision mechanism, fix in 1.26.0. Per the GitHub Security Advisory GHSA-345p-7cg4-v4c7, the NVD entry, and the Vulnerable MCP Project writeup. ↩