Model Context Protocol STDIO Transport By-Design Command Execution - MCP By Design

OX Security disclosed a class it calls MCP By Design: the Model Context Protocol STDIO transport executes any process command passed to it on the host, whether or not that command actually starts a valid MCP server. The behavior is not a bug in one product - it is baked into Anthropic's official MCP SDKs across Python, TypeScript, Java, and Rust - which is why it sits at the root of so many 2026 MCP server CVEs. This advisory covers what was disclosed, why it lands on the agentic-endpoint layer, and how to govern it when there is no patch.

What happened

STDIO transport is how an MCP client launches a local server: it takes a command string and an args array, spawns that subprocess, and communicates over stdin and stdout. OX Security's MCP By Design research showed that the SDK spawns the process first and never verifies that what it launched is a real MCP server. A client or configuration that supplies an attacker-influenced command string therefore achieves arbitrary command execution on the host. Because the behavior lives in the official SDKs, every downstream implementer that wires user-controlled or remote data into command or args inherits it.

Researchers tied the pattern to roughly 7,000 publicly reachable servers and up to 200,000 vulnerable instances, spanning a supply chain with more than 150 million downloads. They counted 10+ assigned CVEs and over 30 RCE issues touching products including LiteLLM, Langflow, Cursor, Flowise, DocsGPT, and GPT Researcher - the same supply-chain surface seen in adjacent incidents like the LiteLLM malicious PyPI release. Anthropic stated that the STDIO execution model is the intended secure default and that input sanitization is the developer's responsibility, and it declined to change the protocol. There is no protocol-level patch.

That last point is the one to sit with. This is not a single advisory with a fixed version; it is a structural pattern. That is why so many MCP server CVEs in 2026 reduce to one root cause - untrusted strings reaching a subprocess spawn - and why the 2026 MCP CVE wave keeps producing the same finding across unrelated products.

Why this is an agentic-endpoint risk

An MCP server is not a passive dependency. It is code that an AI agent invokes to read files, run commands, and reach the network, running with the agent's privileges on a managed endpoint. STDIO transport is the most common way agents launch those servers locally, so the by-design execution behavior sits on the everyday path between an agent and its tools - not an edge case.

The exposure is hard to see from the controls you already run, because it lives in the AI artifact layer. The launch command sits in a local config file a developer edits to unblock a task; the spawned process looks legitimate to EDR; the network sees only encrypted agent traffic; and DLP sees nothing at rest. MCP servers are one of the eight AI artifact types adopted bottom-up that report to no security tool - the dynamic that makes AI agents and MCP servers the new shadow IT. The question is not whether the SDK behaves as documented; it does. It is which endpoints build a launch command from data they do not fully control, and you cannot answer that without an inventory of the artifact layer.

How Anomity surfaces and governs it

Because there is no patch, the only durable defense is to treat the MCP layer as an execution boundary and govern which tool calls and process spawns are allowed to run. Anomity does that in three steps.

First, inventory. Anomity inventories every MCP server on every managed endpoint as part of the eight AI artifact types it tracks, capturing the configuration metadata - including the command and args wired into each STDIO server and the agent that launches it. It classifies each server by trust signals and infers the capabilities it grants. Metadata only: secrets are redacted on the endpoint before anything leaves it.

Second, decide at the hook. On agents that expose a hook - for example, the PreToolUse event in Claude Code - Anomity evaluates each tool call and process spawn against your policy and returns allow, deny, or log before the call runs. A spawn whose command was assembled from untrusted input can be denied at the boundary instead of executing, which is exactly the control runtime governance is built to provide for a by-design behavior that will not be patched upstream.

Third, keep the record. Every decision, and every added, changed, or removed MCP server, lands in a queryable 90-day audit trail, and decisions route to SIEM, Slack, email, or Jira. When a CVE in this class is published against a product you run, you can answer where it is, what it was allowed to do, and what it did - from a record, not a guess. Anomity complements your Network, EDR, DLP, and GRC tooling; it covers the artifact layer those tools were never built to inventory.

You can't govern what you can't see.The Anomity principle

What to check across your fleet

• Inventory every MCP server configured on every endpoint and capture the command and args for each STDIO server - not just the ones that bind a network transport.
• Identify any path where user-controlled, model-generated, or remote data can flow into an MCP launch command, including dynamic server registration and config written by an agent.
• Flag projects built on the official MCP SDKs for Python, TypeScript, Java, or Rust that accept external input near the spawn - the by-design behavior is inherited, not opt-in.
• Cross-reference your inventory against the 10+ derived CVEs and the named products - LiteLLM, Langflow, Cursor, Flowise, DocsGPT, GPT Researcher - and treat a match as in-scope.
• Confirm that high-risk tool calls and process spawns are evaluated at the agent hook with allow/deny/log, so an untrusted command is stopped before it runs.
• Verify that every spawn and every server change is written to a 90-day audit trail and routed to your SIEM, so you can answer scope questions when the next CVE in this class lands.

MCP By Design is not a flaw you wait out - Anthropic has said the STDIO execution model stays. The way through is to treat the MCP layer as an execution boundary, inventory every server, and govern spawns at the hook. For the full attack surface, trust tiers, and the 2026 CVE wave this class sits at the root of, see the pillar guide on MCP server security. To see Anomity inventory and govern the MCP layer across your fleet, request early access.