MCP servers executable at scale: what the Anthropic SDK chain means for AI agents in the German Mittelstand

TL;DR — the 90-second summary

Affected?

Every locally starting MCP server (STDIO transport) invoked via a client-side config file — Claude Desktop, Cursor, Continue, Roo Code, custom MCP clients. ~200,000 installations worldwide.

Risk?

Anyone able to change the config path or the command path of the MCP server controls the subprocess on the next client start. Direct code-execution path as the starting user — typically the developer account.

Immediate action?

Check config file permissions (~/.config/claude/claude_desktop_config.json and similar), pin MCP server paths to absolute binary paths, subprocess sandboxing where possible (bwrap, firejail, container).

Recommendation?

German Mittelstand with MCP stack: config audit + path pinning. Enterprise: additionally code-signing verification of MCP server binaries plus subprocess isolation.

Criticality?

High (see badge in the page header).

 

What is the problem?

The Model Context Protocol is Anthropic's standardized way to connect AI agents to external data sources and tools. An MCP server provides an AI application — Claude Desktop, Cursor, Continue, custom clients — with structured access to files, databases, APIs, or system commands. There are three transport variants: STDIO, SSE, and HTTP-Streamable.

The STDIO transport is the most common default. The client reads a configuration file (typically ~/.config/claude/claude_desktop_config.json on Claude Desktop), finds a command path and arguments per MCP server in it — and starts the server as a local subprocess. Communication runs over stdin and stdout in JSON-RPC format.

Exactly in this architecture sits CVE-2026-30623: anyone able to alter the config path or the command path referenced in it controls the subprocess on the next client start. There is no cryptographic verification of the MCP server binary, no code-signing check, no subprocess sandbox default. The subprocess starts in the context of the client user — typically the developer account on a workstation — with all permissions that user holds.

Anthropic classifies the behavior in its own disclosure as „expected“: the STDIO transport model assumes the client trusts the server subprocess. Whoever installed the server is responsible for what it executes. From Anthropic's perspective this is an architectural choice, not a bug. That's a defensible position — but it shifts responsibility fully to the operator.

Practically this hits a broad world: roughly 200,000 MCP server installations worldwide (per Anthropic telemetry from the disclosure post), including thousands of in-house and community-maintained servers that connect file, database, GitHub, JIRA, Confluence, or custom API access to Claude Desktop and comparable clients. Practically everyone who uses MCP productively today runs over STDIO — SSE and HTTP-Streamable are the exception.

Who is affected?

Reach follows MCP adoption — and that has grown sharply in the last six months. Three profiles from our advisory practice are acute today:

Cutting across these: every MCP installation with an npm- or pip-based server. The typical install runs via npx -y @modelcontextprotocol/server-filesystem or similar — a dynamic pull from the npm registry at client start, without a pin to a verified hash. Anyone on :latest pulls the current version on every start.

Mitigation and immediate actions

The short answer: check config file permissions, hard-pin MCP server paths, start the subprocess in a sandbox where possible. Four steps:

Check config file permissions

# Who can write the Claude Desktop config?
stat -c '%U %G %a' ~/.config/claude/claude_desktop_config.json
stat -c '%U %G %a' ~/Library/Application\ Support/Claude/claude_desktop_config.json  # macOS

# Target: user only, 0600
chmod 0600 ~/.config/claude/claude_desktop_config.json

Hard-pin MCP server paths

// INSTEAD: dynamic npx pull at every start
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me"]
    }
  }
}

// BETTER: absolute paths, pinned version, hash verification in update path
{
  "mcpServers": {
    "filesystem": {
      "command": "/usr/local/bin/mcp-server-filesystem",
      "args": ["/Users/me"]
    }
  }
}

Subprocess sandbox on Linux

# Start MCP server in bwrap sandbox
{
  "mcpServers": {
    "filesystem": {
      "command": "bwrap",
      "args": [
        "--ro-bind", "/usr", "/usr",
        "--ro-bind", "/etc/ssl", "/etc/ssl",
        "--bind", "/Users/me/Documents", "/data",
        "--proc", "/proc",
        "--dev", "/dev",
        "--unshare-net",
        "--die-with-parent",
        "/usr/local/bin/mcp-server-filesystem", "/data"
      ]
    }
  }
}

Code-signing verification in the update path

# Custom MCP server: verify signature before distribution
cosign verify-blob \
  --key cosign.pub \
  --signature mcp-server.sig \
  /usr/local/bin/mcp-server-internal

# CI/CD pipeline: only sign-verified binaries into the update stream

What „Claude will handle that“ doesn't solve. Anthropic stated the position clearly: the STDIO transport model is „as designed“. There is no patch that resolves the subprocess-trust question for you — it sits structurally with the operator.

Detection and verification

Five core questions if MCP runs in your stack:

• Which MCP servers are configured? Read the config file, list all mcpServers entries.
• Are absolute paths or dynamic loaders (npx, uvx) used? Dynamic = supply-chain risk on every start.
• Who can write the config file? Other users, other processes, Git hooks?
• Do subprocesses run sandboxed or directly? Direct = code execution with user privileges.
• Which tokens are accessible in the user account? GitHub, AWS, Azure, GitLab — anything the user has, the subprocess can fetch.

# Find MCP server configurations
for f in \
  ~/.config/claude/claude_desktop_config.json \
  ~/Library/Application\ Support/Claude/claude_desktop_config.json \
  ~/.cursor/mcp.json \
  ~/.continue/config.json; do
  [ -f "$f" ] && echo "=== $f ===" && jq -r '.mcpServers // .mcp.servers // {}' "$f"
done

# Check which binaries actually start
lsof -c claude 2>/dev/null | grep -E '(node|python|deno)' | head

Operator recommendation

