← Blog

MCP Security for Security Leaders: Why Local STDIO Servers Are the New Shadow IT

By Eito Miyamura

Overview

Can you name the MCP servers running on your employees' computers today? Each install is a potential RCE on the user's computer, and CVE-2025-6514 in mcp-remote is the recent example: a critical unauthenticated RCE rated CVSS 9.6 with 437,000 npm downloads, in the STDIO bridge that Claude Desktop and Cursor use to connect to remote MCP servers. There is no automated inventory of these servers, no telemetry from them, and no central control over how they were installed.

MCP, STDIO, and Remote in Plain Terms

MCP is the Model Context Protocol, the standard way an AI assistant connects to external tools and data sources like GitHub, Slack, or an internal database. The connection runs through an MCP server, the program that exposes those tools to the AI client. Two transports exist: a remote MCP server runs on someone else's infrastructure and the AI client reaches it over HTTPS, and a local STDIO MCP server runs as a subprocess on the user's own computer, talking to the AI client over standard input and output.

The "local" label is misleading. Most STDIO servers are thin wrappers around outbound HTTPS calls to GitHub, Slack, or other external services. The data leaves the user's computer the moment the wrapper runs.

The STDIO Trust Collapse

An April 2026 audit of the MCP supply chain found that the default STDIO transport in every official MCP SDK executes operating-system commands supplied through its configuration channel with no sanitization and no execution boundary. Up to 200,000 MCP instances were estimated vulnerable, extrapolated from roughly 7,000 publicly reachable STDIO servers and over 150 million SDK downloads. Anthropic declined to change the protocol, updating SECURITY.md nine days after disclosure rather than altering the SDK behavior.

The architectural problem reduces to one sentence: STDIO collapses the trust boundary between the AI client, the configuration channel, and the tool integration. The user who edits the config gets code execution on the host. The package the user installed reads the config. The agent the user runs can write to the config. Three layers an enterprise normally separates are now a single trust zone.

Three Install Paths Your Security Stack Does Not See

A local STDIO MCP server arrives on a developer's computer in one of three ways that no DLP, CASB, or EDR is configured to flag:

  • JSON paste from a vendor README: the user opens claude_desktop_config.json (or .cursor/mcp.json, .vscode/mcp.json) and pastes a server entry. No package manager, no review, no telemetry. The first run is also the first time the binary is fetched.
  • npx-style command: the user runs npx @some-vendor/some-mcp-server from a vendor's quickstart. The package is downloaded on demand from npm, executed once, and added to the config file so the server runs every subsequent session.
  • Agent-initiated install: an AI agent the user is already running, prompted to do work that requires a new tool, installs an MCP server on the user's behalf. No human reviews the install; the agent both decides to install it and immediately uses it.

Security teams' shadow-IT playbooks were written before AI agents could install software autonomously, so the third path is the one without a runbook. An autonomous agent that can install MCP servers can chain three of them in a single session: one to read private data, one to read untrusted content, one to send outbound. That is what Simon Willison, co-creator of Django, calls the lethal trifecta, assembled at runtime by the agent itself.

The Incident Record Is Already On the Books

The MCP-STDIO RCE catalogue for 2026 has six NVD-confirmed entries across shipping AI products:

  • CVE-2026-40933 (Flowise <3.1.0): npx -c bypass of validateCommandInjection lets configuration content execute as a subprocess.
  • CVE-2026-30615 (Windsurf 1.9544.26): HTML-rendered prompt injection modifies the local MCP config and auto-registers a malicious STDIO server.
  • CVE-2026-30617 (LangChain-ChatChat 0.3.1): attacker-controlled command and arguments in MCP STDIO config.
  • CVE-2026-30624 (Agent Zero 0.9.8): arbitrary command and arguments via MCP config JSON.
  • CVE-2026-30625 (Upsonic 0.71.6): allowlist bypass via npx flags in a STDIO task.
  • CVE-2026-26015 (DocsGPT 0.15.x): switches transport from SSE to STDIO and injects commands through the "MCP test" endpoint.

