The MCP flaw that spanned four languages

MCP in one paragraph

Model Context Protocol is the open standard, introduced by Anthropic in late 2024, that lets an AI agent use tools. A tool is a small server that exposes a capability, say "look up this customer" or "create this invoice", along with a plain-English description of what it does. The agent reads the descriptions, picks the tool that fits the task, and calls it. That description is the whole contract. The model does not read the code behind the tool. It reads the label, trusts the label, and acts on it.

What the flaw let an attacker do

MCP servers talk to the agent over one of two transports. STDIO (standard input/output, the plumbing a program uses to talk to another program on the same machine) runs the server as a local process the agent starts; HTTP runs it as a service on the network. OX Security's finding was about STDIO: the official SDKs take the command that starts a server and execute it, and they execute it even when it fails to produce a valid server. As the researchers put it, pass in a malicious command, receive an error, and the command still runs. Where an application lets a user or a config file influence that command, the user can run anything on the host, with the host's privileges.

OX found the same behaviour in the Python, TypeScript, Java and Rust SDKs, counted 150M+ downloads of the affected packages, scanned 7,000+ servers on public IPs with STDIO exposed, and estimated up to 200,000 vulnerable instances across the ecosystem. Their disclosures produced 10 CVEs (the public register entries the industry uses to name a security flaw) rated high or critical. Affected products included LiteLLM, Windsurf and Cursor. Anthropic's position was that STDIO's execution model is a secure default and sanitisation belongs to the developer. A week later the project's security guidance gained a line recommending caution with STDIO adapters.

Five questions before an agent gets a tool

These are the questions we put to our own servers and to any vendor's.

1. What is the least this tool needs, and does it get only that? A tool that reads a customer record should not hold the credential that deletes one. The MCP specification's own guidance calls this scope minimisation: start with low-risk read scopes and elevate only when a privileged action is first attempted. If a vendor's tool arrives with one broad key that does everything, that key is the blast radius.

2. Who can change a tool's description, and would you know? The description is what the agent obeys, so a change to it is a change to what your agent will do. Ask where descriptions live, who has write access, whether they are pinned to a version or a checksum, and whether a changed description forces a fresh approval.

3. Is the server on the network or on a machine? STDIO on a laptop is a different risk from HTTP on a public IP. 7,000+ servers were reachable from the internet with the vulnerable transport exposed. Every MCP server in your estate should be either local and sandboxed (run inside a box that limits what it can touch on the machine), or on the network behind real authentication with the tokens issued to that server and no other. The specification bans passing a token through to a downstream API, and that is the check to ask for by name.

4. What can the agent do without a human? Read is one thing. Send, pay, delete and deploy are another. Decide per tool which actions need a person to confirm, and make sure the confirmation shows the full command or payload rather than a friendly summary. The Cursor proof of concept worked because the human saw a summary.

5. How would you know it went wrong? Every tool call should land in a log you can export, with who asked, which tool, what it was given and what came back. If the only record of an agent's actions is the chat transcript, you have no audit trail and no way to answer a regulator, a client or your own board.

What we check in our own servers

RIVER's published security posture already carried three of these before April: least privilege across all systems, no access expansion without written approval, and audit logging of access and key actions, exportable where required. Our AI governance controls add the other two: what the AI can and cannot do is defined and agreed at the start of each engagement, and outputs are designed for a human to review, with autonomy earned through evidence rather than granted on day one. The OX disclosure sharpened how literally we apply them to a tool description and a transport choice.

What to actually do this week

Inventory every MCP server you run or a vendor runs for you. You cannot ask the five questions of a server you do not know exists. Include the ones on developer laptops.

Put the five questions to each vendor in writing. Least privilege per tool, who can change a description, network or local, what runs without a human, and how you would know. A clear answer on all five is a green light. A vague answer on question two or five is a reason to pause that integration.

Fix the transport and the scope first. Get any internet-reachable STDIO server off the public network, and split any single do-everything key into per-tool scopes. Those two moves close most of the exposure OX Security found.