MCP STDIO risk: when config becomes command execution

OX Security’s MCP research is a clear reminder that MCP over STDIO is not just a transport choice. The moment command and args can be influenced by untrusted input, your MCP integration becomes a generic subprocess launcher.

This is a supply‑chain and trust‑boundary problem, not a one‑off bug. Anywhere MCP configuration is treated like normal user data—or “installing an MCP server” is treated like importing a library—you risk turning configuration into remote code execution (RCE).

---

The root pattern: data that becomes a subprocess

At the core is a simple pattern:

• Safe pattern: The developer hardcodes a known command and arguments, e.g. command = "python", args = ["myapp.py"], to start a trusted local MCP server.
• Dangerous pattern: command and args are derived from user input or other untrusted data, e.g. command = user_input_command, args = user_input_arguments.

Once untrusted data controls command and args, the MCP client is no longer just speaking a protocol—it is executing arbitrary OS processes. Even if the client later rejects the process as “not a valid MCP server,” the command has already run.

This is why MCP STDIO must be treated as a code execution boundary. Any path that lets untrusted data reach command or args is equivalent to exposing a generic subprocess API.

---

Four exploit families to internalize

OX’s advisory groups real‑world issues into four exploit families. They map directly to where you should put defenses.

1. MCP config injection through a UI

When a product exposes an “add MCP server” feature in a web UI and accepts JSON that can specify STDIO command and args, that UI becomes an RCE surface on the host running the backend.

Patterns seen in the wild include:

• Authenticated or semi‑authenticated users submitting MCP configs that flow directly into StdioServerParameters (or equivalent) and are executed.
• Token‑based flows where an attacker first obtains a bearer token (e.g. via an auto‑login endpoint) and then uses it to POST a malicious MCP STDIO configuration.

The key mistake is treating MCP server definitions as data instead of as execution recipes.

Defensive focus:

• Do not let UI‑supplied JSON directly specify command and args.
• If configuration must be user‑driven, make it a selector over a predefined set of vetted servers.
• Enforce transport type and server identity on the backend, not just in the UI.

---

2. Allowlist hardening that fails through arguments

Some teams try to harden by allowlisting only certain commands, e.g. "npx" or "node". OX shows how fragile this is when the allowed command itself can execute arbitrary code via flags.

Example pattern:

• Allowlisted command: npx
• Attacker uses: npx -c "<arbitrary shell>"

Here, the outer command is “safe” according to the allowlist, but its arguments are an execution escape hatch.

Why this matters:

• Ad hoc input filtering (e.g. stripping special characters) is brittle.
• Many developer tools (npm, npx, python, bash, sh, node, etc.) have flags that interpret strings as code or shell.

Defensive focus:

• Treat argument validation as parsing, not sanitization.
• For commands that can execute code from strings or the network, either:
  • Disallow the dangerous flags entirely, and enforce a strict argument grammar, or
  • Disallow those commands in multi‑tenant or untrusted contexts.

---

3. Prompt injection that edits local MCP config (IDEs)

IDE agents and local assistants often let the model edit configuration files, including MCP config. If those files are writable via model‑directed edits, prompt injection can escalate into local code execution.