MCP's 'By Design' RCE: When the Vendor Says the Vulnerability Is a Feature

There is a specific kind of security finding that breaks the usual ritual. Normally a researcher discloses, the vendor confirms, a patch ships, everyone updates, the CVE closes. The cycle has a shape, and the shape ends in a fix. The vulnerability OX Security disclosed in Anthropic’s official Model Context Protocol SDKs does not have that shape. The researchers found a remote code execution path running through the SDKs that power Python, TypeScript, Java, and Rust agents. Anthropic confirmed the behavior. And then, instead of a patch, the answer came back: this is by design. Sanitization is the developer’s responsibility. There is no CVE to close because, per the vendor, there is nothing broken.

That is the paradox worth sitting with. We previously covered the broad shape of this problem in MCP in 2026: The Universal Standard — and Its Security Problem, where the argument was that the standard plug is settled but the security of what you plug in is wide open. This post is the incident-specific sequel. The earlier piece warned about the ecosystem; this one is about the SDK at the center of it, and about what it means when the most serious flaw in a protocol is reclassified, by the people who own the protocol, as intended behavior.

The mechanism: config to command, no gate in between

To understand why “by design” is technically defensible and operationally terrifying at the same time, you have to look at how MCP’s STDIO transport works. MCP servers can run as local processes. When an agent connects to one over STDIO, it spawns the server by executing a command — a binary, an interpreter, a script — with arguments, all read from configuration. That configuration is just data: a JSON-ish blob saying “to start this server, run this command with these args.”

The flaw, as OX Security and the follow-up analysis from Zealynx Security (“Anthropic MCP SDK Vulnerability Full Analysis,” May 2026) describe it, is that the command field is taken at face value and executed on the host. If anything an attacker can influence flows into that field — a config fetched from a remote source, a value templated in from user input, a server entry pulled from a marketplace — then the attacker is choosing what runs on the machine. The agent doesn’t have to successfully initialize a valid MCP server. The code executes during the attempt. There is no validating gate between “here is a config” and “here is a process running with your privileges.”

This is why Anthropic can call it by design. The SDK does exactly what it says: it runs the command you configure. The library is not the place, in their view, where untrusted input should be caught. The catch is supposed to happen upstream, in the application, by the developer. Technically coherent. Practically, it means the single most dangerous operation in the stack — arbitrary command execution — is guarded by nothing but the assumption that every one of millions of downstream developers correctly sanitizes every path that can reach a config field.

The four attack families

The disclosure and the surrounding write-ups (SuperML.dev’s MCP’s Security Debt Just Came Due, and DevOps Daily’s “The MCP Design Flaw That Exposes 150M Downloads to RCE”) group the practical exploitation into roughly four families:

Unauthenticated UI injection. Many MCP-enabled tools expose a local interface — a panel, a web view, a control surface — that accepts server configuration without authenticating who is asking. An attacker who can reach that surface can register a server with a hostile command field and have it execute, no credentials required.
Sanitization bypasses. Where developers did try to filter the command field, the filters were shallow. Encoding tricks, argument splitting, and shell-feature abuse slipped malicious payloads past naive allowlists and denylists. A half-built guard is a worse signal than no guard, because it looks like the problem was handled.
Zero-click prompt injection. This is the one that should worry agent operators most. A poisoned tool description or a malicious document, ingested by an agent running inside an IDE or an automated pipeline, can steer the model into registering or invoking a server whose command field carries the payload — with no human clicking anything. The injection rides the agent’s own autonomy. Tool-poisoning success rates above 60% against major LLM agents have been reported in this class.
Malicious marketplaces and distribution. As the ecosystem grew, so did the registries and marketplaces that distribute server definitions. A hostile or compromised entry can ship a command field that compromises every host that installs it — supply-chain compromise with the protocol’s own distribution channels as the delivery mechanism. OX Security’s framing of this, in their April 2026 piece “The Mother of All AI Supply Chains,” is not hyperbole given the reach.

The blast radius

The numbers are what move this from a bug to a systemic event. The SDKs in question carry 150M+ downloads. OX Security’s scan identified roughly 7,000 publicly exposed MCP servers and an estimated 200,000 vulnerable instances in the wild. More than ten downstream CVEs were filed as the finding propagated through dependent projects — CVE-2026-30615, -30617, -30618, and others in that sequence — even as the root behavior in the SDK itself carries no patch, because the vendor does not consider it a defect.

Sit with the governance gap that opens here. A CVE is, among other things, an accountability artifact: it names a defect, assigns it a severity, and creates an expectation that someone fixes it. When the vendor declares the root cause intentional, the chain of accountability is severed at the top and re-attached, permanently, to the bottom — to every individual developer integrating the SDK. The liability doesn’t disappear. It is distributed, silently, across 150 million downloads’ worth of people who mostly do not know they have inherited it. This is the same dynamic we traced in The $100 Billion Guardrail: the safety work doesn’t go away when the platform declines to do it; it just moves downstream and turns into someone else’s cost center. Here the move is explicit. The vendor has named the owner of the problem, and the owner is you.

Why this is a Southeast Asia opportunity, not just a Southeast Asia risk

If the spec won’t catch untrusted input before it becomes a command, then someone has to build the layer that does — an MCP command allowlist, a config validator, a registration monitor. And here is the part that matters for a capital-light team in Phnom Penh, Da Nang, or Cebu: building that layer requires no GPUs, no training runs, no data center. It requires understanding the protocol, auditing the surfaces where config reaches execution, and writing disciplined validation. That is engineering, not capital.

This is the same opening we have argued for repeatedly. A team that can take an MCP deployment and produce a hardened, audited, allowlisted version of it — one that enforces what the SDK refuses to — is building defensible IP out of skill rather than spend. The vendor permanently delegated the fix downstream; that delegation is a market. The boundary you would enforce is exactly the guardrail-as-compliance-boundary work, applied at the single most dangerous operation in the agent stack. And it pairs naturally with the isolation discipline from Sandboxing the Agent — an allowlist decides what may run, a sandbox limits what the damage can reach when something slips the allowlist anyway. Defense, as we put it in Defense in the Loop, has to sit mid-task, between the config and the command, not bolted on after.

What operators must do today

The vendor’s stance means the responsibility is now, unambiguously, operational. Concretely:

Validate every MCP server config before it is loaded. Treat the command field as the privileged operation it is. It should be a known, fixed binary path, not a value assembled at runtime.
Enforce a command allowlist. The agent should be permitted to launch only an explicit, audited set of server commands. Anything not on the list does not run. This is the layer the SDK will not give you, so you build it.
Never pipe untrusted user input into a STDIO config field. No templating, no string interpolation, no “convenience” path that lets a request body, a fetched document, or a marketplace entry reach the command. If input must influence behavior, route it through validated parameters, never the executable itself.
Monitor for unexpected MCP registrations. A new server appearing in your agent’s config that no one deployed is an incident, not a curiosity. Alert on it. Zero-click injection works precisely because the registration is silent.
Sandbox the server processes. Assume the allowlist will eventually be bypassed and cap the blast radius with isolation, least privilege, and network egress controls.

MCP solved how agents connect to tools, and that was a real achievement. But the vendor has now drawn a bright line: the SDK runs what you tell it to run, and catching what should not be told to it is your job, forever. That is not a temporary state pending a patch. It is the permanent contract. The teams that internalize it — and build the allowlist the spec declined to — are the ones who get to use MCP without inheriting its worst CVE by default.