MCP STDIO RCE Vulnerability Wave (2026) Explained

In April 2026, OX Security researchers disclosed a design-level weakness in Anthropic's official Model Context Protocol (MCP) software development kits that lets an attacker run arbitrary operating system commands on any server exposing STDIO-based MCP configuration to untrusted input. The flaw was not a single fixable bug in one project — it was an unsafe default baked into how the STDIO transport handles server launch across every supported SDK language, and it had already reached thousands of public deployments by the time it was disclosed. Anthropic did not change the protocol's reference behavior in response, which means the responsibility for closing the gap fell to the maintainers of every downstream project that exposed the STDIO launch primitive to input it should not have trusted.

What OX Security found

The Model Context Protocol's STDIO transport is designed to launch a local server process and hand its standard-input/output handle back to the calling application, so a model can use that process as a tool. OX Security's researchers — Moshe Siman Tov Bustan, Mustafa Naamnih, Nir Zadok, and Roni Bar — found that across Anthropic's Python, TypeScript, Java, and Rust SDKs, the code path that performs this launch will execute whatever command and arguments it is given. If a command successfully starts an STDIO server, the handle is returned; if it does not, the command still runs before an error is surfaced. In their words, the SDK gives "a direct configuration-to-command execution via their STDIO interface on all of their implementations, regardless of programming language."

That is not a flaw an individual project can patch by fixing its own code — it is the documented behavior of the primitive every STDIO-based MCP integration is built on. The vulnerability only becomes exploitable when an application exposes that primitive to a source the application does not fully control: a public configuration screen, an unauthenticated API, or content the agent processes as part of its normal work.

Four ways the same flaw was reached

OX Security grouped the exploitable paths into four families:

1. Unauthenticated or authenticated command injection via direct STDIO configuration. A UI screen lets a user supply the command and arguments for a new MCP server, and those values are passed to the launch call without validation.
2. Unauthenticated command injection through configuration edits that bypass hardening. An application attempts to restrict which commands can be configured, but the restriction can be sidestepped.
3. Zero-click command injection via prompt injection. Content the agent processes — a document, a web page, a tool response — instructs the agent to edit its own MCP configuration and add a malicious STDIO entry, with no user interaction required. This is the pattern covered in more depth in threat model: indirect prompt injection.
4. Unauthenticated command injection via MCP marketplaces. A network request tied to browsing or installing a marketplace listing triggers a hidden STDIO configuration without the operator reviewing it first.

Each of the four independently produces the same outcome: an attacker's command runs with the privileges of the process that launched the MCP server.

Scale and affected projects

By OX Security's count, the underlying pattern touched more than 7,000 publicly accessible MCP servers and software packages, with a combined total of over 150 million downloads. Ten distinct CVEs were assigned across named projects at initial disclosure. Patch status is a moving target — it should be re-verified against each project's own advisory rather than taken from any single list, including this one — but the publicly confirmed status at the time of writing is:

Several related CVEs reported independently over the prior year — covering MCP Inspector, LibreChat, WeKnora, and a Cursor extension — trace to the same root pattern, which is part of why OX Security framed this as a supply chain event rather than a single vulnerability.

Why Anthropic calls the behavior "expected"

Anthropic's position is that the STDIO transport is working as designed: it is meant to start a local process under the operator's own privileges, the same way any script or CLI tool would. The design assumption is that only a trusted operator supplies the launch command. The vulnerability appears when applications built on the SDK let that assumption break — by exposing the configuration surface to public users, to marketplace content, or to anything an agent might read and act on. That is the same class of trust-boundary failure behind server-side request forgery, covered in SSRF risks in agent tool calls: a primitive that is safe inside one trust boundary becomes dangerous the moment an application lets an untrusted input reach it.

OX Security put it directly: "What made this a supply chain event rather than a single CVE is that one architectural decision, made once, propagated silently into every language, every downstream library, and every project that trusted the protocol to be what it appeared to be." For readers who want the baseline protocol mechanics before going further, see what is Model Context Protocol (MCP).

