Incident file · Security
The tool you approved isn't the tool you're running (2025)
MCP tool-definition compromise, CVE-2025-54136 (CVSS 8.8)
The system
MCP (Model Context Protocol) clients, including Cursor, discover available tools by calling tools/list on a connected server. The server's response, a name, a natural-language description, and an input schema per tool, is loaded directly into the model's context as trusted operational metadata. A user typically approves a new MCP server once, the first time it is used.
What was observed
Two related but distinct problems surfaced in 2025. Invariant Labs formally named "Tool Poisoning Attacks" in April, showing a malicious server's tool description, not its execution, could carry hidden instructions followed with the same authority as the user's own request. Separately, Check Point Research disclosed CVE-2025-54136 ("MCPoison," CVSS 8.8) in Cursor in July: a tool a developer had already approved stopped behaving the way it did when it was approved.
Stop and think
- If a tool's description (not its code) can carry an attack, what has to be true about how that description reaches the model, and why would text labeled "metadata" get the same trust as a direct user instruction?
- A developer approved an MCP server's configuration once. What, if anything, re-checks that configuration the next time the same server is used?
- What is the practical difference, from a defender's point of view, between a tool that was malicious from day one and a tool that was clean at approval and changed later?
Answer the questions above before you read on: what failed, why, and what would have stopped it.