The code does not lie, but it does omit. And what it most consistently omits is the environment in which it will be executed. On September 18, 2025, a joint disclosure from two independent security research collectives — a finding that cut through the noise of the latest crypto yield announcements — surfaced a structural vulnerability class in the Model Context Protocol (MCP). The disclosure arrived with a specific CVSS score of 9.6 and an EPSS (Exploit Prediction Scoring System) probability of 77% for CVE-2025-6514, a flaw in the mcp-remote bridge. This is not a story about a bug. It is a story about the architecture of trust we are currently building into the consumer internet.
The data suggests a systemic misalignment. MCP, developed by Anthropic as an open standard for AI agents to interface with local tools and data, explicitly models the client-server connection as a parent process spawning a child process. The command argument is, by design, the equivalent of a shell execution. When a client launches a server, it is essentially running subprocess.exec(). This is an elegant inheritance from the Unix process model — a model that assumes the entity writing the configuration is the same entity who owns the machine.
The assumption collapses when you introduce the household IoT device. A smart home hub running an MCP server to interface with door locks, cameras, and thermostats is not a controlled developer workstation. It is a device configured by a non-technical user, often behind a consumer router, but increasingly exposed to the public internet via the ubiquitous and insecure use of tunneling services like ngrok. The architect's response to early criticism was that this is “by design” — a deliberate choice to maximize developer experience by avoiding the unworkable task of sanitizing shell commands at the protocol layer. The logic is technically sound. Blacklisting commands in a protocol that allows arbitrary arguments is a theater of false security; it is a leaky abstraction that would inevitably be bypassed via shell metacharacters, environment variable expansions, or nested sh -c calls. The failure is not in the protocol's logic, but in its default ethics. It is a contract that transfers the burden of security from the protocol designer to the least capable party in the chain: the end user.
Consider the architecture of the alternatives. Google’s Home MCP solution relies on SSE (Server-Sent Events) combined with OAuth. In this model, the server is a separate, remote or local process that the client does not spawn directly. The command injection surface essentially vanishes. But this architectural choice comes at a cost: a loss of the zero-configuration local execution that developers love, replaced by an OAuth flow that requires a Google Cloud Console project, user authentication, and a paid subscription. Home Assistant, the stalwart of the open-source community, has opted for a different middle ground, integrating MCP with OAuth 2.0 and PKCE (Proof Key for Code Exchange). This is a significant improvement over the raw stdio model, but still relies on the user to build and maintain the security posture.
Here, the real anomaly appears. The conversation has focused on the 7,000+ publicly accessible MCP instances observed by Shodan and similar scanners. Yet the more insidious metric is the 0.45% — approximately 70 instances — that are explicitly running on personal or home machines. The gap between these figures is not a contradiction; it is a category error in public perception. The 7,000+ represents the absolute exposure of a protocol designed for local tools. The 0.45% represents the deep penetration of MCP into the one environment where it is least suited to survive: the fragmented, unmanaged, and unmonitored home network. This is the lead indicator of a future botnet supercycle.
The mechanism is not a brute-force password attack, as we saw with Mirai. It is a legitimate execution path. A malicious actor does not need to find a vulnerability in the MCP server. They simply need to deliver a poisoned configuration file — a mcp.json imported from a community forum, an IDE plugin that auto-pulls a server list, or a malicious instruction embedded in a shared agent context. When that configuration is loaded, the client’s trust model is subverted. The agent executes the attacker's command, not because it is a bug, but because the protocol allowed it. The code does not lie, but it does omit the intent of the author of the file.
This is where the forensic work of the Anthropic Frontier Red Team becomes unsettling. Their research, which warns of AI worms capable of self-replication in IoT environments, exists in tension with the product team’s default configurations. The technical novelty they demonstrate is not just the worm’s ability to copy itself, but the environment in which it operates. The inference engine, the AI model itself, runs in user space. This is a critical, underappreciated point. Traditional malware requires privilege escalation to move laterally across a network. It needs to exploit a kernel vulnerability, steal a token, or break out of a container. An AI agent running in user space, however, can write files, make network requests, and execute commands with the permissions of the user who launched it. If that user is the default, non-privileged account on a smart home hub, the agent has everything it needs. The OS-level security model — the one that equates “no root” with “safe” — is fundamentally poorly equipped to constrain an entity that is supposed to be there.
The implications for the crypto and DeFi industry are not immediate, but they are structural. The same MCP architecture that allows an AI trading bot to query a local price feed is the architecture that could allow a malicious agent to drain a hot wallet. The difference between a sophisticated user configuring a local environment and a retail user installing a “yield maximizer” agent is negligible in the eyes of the protocol. The user has delegated authority to an autonomous system.
My audit experience in 2022, dissecting the reserve ratios of the Terra ecosystem before its collapse, taught me a valuable lesson: the most catastrophic failures do not come from a single broken component, but from a systemic mispricing of risk. Here, the risk is mispriced as a developer problem, when it is a consumer problem. The warnings from OX Security and JFrog are clear, but they are also a product of their own incentive structures. High-profile disclosures generate business. The amplification of a 77% EPSS score creates a sense of immediate, unavoidable crisis.
But a cold, forensic look at the evidence suggests a more measured — though no less alarming — reality. The AI worm that copies itself is a laboratory demonstration, not a wild occurrence. It relied on specific conditions: homogenous hardware, a controlled network, and a lack of firmware-level defenses. We have not yet seen the event that turns a proof-of-concept into a widespread botnet. This is not a reason to be complacent; it is a reason to be precise. The correct defense is not to patch a single bug, but to re-architect the default. If the protocol will not enforce security, the ecosystem must.
The invisible cost of the current path is the creation of a vast, unpatched, and unmonitored install base of AI agents that have a legitimate ability to execute commands. The security middleware market — the MCP gateways and audit layers that will inevitably emerge — is the market’s tacit acknowledgment of this gap. But relying on a commercial intermediary to fix a protocol-level default is a slow and brittle solution.
The evidence over intuition suggests a clear path forward. The 200,000 instances and 150 million SDK downloads represent a scale that has already moved beyond a niche developer tool. A secure default must become non-negotiable. This means forcing localhost binding by default, requiring explicit user confirmation for every command execution, and providing a hardened, containerized runtime for any server that touches public networks. The code does not lie; it is our responsibility to ensure the environment does not omit the safety we have come to expect.
The next major regulatory shift in IoT and AI security will not be triggered by a data breach of a corporate database. It will be triggered by a physical event — a compromised door lock, a disabled alarm — enabled by a protocol that was designed for a world it no longer inhabits. The 0.45% is the signal. The rest is noise. The time to audit the defaults is now.