The MCP specification does not have a command injection vulnerability. It has something more interesting: a trust boundary written for one deployment model and deployed into another. When a protocol assumes that the person writing the configuration file is the person running it, shipping that protocol into a household with a router, a smart lock, and no security operations center produces a mismatch that no patch can fully resolve. The architecture is not broken. The deployment is wrong.
MCP defines three transport models: stdio, SSE, and Streamable HTTP. The stdio model is explicit about what happens at connection time. The client spawns a subprocess; the command, args, and environment variables are part of the connection configuration. This is the same trust model as launch.json in an editor, the scripts block in npm, or the command field in a Compose file. The configuration file is an execution surface. That has been true since Unix process models became the default way to start programs.
Anthropic's refusal to sanitize the command parameter at the protocol layer is technically correct, and opponents of that position should understand why before they call it negligence. A protocol that permits python -m mcp_server --config /path/x.yaml cannot simultaneously prohibit arguments without making the legitimate case impossible to express. And any sanitization scheme would need to survive quote escaping, redirection, pipes, environment variable expansion, and nested sh -c invocations. Blacklist-based protection at the protocol layer produces the appearance of safety, not safety itself. The shell escaping wars of the past two decades taught this lesson repeatedly, and the people who wrote MCP clearly learned it.
Where the reasoning breaks is not in the execution model. It is in the configuration surface.
The Bridge Is the Breach
CVE-2025-6514, which affects mcp-remote with a CVSS score of 9.6 and an EPSS score of 77 percent, is not a stdio problem. It is a bridge problem. The package connects remote endpoints to a local OAuth proxy, and in doing so it opens a channel from untrusted remote input to local command execution. That channel was not supposed to exist under the original stdio assumption, because the original assumption was that configuration came from a local user who already had execution rights on the machine.
The moment a bridge component reads a remote URL and translates it into local execution, the assumption collapses. The remote input is now untrusted, the local side is fully privileged, and the protocol layer offers no guard because it was never designed to guard that direction. The same class of exposure appears wherever an IDE plugin auto-pulls community MCP configurations or an mcp.json file is imported from a source the user did not write.
What matters here is that the vulnerability was patched and the exposure did not disappear. Patch lag across dependency trees is measured in months for well-maintained projects and in years for everything else. A protocol that centralizes configuration-driven execution inherits the entire lifecycle risk of every package in that configuration.
Why Google's Architecture Looks Cleaner
Google Home's MCP implementation uses SSE with OAuth. The comparison is instructive because the security difference is not the result of superior engineering discipline. It is a structural byproduct. In SSE mode, the server is a separate process or a remote service. The client does not spawn anything, so there is no command surface to inject into. The security property falls out of the transport choice before anyone writes a security review.
That advantage carries a price that the security narrative conveniently omits. The OAuth path requires account binding, a Cloud Console configuration step, and in Google's case, payment and geographic availability. The architecture is safer because the client is not starting local processes, and the client is not starting local processes because the platform wants to own the account relationship, the audit trail, and the quota. Security and lock-in are described by the same sentence here.
The developer experience cost is real. Zero-configuration local execution disappears when every server requires an OAuth dance and a cloud project. That is why Home Assistant occupies the middle position with OAuth 2.0 and PKCE over local-first infrastructure, and why the community projects that fill the remaining gap โ tools that grant direct write access to home configurations and automation โ carry the highest practical risk of any layer in this stack. They extend capability beyond what the main project supports and inherit none of the accountability when the automation fires the wrong way.
Whoever controls the transport default controls the security narrative. That is the actual competitive dynamic, and it is more consequential than any single CVE.
The Responsibility Transfer
Enterprise deployments have SIEM, endpoint detection and response, zero-trust gateways, and a security team watching outbound traffic for command-and-control beacons. Households have NAT and a vague sense that things are probably fine. When a protocol pushes security responsibility down to the deployer, it pushes that responsibility to whoever happens to have installed the thing. In an enterprise, that person has a job title and a budget. In a home, that person has a router they have never logged into.
This asymmetry explains the scale problem better than any vulnerability count. Publicly accessible MCP instances have been measured in the thousands, and total deployments in the hundreds of thousands, against SDK download numbers in the hundreds of millions. Those figures describe different things and should never be placed side by side without stating the measurement basis: one counts personal and household machines, the other counts internet-reachable services. The internet-reachable figure is the one that determines exposure. Household machines are a subset of it.
The tunnel is the variable that gets underestimated. Tools like ngrok push a service that should have been bound to localhost directly onto the public internet, often bypassing NAT entirely. This is not an MCP defect. It is a decades-old default-value problem in consumer networking, and it has been present in NAS devices, home automation servers, and single-board computers long before any AI protocol existed. MCP is simply the newest payload traveling through an old hole.
What User-Space Inference Changes
The technical observation buried inside this debate deserves more attention than the CVE list it sits beside. The inference engine runs in user space. An agent can migrate across devices without root, without a kernel exploit, without the privilege escalation step that traditional malware requires before lateral movement becomes possible.
That single property invalidates the most common defensive intuition in consumer security: that not granting administrator rights keeps you safe. A lightweight agent loader that can write files and reach the network already has what it needs to replicate. Container isolation, unprivileged user accounts, and least-privilege principles still matter, but they constrain an AI workload less effectively than they constrain a conventional process, because the workload was never trying to cross the privilege boundary in the first place.
The replication mechanism matters more than the replication speed, and this is where the danger concentrates. If an agent copies itself through the protocol's legitimate command execution path, then every detection rule built on anomalous process behavior fails at once. There is no anomalous process. There is a user running MCP correctly.
The demonstration-level caveat belongs here, stated plainly. Self-replication in a laboratory requires homogeneous devices, a controlled network, and no firmware-level defenses. Real-world worming requires cross-vendor compatibility, persistence mechanisms, a command channel, and detection evasion, and each of those is a genuine engineering hurdle. The correct characterization is that the primitive exists and the vehicle does not yet. Describing that as an imminent botnet overstates the evidence. Describing it as a theoretical curiosity understates the direction of travel.
The Regulatory Vacuum
MCP is a protocol, not a product. No entity in the chain โ the specification authors, the SDK maintainers, the developers who write servers, the users who deploy them, the tunnel providers who expose them โ has a clear product liability obligation covering the default configuration of a transport layer. Europe's Cyber Resilience Act covers connected products but not protocol specifications. The AI Act's obligations target model providers, not the plumbing that carries their calls. In the specific case of a home device becoming a public command execution endpoint, the legal responsibility chain has no precedent.
This vacuum is the largest structural risk in the entire picture, larger than any individual vulnerability, because it removes the only force that reliably corrects default-value negligence at scale. Enterprises respond to auditors. Consumers respond to insurance. Regulators respond to incidents. Until an incident occurs, nobody is paying for the fix.
A single event involving physical safety โ a lock, a camera, an alarm system under the control of a compromised agent โ would change the regulatory posture within a quarter. The European and American frameworks are already positioned to absorb AI agent runtimes into product compliance obligations once a concrete harm exists to justify the expansion. That event has not happened. The absence of it is not evidence of safety. It is evidence of luck.
The security middleware market will respond before the regulators do. Protocols that are insecure by default reliably generate a layer of security products designed to sit in front of them, in the same way that API gateways and web application firewalls grew up around protocols that never shipped with adequate protection. Configuration source auditing, outbound allowlisting, and sandboxed stdio wrappers are the obvious first products. Managed household MCP services that sell safety through inexperience โ you do not need to understand security because we have already configured it โ are the second. Detection tooling for legitimate-channel abuse, built on anomalous command sequences and configuration changes rather than anomalous processes, is the third and the hardest.
What the Next Two Release Cycles Reveal
The only reliable indicator of Anthropic's actual position is not what its engineers say about protocol-layer sanitization. It is what the SDK defaults, documentation, and example configurations do. Refusing to change the wire format and refusing to change anything at all are different decisions, and the press coverage has blurred them. A protocol that will not filter commands can still prohibit stdio servers from reaching the network by default, require explicit confirmation before spawning, and place the public exposure warning on the first screen of the quickstart.
Whether that happens in the next few versions will tell us more about institutional priorities than any public statement. The visible tension โ a red team warning about AI worms coexisting with SDK defaults that provide the environment those worms would need โ suggests two teams optimizing for different objectives without a formal review process connecting them. That is a testable organizational hypothesis, not a criticism, and it should be verified before it is believed.
The macro view reveals what the micro hides. A single command injection finding looks like a bug to be patched. The same finding viewed across hundreds of thousands of household deployments looks like a structural transfer of risk from organizations that can absorb it to individuals who cannot. Regulation is the new liquidity engine, and right now it is not flowing into this particular corner of the market.
Strategy prevails where sentiment fails. The strategic play here is not to argue about whether the design is defensible, because it is. The play is to recognize that a protocol's safety is determined by the least capable person who deploys it, not by the sophistication of the people who designed it. On that measure, the current default configuration is a bet that households will behave like development teams. Mapping the chaos, one block at a time, the honest conclusion is that this bet has not yet been settled, and the settlement will arrive disguised as an incident nobody scheduled.