Three named supply-chain incidents in the same period make the same point with a different mechanism:

  • postmark-mcp backdoor: an npm package with 1,643 downloads silently BCC'd every outbound email to an attacker. First confirmed in-the-wild malicious MCP server, as Snyk first documented (https://snyk.io/blog/malicious-mcp-server-on-npm-postmark-mcp-harvests-emails/).
  • Shai-Hulud worm: compromised npm publishing tokens were used to push rogue MCP servers into Claude Code, Cursor, and Windsurf installs, exfiltrating SSH keys and AWS credentials.
  • CVE-2025-6514 in mcp-remote: a critical unauthenticated RCE in the STDIO bridge clients use to reach remote MCP servers, 437,000 npm downloads.

Snyk's parallel scan of the broader AI agent skill ecosystem (https://snyk.io/blog/toxicskills-malicious-ai-agent-skills-clawhub/) found 76 of 3,984 skills contained outright malware and 5 of the 7 most-downloaded were malicious. The supply chain that feeds local STDIO MCP servers is the same one.

Shadow MCP, and Why Existing Controls Miss It

Industry analysts have framed unmanaged MCP servers as a new form of shadow IT, and the technical reason existing controls miss this category is the STDIO trust collapse: CASB, DLP, and EDR were each designed for a different surface (SaaS sign-ins, outbound HTTPS bytes, binaries and processes), and a piece of software installed via npx that holds an API token your security team never issued is none of those surfaces.

Alice, a data scientist, pastes a database MCP server config into Cursor on Monday so her agent can answer questions about the prod schema. By Friday she has installed five more servers from quickstarts, two of them by asking the agent to do it for her. None of those servers is in any inventory, none of the credentials in ~/.cursor/mcp.json is tracked in your secret store, and the agent has full execution authority on her behalf for all five.

How to Govern MCP: Three Options

Security teams have three real options, each with a different tradeoff between operational cost and residual risk:

  1. Ban local STDIO MCP servers outright. Enforced via MDM and EDR application allowlisting against tools the security team can preregister. Developers who can install software on corporate-issued machines will route around it, and agent-initiated installs evade the policy because the agent looks like a sanctioned binary.
  2. Sandbox local STDIO servers behind an egress proxy and pin dependencies. Run the STDIO process in a constrained network namespace that only reaches an enterprise egress proxy. Require signed and pinned versions. Centralize the config file in a managed-secret form. Recovers logging, DLP, and revocation. The credential aggregation problem inside the config file and the agent-initiated install vector remain unsolved.
  3. Replace local STDIO with managed remote MCP behind an enterprise gateway. Tokens issued at the enterprise identity provider, traffic mediated by the gateway, tool calls logged, RBAC enforced server-side. This is the option the protocol stewards are themselves moving toward: the November 2025 transport spec (https://modelcontextprotocol.io/specification/2025-11-25/basic/transports) and the OAuth 2.1 authorization spec (https://modelcontextprotocol.io/specification/draft/basic/authorization) are oriented to Streamable HTTP. Tradeoff: every MCP server an enterprise wants to use must be reachable over HTTPS through the gateway, which means waiting for vendors to ship remote builds and operating the gateway yourself.

For organizations with a sizable engineering footprint, option (3) is the right answer, with option (2) as the temporary state for servers that have no remote build yet. Option (1) only works inside a small, locked-down workforce.

Where Existing Vendors Sit

Multiple vendors are converging on managed remote MCP at the gateway layer, with different scope:

No single product is the right answer for every organization. The questions to ask: does the vendor cover STDIO clients as well as remote ones; does it enforce policy deterministically or rely on the model to refuse; does it handle the agent-initiated install case; does it integrate with the identity provider, secret store, and SIEM you already operate.

Core Takeaway

Local STDIO MCP servers are unmanaged code with privileged API access, installed through three paths that no existing security control inspects, and the protocol's own design collapses the install trust boundary onto a single configuration file. The 2026 CVE record across Flowise, Windsurf, LangChain-ChatChat, Agent Zero, Upsonic, and DocsGPT shows the design choice has already produced exploitable bugs in shipping software, and the supply-chain incidents (postmark-mcp, Shai-Hulud, mcp-remote) show the attacker model is real. Move MCP onto a managed remote footing now, sandbox the STDIO holdouts behind an egress proxy in the meantime, and inventory the install paths your security stack does not see today.

References