What MCP adopters should check now

• Inventory every MCP server you run or depend on, and flag any that accept STDIO configuration through a UI or API reachable by anyone other than a trusted operator. Shadow MCP server detection covers how to find the servers nobody formally registered.
• Confirm STDIO configuration changes require authentication and an authorization check separate from general login — not just that a login screen exists somewhere in front of the application.
• Trace whether any agent-processed content has a path to your MCP configuration. If a document, email, or web page an agent reads could plausibly reach a configuration-edit action, you have the zero-click path described above.
• Review how your marketplace or registry ingestion handles new listings. If adding a server from a public catalog can trigger an STDIO launch before a human reviews the command, that is exploitable per family four above. Registering and governing MCP servers covers the approval workflow this requires.
• Sandbox MCP server processes, especially any accepting externally supplied configuration, so a successful command execution cannot reach secrets or systems beyond what that specific tool needs. See tool use safety and sandboxing agent actions.
• Log every MCP tool invocation and STDIO launch command. How to monitor MCP tool calls covers what to capture so an anomalous launch command is visible after the fact, not just in hindsight during an incident.
• Track the specific CVEs for the tools you deploy against the vendor's own advisory. Patch status changes; a list compiled in April 2026 is a starting point, not a current-state answer.

The broader supply-chain lesson

A single architectural decision in a widely reused SDK, replicated silently across every language binding and every project built on top of it, is close to a textbook definition of a software supply-chain risk — the same pattern examined in securing the AI agent supply chain. The practical takeaway for anyone building or operating MCP infrastructure is that a security review of "your" code is not sufficient; the SDK and transport layer underneath it carry assumptions that need to be checked explicitly, not inherited on trust. A general checklist for hardening MCP deployments against this and adjacent classes of issue is in the MCP server security checklist, and the broader question of what MCP server governance should cover as a program, not a one-off review, is in the MCP server governance guide.

Praesidia is an AI agent security and governance control plane covering agent identity and access, guardrails, audit evidence, and cost controls; MCP tool governance — scoping what a connected server can be asked to do — is one of the areas that reduces the blast radius when an upstream flaw like this one surfaces.

Common questions

Does this affect MCP servers that use HTTP or SSE transport instead of STDIO? The disclosed vulnerability family is specific to how the STDIO transport handles server launch and configuration. HTTP- and SSE-based MCP servers have a different set of risks, typically around authentication and authorization of remote requests. Do not assume a non-STDIO deployment is unaffected by every issue in this family without checking the specific CVE details for the transport you use.

Has Anthropic changed the MCP SDK or specification because of this disclosure? As of the OX Security advisory, Anthropic had not modified the reference SDK's STDIO launch behavior, characterizing it as expected given the design assumption that only a trusted operator supplies the launch command. Check the current MCP specification and SDK changelog directly before assuming the underlying behavior has changed since April 2026.

How do I find out if a specific MCP server I use is affected? Check the project's own security advisories and changelog for the CVE identifiers listed above, and search for the project name alongside "MCP STDIO" in the National Vulnerability Database. Because this is a supply-chain issue rather than a single product bug, a project not named in the initial ten disclosures can still share the same underlying pattern.

Is upgrading the MCP SDK itself enough to fix this? Not by itself. Because Anthropic did not change the SDK's STDIO launch behavior, the fix in every patched project listed above was applied at the application layer — restricting who can supply STDIO configuration and validating what is accepted — not inside the SDK. Upgrading a dependent library without also reviewing your own configuration-handling code will not close the gap.

How is this different from a typical prompt injection vulnerability? Prompt injection manipulates what an agent decides to do; this vulnerability is about what happens once a command reaches the STDIO launch call, regardless of how it got there. The two compound in family three above, where prompt injection is the delivery mechanism and the STDIO design flaw is the payload's effect — a zero-click path from untrusted content to command execution with no separate authentication step in between.