The recommendation depends on the setup. Four scenarios, four answers — with an operational decision grid upfront:

Decision grid: when to harden now, when to wait for a maintenance window?

• Harden immediately if the config file sits in a Git repo where multiple people can write, or if dynamic loaders (npx -y, uvx) are used.
• Maintenance window acceptable if the config file lives only locally and all MCP server paths point to absolute, pinned binaries.
• Reduce token scope if the user account holds broad cloud tokens (AWS admin, GitHub owner). A compromised MCP subprocess sees everything.
• CI/CD pipeline with MCP? Isolate immediately. CI runners shouldn't carry a Claude Desktop workflow.

Developer workstation with Claude Desktop / Cursor

Config file 0600, all MCP server paths pinned to absolute binaries, dynamic npx -y loaders replaced with installed versions. Optional: bwrap sandbox on Linux for untrusted servers.

Team setup with shared MCP configuration

Don't keep the config in a Git repo that anyone can write unfiltered. If you must keep it in the repo: code-review obligation for config PRs, pre-commit hook against unexpected command path changes, signed commits.

German Mittelstand with custom MCP server stack

Code-sign MCP server binaries with cosign or sigstore. Update path with hash verification, not via direct npm pull. SBOM across all MCP servers that ship in the client distribution.

Declarative stacks (NixOS workstations, Talos bots)

The clean answer: MCP servers run over Nix store paths, are cryptographically hash-verified, the command path is deterministic in the store. If you use NixOS for your developer workstations, you have a structural advantage here — not for every CVE class, but for exactly this one.

What we actually did

At the Anthropic disclosure we ran our own MCP stack and that of our clients through a two-hour check. Pattern as with Comment-and-Control: SBOM across all MCP configurations, then concrete steps per stack.

• MCP config inventory. All developer workstations and CI runners scanned for claude_desktop_config.json, cursor/mcp.json, .continue/config.json. 23 workstations with active MCP, 14 of them with dynamic npx -y loaders.
• Config file permissions. Configs were world-readable (0644) on two workstations. Set to 0600.
• Path pinning. The 14 workstations with npx -y switched to absolute, installed binary paths. Versions distributed via npm install -g with lockfile pin.
• Custom MCP server stack. We run our own openly developed MCP server (not proprietary, open source). Introduced code signing via cosign, sigstore bundles on every release, hash pin in the update path.
• Token-scope review. Four workstations carried GitHub-owner rights and AWS-admin roles in the user account. Reduced to tightly scoped service tokens; MCP server gets its own identity with minimum scope.
• What we deliberately didn't do. Did not remove MCP from the workflow — the productivity value is real, the model is defensible. No switch to SSE or HTTP-Streamable as a pure „security-via-transport-change“ solution; the subprocess-trust question remains structural.

This routine is the operational practice behind DevSecOps as a Service and the External IT Department. Methodically, MCP STDIO sits in the same fabric as Comment-and-Control and Semantic Kernel: AI-agent architecture is a workflow and trust-boundary question, not a model question.

Technical deep dive

MCP's STDIO transport model is conceptually a classic Unix subprocess pattern: the client starts a server process, communicates over stdin and stdout, terminates the process on close. Three structural aspects are decisive for understanding CVE-2026-30623:

Client-driven subprocess start

At launch the client (Claude Desktop, Cursor, Continue) reads its configuration file. It contains a command path and arguments per MCP server. The client runs exec() on that path, in the context of the client user. There is no cryptographic verification of the binary, no sandbox default, no policy engine. Whoever sets the command path in the config determines what runs.

Dynamic loader path

The typical MCP install uses npx -y @modelcontextprotocol/server-foo or uvx mcp-server-foo as command. These loaders pull the current version from the npm or PyPI registry on every start. By default there is no hash pin, no version lock, no supply-chain verification. An npm account takeover or a compromised PyPI distribution compromises the next client start directly.

JSON-RPC frame and tool capability

The client sends tools/list and tools/call requests via the JSON-RPC stream over stdin/stdout. The server responds with tool capability descriptions and executes called tools. The model can trigger any tool call the server offers through the client. If the server is compromised, the tools are compromised — with user privileges.

Aspects for assessment

• Trust model is „intentionally flat“. Anthropic position: the STDIO model trusts the server. Whoever installs the server is responsible. That's consistent with the Unix subprocess pattern — unfamiliar in the web-security world.
• Config file is the actual target. Whoever can write controls the next start. 0600 permissions, signed commits, pre-commit hooks against unexpected path changes.
• Dynamic loaders are the supply-chain bridge.npx -y without pin is a :latest pull on every start.
• NixOS and declarative stacks gain structurally. Nix store paths are cryptographically hash-verified, deterministic, immutable. Setting the command path to a Nix store path locks the subprocess start cryptographically.

Conclusion

CVE-2026-30623 isn't a software vulnerability in the classic sense — it's an architectural choice that Anthropic openly leaves standing as „expected“. The STDIO transport model trusts the server subprocess, and the client starts it with user privileges. Anyone using the system productively carries the subprocess-trust question structurally themselves.

What matters more operationally than the individual CVE is the pattern behind it: every MCP configuration with a dynamic loader and a writable config file is a potential subprocess C2 channel. Anyone who has consistently driven config permissions to 0600, path pinning to absolute binary paths, and code signing in the update path answers the next comparable disclosure in hours, not in subprocess forensics.

Realistic risk framing: high for workstations with cloud-admin tokens and dynamic MCP loaders. Medium for German Mittelstand stacks with pinned configuration. Low for declarative setups (NixOS, Talos) that lock subprocess paths cryptographically. The question isn't when the next comparable MCP finding will arrive. It's whether you experience it on a configuration where every subprocess start is traceable and cryptographically pinned — or on one where an npm account takeover is enough to compromise the next client start.