Skip to content
← All articles

Home MCP servers: the flaw Anthropic calls by design

Oct 18, 2026 · Automation · 4 min

·By Dimitri Pisarev

If an MCP server runs on your home machine, the protocol's maker considers at least part of the exposure intended. OX Security scanned 15,465 publicly indexed servers and found consumer tunnels, expired domains and personal hardware behind them. The official SDKs take the launch command from config and execute it verbatim.

Why is the official SDK the risky part?#

The Model Context Protocol ships two transports. The local one, STDIO, starts a process: the client reads a command out of its configuration and runs it. OX Security's researchers walked the SDKs Anthropic maintains for Python, TypeScript, Java and Rust and found the same shape in all four. The command parameter arrives in plain text, and the SDK executes it without sanitization, allowlisting or signature verification (Yahoo Tech has the full writeup).

A config file that executes has been normal for a long time. package.json scripts run on every install, CI runners execute whatever the repository contains, and Docker Compose boots whatever the compose file names. MCP inherits that model. The difference is what sits behind it: a protocol that hands models real tools deserves extra suspicion at the launch step.

Where the story sharpens is the response. OX Security reports that Anthropic confirmed the behavior is by design and declined protocol-level changes, with the argument that production deployments typically use the remote transport and OAuth 2.1. That is a coherent answer for a company whose products call servers in the cloud. It leaves the home user holding a default path that trusts every line of its config file.

What the scan found#

The numbers come from OX Security's "Welcome to the Jungle" report, published on The Hacker News at the start of October: five registries, 15,465 indexed servers, 5,095 unique hostnames once duplicates collapse. 15.6 percent of the hostnames sit outside the United States, including 19 in China and 18 in Russia.

Two slices of the sample deserve attention. 0.45 percent of the servers route through consumer tunneling services, mostly ngrok, which usually means a home machine or an office desk rather than a server room. And 2.3 percent dangle on domains nobody maintains; six had already expired and were buyable for 4 to 12 dollars a year. Whoever registers one of those names first inherits every client that still points at it. An earlier OX advisory put the wider exposure at roughly 200,000 vulnerable MCP server instances worldwide, more than 7,000 of them reachable without authentication, on SDKs with more than 150 million downloads.

The attack paths are already catalogued#

A critical command injection in mcp-remote, the npm bridge that connects desktop clients to remote servers, drew CVE-2025-6514 with a CVSS of 9.6 from JFrog in July 2025. Yahoo Tech's summary of the OX report adds an EPSS score around 77 percent, which puts it among the flaws most likely to get exploited.

The forward-looking scenario comes from Anthropic's own Frontier Red Team. The Hacker News covered it on 13 October: across eleven open-weight models tested, GLM-5.2 from Zhipu was the only one that reliably carried Llama3.1-8B to all eight emulated Android nodes, succeeding in four of five trials, with the worm carrying the weights it needs as payload. A separate test distributed image captioning for Gemma4-26B-A4B across fifteen smart TV boxes. Anthropic's team concluded that no complete self-replicating AI system exists yet, and that the parts need no breakthrough, only assembly.

A home machine running an MCP server behind a consumer tunnel looks exactly like that assembly target: always on, weakly monitored, holding valid credentials, and advertising a protocol whose launch path executes config verbatim.

What a safer setup looks like#

Read the MCP configuration as code, because it executes as code. Pin versions, review entries before they enter the file, and re-verify after every update. The Snyk session on banning AI coding tools made the same point for the tool layer: a clean MCP server does not stay clean through its next release.

Then remove the tunnel. A server that must be reachable over the network should take the authentication any API would get. The contrast already exists inside the ecosystem: Google's Home MCP integration uses Server-Sent Events with OAuth, and Home Assistant ships OAuth 2.0 with PKCE on its built-in MCP server, while the community ha-mcp project hands a model direct write access to the whole Home Assistant instance, which is the design to avoid. Anthropic's own recommendation, remote transports with OAuth 2.1, is the same answer in vendor wording.

Isolation is the last layer, and it needs no vendor: the pattern from Chainguard's Workspaces launch runs on plain Docker. Execution off the machine that holds keys, egress denied by default, credentials injected per request.

This site carries a small MCP server of its own, the demo shop at /api/mcp: Streamable HTTP, stateless, read-only, four tools, nothing that writes. Serving a read-only catalog over a spec-compliant transport is the easy end of this problem. The hard end is the home machine with a tunnel, a write-capable server, and a config file nobody has read since the day it was pasted in.