In this post
Anthropic’s official SDKs for the Model Context Protocol will run whatever shell command they receive. No sanitization, no confirmation step. When OX Security flagged this as a systemic command injection problem, Anthropic’s answer was that the behavior is intended.
That answer matters to you if your dev shop has wired MCP servers into your product, your internal tools, or your developers’ machines. The count from OX’s earlier advisory: roughly 200,000 vulnerable server instances, over 7,000 reachable on public IPs, across an ecosystem with 150 million SDK downloads.
This week’s “Welcome to the Jungle” report adds the weirdest detail. Of 15,465 publicly indexed MCP servers across five registries, about 0.45% run on personal or home machines, often exposed through consumer tunneling services like ngrok. Someone’s side project is sitting on the open internet, waiting.
What the flaw actually is #
MCP’s STDIO transport is the default way an AI agent connects to a local tool. The configuration includes a command parameter, and the SDK executes whatever that parameter says, verbatim.
OX’s researchers turned that into more than 30 disclosures and over 10 CVEs rated high or critical, hitting LiteLLM, LangFlow, Flowise, Windsurf, and Agent Zero among others. The mcp-remote npm package, the OAuth proxy many MCP clients use, carried CVE-2025-6514, a remote code execution scored 9.6 out of 10. Windsurf’s variant needed zero clicks from the user.
The registries failed too. OX submitted a harmless proof-of-concept server to 11 MCP registries, and nine accepted it with no security review. “We installed it from the registry” is not a safety answer.
“By design” is a real position. It still doesn’t help you. #
Anthropic’s counterargument is technically coherent: sanitizing STDIO would either break the transport or push the same payload one layer down. The MCP project’s own security policy treats executing the configured command as expected behavior, full stop.
The real boundary is who gets to write that configuration. If only your local admin can define the command, the SDK is doing what you asked. Trouble starts when a GitHub issue, a README, or a web page can modify the MCP config your agent reads - then server registration becomes remote code execution, and OX demonstrated exactly that path against production platforms with paying customers.
Merritt Baer, a former deputy CISO at AWS, put the pattern plainly: “MCP is shipping with the same mistake we’ve seen in every major protocol rollout: insecure defaults.” Both sides are right about the mechanism. Only one side has to clean up after it.
Why this lands on founders as much as security teams #
MCP is how Claude Code, Cursor, and most agent setups talk to your database, your file system, and your deploy pipeline. If your agency installed MCP servers to speed up development, you now have a list of questions for them, whether or not they ever mentioned the protocol by name.
The questions are short:
- Which MCP servers are installed, on which machines, and who approved each one?
- Can any of them be reconfigured by content the agent reads - a repo file, an issue, a web page?
- Did any server come from a registry listing rather than the original publisher’s own package?
- What credentials does each server hold, and are they hard-coded in a config file?
That last one is not hypothetical. Separate research found 53% of MCP servers expose credentials through hard-coded config values, which is the same sloppy pattern we find in dev shop audits all the time.
What to actually do about it #
Start with an inventory. The Cloud Security Alliance’s MCP maturity model makes a complete server list - name, version, location, owner - the entry-level requirement, before any fancier control. Most teams we talk to can’t produce one today.
Then cut the supply chain risk. Semgrep’s writeup of the first malicious MCP server on npm showed the attack was avoidable by using the genuine package from the original developer instead of a reposted copy. Pin your servers to official sources, and treat registry listings as untrusted until someone on your team has read the code.
Patch the known CVEs in your stack, but know what a patch buys you. Every product-level fix OX catalogued closes one entry point in one product; none changes the STDIO default, so the next server you add inherits the same behavior.
If an agent on your team can reach production through one of these servers, the guardrails from our PocketOS post-mortem apply unchanged: read-mostly keys, human approval for anything destructive, backups the agent can’t reach.
We build agent tooling ourselves and write about debugging LLM agents in Rails from first-hand experience. MCP is useful. It is also a shell with a JSON interface, and your setup should treat it like one.
Want an audit of how your agents are wired? See how we work
Related reading #
- 9 Seconds: An AI Agent Wiped a Live SaaS - what happens when an agent holds production keys
- Devtools for AI Agents - the tooling layer MCP plugs into
- Debugging RubyLLM Agents in Rails - how we run agents on client work
Sources #
- Yahoo Tech: Your Home MCP Server Is Probably Unsecured (2026-10-19)
- VentureBeat: 200,000 MCP servers expose a command execution flaw (2026-05-01)
- Cloud Security Alliance: Agentic MCP Security Best Practices (2026-05-20)
- Six Hack Academy: MCP Security - The New Weak Link in AI Agents (2026-10-07)
- Semgrep: The first malicious MCP server on npm (2025-10-02)
