Field Notes
Tools as Attack Surface: 2026's MCP Vulnerability Cascade and 'Tool Poisoning'
From three CVEs in Anthropic's own Git MCP to a STDIO design flaw that exposed 7,000 servers — MCP turned "connecting external tools" into a new supply-chain battlefield. How much can fibon's trust tiering and tool-hash verification stop?
Quick summary: In the first half of 2026, vulnerabilities in MCP (the protocol that lets AI connect to external tools through a unified interface) cascaded — three CVEs in Anthropic’s own Git MCP, a STDIO design flaw affecting 7,000+ servers, a CVSS 9.8 command injection in gemini-mcp-tool, RCE and key exfiltration via Claude Code project files. The common theme: “tool poisoning” and “over-privileged credentials + untrusted input.” The note ends by testing fibon’s trusted/untrusted MCP tiering and tool-hash verification.
Skip this if: your AI tool connects to no external MCP servers.
When “connecting tools” becomes the attack surface
MCP (Model Context Protocol), launched in late 2024, lets AI connect to external tools in a unified way — like giving AI a standardized plug. It solved a real problem and was adopted widely. But in the first half of 2026, that plug became a battlefield. AuthZed’s timeline counts over 40 MCP-related CVEs disclosed in January–April 2026 alone. A few representative ones:
Three CVEs in Anthropic’s own Git MCP (disclosed 2026-01-20). Fittingly, the trouble was in the official reference implementation mcp-server-git — the one developers are expected to copy directly. The most severe of the three, CVE-2025-68143 (CVSS 8.8), let the git_init tool accept arbitrary paths and turn any directory on the system into a git repo; CVE-2025-68145 (the --repository flag-not-validated one you may have heard of) let subsequent tool calls access any repository on the server. Chained together, with the Filesystem MCP added, they form a full RCE chain. The trigger vector is prompt injection — a malicious README, a poisoned issue description is enough; the attacker never needs to touch your system directly.
A STDIO design flaw affecting 7,000+ servers (disclosed 2026-04-20). This one is more fundamental — not a bug in some code, but an architectural decision built into the official MCP SDK across all languages. The STDIO transport turns “configuration” directly into “command execution,” with no input sanitization. OX Security’s analysis produced 10 high/critical CVEs affecting 150M+ downloads, including a zero-click attack: when processing attacker-controlled HTML content, malicious instructions can rewrite the local MCP config, auto-register a malicious STDIO server, and then execute arbitrary commands with no user interaction. Anthropic’s position is that this behavior is “expected,” declining to change the protocol architecture.
A command-injection zero-day in gemini-mcp-tool (CVE-2026-0755, CVSS 9.8, disclosed 2026-01-09). This is an unofficial open-source tool whose execAsync splices user input straight into a system command handed to the shell. Penligent’s analysis has a line worth carving into a wall: the PoC succeeded via direct curl but failed in the Claude Desktop interface — because the client-side safety filter acts like a WAF. But their conclusion: “the client’s polite refusal is not a defense.” The attacker just bypasses the UI and sends a raw JSON-RPC frame to the exposed port.
The recurring breach: over-privilege + untrusted input
Lay these CVEs out and AuthZed distills the most recurring breach pattern: over-privileged credentials combined with untrusted tool/context input. One over-privileged token, plus a piece of untrusted content in the LLM context (manipulated by prompt injection), turns a legitimate MCP tool call into the attacker’s ATM.
Another AI-native vector is tool poisoning: hide malicious instructions in a tool’s description/metadata, and the agent treats it as ground-truth for “what this tool does.” Traditional security tools don’t monitor whether a “tool description” has been quietly changed — a supply-chain surface unique to the MCP era. The academic conclusion (arXiv:2603.22489, threat-modeling MCP with STRIDE/DREAD) is that tool poisoning is the most prevalent and highest-impact client-side vulnerability.
What this means for fibon
MCP is one of fibon’s load-bearing pillars — between its three services, and to external tools, everything runs over MCP and gRPC. So this string of vulnerabilities isn’t a spectator sport for fibon; it’s directly relevant. fibon’s design on this line maps onto several of them:
Trusted/untrusted MCP tiering + Worker isolation network. fibon doesn’t treat all MCP equally. Untrusted external MCP is relayed by the Worker, which runs in an isolated Docker network (fibon-isolated-net) whose design goal is written plainly: even if compromised, it cannot reach the Gateway’s API keys or the database (Chapter 6). Those STDIO command-injection and reverse-shell payloads above, even if triggered inside fibon, land in an isolated container that can’t touch the keys or the DB — the exact inverse of the “over-privilege” breach: least privilege by default, untrusted by default. Browser capability also moved to a standalone playwright-mcp sidecar in 2026-05 (ADR-019), the same isolation logic.
The defense against tool poisoning — description hashing. This one lands right on tool poisoning: fibon’s tool registry hashes each tool’s description (description_hash) to detect tampering — if a tool’s description gets quietly altered, the hash mismatch catches it. This is the exact opposite of AuthZed’s “traditional tools don’t monitor description changes”; fibon makes it a field that gets verified. Additionally, Brain runs Pydantic schema validation plus sanitization on all tool output returned from the Worker/MCP, trusting nothing the tools hand back.
The idea to take away from this MCP cascade is the same as the ClawHub note: every external tool an AI agent connects to is a chunk of “trusted instructions” that will execute with the agent’s identity. Whether it’s called a skill or an MCP server, the essence is “you authorized something someone else wrote to act with your privileges.” Penligent’s “the client’s refusal is not a defense” is the key to this whole topic — security can’t bank on the LLM interface blocking things for you; it must be built on the server side you control, drawing the blast radius small with least privilege and isolation. fibon has built the isolation and the hash verification on this line, and still owes the content review for MCP tool descriptions — flagged here, to be done.
Sources
- A Timeline of MCP Security Breaches — AuthZed (updated 2026-05-30)
- Anthropic MCP Design Vulnerability Enables RCE — The Hacker News (2026-04-20)
- MCP Threat Modeling: Prompt Injection with Tool Poisoning — arXiv:2603.22489 (2026-03-23)
- RCE and API Token Exfiltration Through Claude Code Project Files — Check Point Research (2026-02-25)
- Deep Analysis of gemini-mcp-tool Command Injection (CVE-2026-0755) — Penligent (2026-02-07)
- Three Flaws in Anthropic MCP Git Server — The Hacker News (2026-01-20)