You might think your smart home setup is just a collection of lights and thermostats, but if you are experimenting with the Model Context Protocol (MCP), you are effectively running a small, potentially exposed server in your living room. OX Security’s ‘Welcome to the Jungle’ report, published this month via The Hacker News, scanned 15,465 publicly indexed MCP servers across five registries and found that about 0.45% are running on personal or home machines, often exposed via consumer tunneling services like ngrok. While that percentage seems small, it represents a wide-open door for anyone scanning the internet for vulnerable hardware.
The ‘By Design’ Vulnerability #
The core issue is not a simple bug; it is a fundamental architectural choice. Anthropic’s official MCP SDKs for Python, TypeScript, Java, and Rust utilize a transport method called STDIO. This method accepts a ‘command’ parameter and executes it verbatim without any sanitization. When researchers at OX Security highlighted that this creates a systemic command injection vulnerability, Anthropic confirmed the behavior is by design and declined to make protocol-level changes, pushing the entire burden of sanitization onto developers. Earlier this year, OX Security’s supply chain advisory estimated roughly 200,000 vulnerable MCP server instances globally, with over 7,000 publicly accessible and 150 million-plus SDK downloads.
Proven Exploitation Paths #
The risk is already manifesting in the wild. CVE-2025-6514, a critical remote code execution vulnerability with a CVSS score of 9.6, affected the mcp-remote npm package — the OAuth proxy many MCP clients rely on to connect to remote servers. JFrog discovered the flaw in July 2025; it earned an EPSS score of 77%, meaning a 77% probability of exploitation within 30 days. CVE-2026-30624, a high-severity RCE in Agent Zero, allowed users to define MCP servers with arbitrary commands that executed without validation. These are proven paths for attackers to gain control over the machines running these agents, turning your home automation hub into a liability.
The AI Worm Connection #
This architecture creates the environment for the AI worm scenario Anthropic’s own Frontier Red Team warned about. Researchers demonstrated that small AI models can self-replicate across consumer IoT devices without needing root privileges — because the inference engines run in userspace, the AI can move from device to device without breaking through the operating system. Combine an unvetted, ‘by-design’ command injection flaw with a self-replicating agent, and you have a supply-chain mechanism that could turn your smart home into a node in a much larger, unwanted network.
What Home Users Should Know #
Not all MCP implementations carry the same risk. Google Home MCP, which launched in early access in September, uses SSE (Server-Sent Events) transport with OAuth — a significantly safer architecture than STDIO. It is also a premium, US-only service requiring a developer-oriented setup through Google Cloud Console. Home Assistant’s built-in MCP integration uses OAuth 2.0 with PKCE, another meaningful step up. Be cautious with community-made projects like ha-mcp, which can provide direct write access to your home configurations and automations.
The financial reality is this: enterprises are spending heavily to secure their AI deployments, but the home user navigating these risks alone is the norm, not the exception. If you are running an MCP server at home, treat it like any other exposed service. Assume it is being scanned. Assume the protocol will not protect you. Keep your exposure to the public internet as close to zero as possible. If you do not absolutely need it accessible from outside your home, turn off the tunnel. Your thermostat will thank you.