When Cursor IDE users updated to version 1.3 in late July 2025, many did not know they were patching a vulnerability that had existed since the day MCP servers became a feature. MCPoison (CVE-2025-54136), discovered by Check Point Research, and CurXecute (CVE-2025-54135), discovered by AIM Security, both exploited the same architectural gap in how AI agents handle Model Context Protocol servers. Neither vulnerability required a malicious user input, a compromised system, or sophisticated social engineering. Both required only that the agent trusted what an MCP server told it about its own tools.
Tool poisoning through MCP is distinct from ordinary prompt injection in a way that matters for defense: the attack surface is not user input but configuration metadata, and it runs before any user ever asks the agent anything. Understanding why requires understanding what happens when an AI agent connects to an MCP server at boot.
The tools/list Protocol Step: Where the Attack Lives
When an AI agent starts up and connects to an MCP server, the agent issues a tools/list JSON-RPC call. The server responds with an array of tool descriptors. Each descriptor contains three things: a name, a natural-language description of what the tool does and when to use it, and a JSON Schema defining the tool’s input parameters. The agent merges these descriptors with tool descriptors from every other connected server and serializes the full combined list into the model’s context window. This happens before the first user message is processed.
The description field in each tool descriptor is where tool poisoning lives. This field is a natural-language string that the model reads as instructions about the tool. There is no sanitization of this field. There is no provenance check verifying that the description contains only legitimate tool documentation. The model processes the description with the same trust it extends to system prompt contents, because from the model’s perspective, tool descriptions arrived via a privileged channel: the agent’s own configuration infrastructure, not a user-supplied input.
An attacker who controls an MCP server can write arbitrary instructions into the description field of any tool that server exposes. Those instructions are loaded into the model’s context at boot, with higher implicit trust than a document the model retrieves at runtime, and with no visible indication to the user that anything unusual has happened. The agent’s tool panel shows a normal tool name and normal-looking description text. The injected instructions may be hidden using Unicode zero-width characters, embedded in sections of the description that display as ellipsis in the IDE, or appended after enough legitimate description content that a casual review would not reach them.
MCPoison: The Team-Wide Persistent Backdoor
MCPoison (CVE-2025-54136) demonstrated one of the most concerning properties of tool poisoning: persistence across an entire development team without any per-user approval bypass. The attack works as follows. An attacker contributes a legitimate-looking MCP configuration to a shared repository. Team members review the configuration, see normal-looking server definitions and tool descriptions, and approve it. The configuration is merged. Every team member who opens the project now loads the MCP server from the shared configuration.
The attacker then modifies the MCP server’s tool descriptions after the initial approval. The modification adds injected instructions to the description fields of tools the agent uses regularly. Because the configuration was already approved and the MCP server was already trusted, no new approval prompt is triggered. Every team member’s agent now loads the poisoned descriptions at boot, silently, the next time they open the project.
The specific attack chain demonstrated by Check Point Research used this mechanism to execute backdoor commands with developer privileges every time any team member opened the project. Over 100,000 active Cursor users were in scope for this vulnerability at the time of disclosure. Cursor patched MCPoison in version 1.3.
CurXecute: Social Media to Remote Code Execution
CurXecute (CVE-2025-54135), carrying a CVSS score of 8.5, demonstrated a different attack chain with a more dramatic entry point. AIM Security researchers showed that an attacker could publish a malicious Slack message in a public channel. When a developer used Cursor’s agent to summarize Slack activity, the agent processed the message content as part of a tool call result. The malicious message contained injected instructions directing the agent to write to the .cursor/mcp.json configuration file.
In Cursor versions below 1.3.9, if the .cursor/mcp.json file does not already exist in the workspace, creating it does not require user approval. The agent created the file, which pointed to an attacker-controlled MCP server. The next time the agent loaded, it connected to the malicious server, loaded poisoned tool descriptors, and executed attacker-specified commands with the developer’s full system privileges. The complete chain from a public Slack message to remote code execution on a developer’s machine required no interaction from the developer beyond the initial Summarize Slack activity request. Cursor patched this in version 1.3.9.
Why Tool Descriptions Are More Dangerous Than Tool Responses
Both MCPoison and CurXecute ultimately exploit the model’s trust in content that arrives through a privileged channel. But tool description poisoning specifically is more dangerous than tool response injection for three structural reasons.
First, timing. Tool descriptions are loaded at boot, before any user request. This means the injected instructions have been in the model’s context from the start of every session. They establish themselves before the model has processed any grounding instructions from the user, which makes them harder for the model to identify as suspicious: they predate the conversation they are influencing.
Second, provenance. Tool descriptions are treated by the agent infrastructure as configuration, not content. When a model processes a retrieved document, there is at least a conceptual frame: this arrived from the external world, it is data. When a model processes tool descriptions, the frame is: this arrived from the agent’s own configuration system. Injected instructions in tool descriptions are processed with the same implicit trust the model extends to the system prompt.
Third, persistence. A poisoned tool response affects only the session where that tool was called. A poisoned tool description affects every session that loads that server, for as long as the poisoned description remains in the server’s response. The rug pull pattern exploits this: a server owner can modify descriptions after initial approval, converting a trusted server into an attacker-controlled one for all future sessions without any re-approval event occurring.
The TrueFoundry analysis of CVE-2025-54136 captured the asymmetry precisely: standard prompt injection has a known attack surface (every place a user-supplied string enters the prompt) and a known set of mitigations. Tool poisoning has a surface that most security reviews never consider, because the channel looks like configuration rather than data. JSON Schema fields. Tool descriptions. Structured metadata fetched at boot. None of those things look like instructions until you remember that the model reads them as instructions.
The MCP Inspector Vulnerability
A third CVE published in the same period exposed a different layer of MCP infrastructure. CVE-2025-49596 affected MCP Inspector versions below 0.14.1. MCP Inspector is the developer tool for testing and debugging MCP servers. The vulnerability was a lack of authentication between the Inspector client and the proxy server component: unauthenticated requests from any origin could issue MCP commands over the stdio connection. A developer running MCP Inspector during development exposed a local endpoint that any process or web page on their machine could use to invoke arbitrary MCP commands without authentication. Fixed in version 0.14.1.
The MCP Inspector vulnerability is categorically different from tool poisoning, but it illustrates the same pattern: MCP infrastructure components are shipping faster than their security surfaces are being evaluated. The Inspector is a development and debugging tool that was not designed with the assumption that an attacker could be co-resident on the developer’s machine or could make cross-origin requests to the Inspector proxy. Both of those are realistic assumptions in a development environment, particularly one where the developer browses the web or runs untrusted code.
Public MCP Server Statistics
Research from PromptHub analyzed public MCP servers in 2025 and found that 43% allow command injection through insufficient input validation, 30% will fetch any URL passed to them (creating server-side request forgery exposure), and 22% leaked files outside their intended directory boundaries. The MintMCP analysis found similar patterns, with over 33% allowing unrestricted network access.
These figures describe the public server ecosystem as it existed when MCP adoption was accelerating. They are not surprising given the development trajectory: MCP server authors are typically focused on capability rather than security, the protocol specification does not mandate input validation, and there is no equivalent of a web application firewall sitting in front of MCP tool calls. The 43% command injection figure is particularly significant: a command injection vulnerability in an MCP server means that an attacker who can influence tool call parameters can execute arbitrary commands on the MCP server host, which often has privileged access to the systems the MCP server was built to connect to.
The Supabase Incident: Real-World Exploitation
Before the CVE disclosures, a production incident at Supabase provided early evidence of what MCP-mediated prompt injection looks like in practice. Supabase’s Cursor agent was running with service-role access, a privileged credential level that bypasses row-level security policies and can read and write any data in the database. The agent was processing support tickets, which included user-supplied text.
Attackers embedded SQL instructions within support ticket content. The agent, treating the ticket content as a tool call result to process, executed the embedded instructions using its service-role credentials. The result was that sensitive integration tokens were read from the database and exfiltrated to a public support thread, visible to anyone with access to the thread.
The Supabase incident combined three factors that appear repeatedly in MCP incidents: privileged access (service-role credentials), untrusted input (user-submitted support tickets), and an external communication channel (the public support thread that received the exfiltrated data). The same architecture that made the agent capable of efficiently processing support tickets also made it capable of processing the adversarial instructions embedded within them. Capability and exploitability came from the same source: the agent’s tool access and the absence of any distinction between trusted and untrusted content in its context window.
The Rug Pull Pattern
One attack pattern specific to MCP tool poisoning has no equivalent in traditional prompt injection: the rug pull. In a rug pull, a malicious MCP server operator publishes a legitimate, useful server with accurate and benign tool descriptions. Developers evaluate it, find it useful, approve it, and integrate it into their workflows. The server accumulates users and trust.
The operator then modifies the tool descriptions to include injected instructions. Users who approved the server weeks or months earlier see no approval prompt for the modification. Their agents load the updated descriptions at boot, process the injected instructions as trusted configuration, and execute whatever the operator specified. The operator has converted a trusted server into an attack delivery mechanism for every user who approved it, with no re-approval event and no visible change in the agent’s tool panel.
The rug pull is the MCP-specific version of a supply chain attack. It is harder to detect than a compromised package because the delivery mechanism is a natural-language description field that looks unchanged to casual inspection, and because the approval model for MCP servers does not include version-pinning or description change notifications. An approved server can be modified indefinitely without triggering any re-evaluation by the client.
Defense Architecture
The structural fix for tool poisoning is a gateway that sits between the agent and all external MCP servers. The gateway intercepts the tools/list response before it reaches the agent, applies policy-based filtering and sanitization to description fields, strips or flags content that matches injection patterns, enforces description length limits, and logs all tool descriptor content for audit. This does not eliminate injection risk. A sophisticated attacker will find ways to encode instructions within policy-compliant description content, but this approach eliminates the class of naive attacks where injected instructions appear in plain text in description fields.
Version pinning for MCP server configurations closes the rug pull attack surface. An agent should connect to a specific commit hash or signed version of an MCP server configuration, and any modification to that configuration should trigger a re-approval event. This is equivalent to lockfile-based dependency management in traditional software development: approved at a specific version, re-evaluated when the version changes.
Scoped credentials eliminate the blast radius amplification that makes tool poisoning dangerous in practice. As covered in the analysis of LLM excessive agency, an agent that operates with service-role database credentials or broad filesystem access converts a successful injection into a high-consequence incident. An agent that operates with read-only credentials scoped to specific tables converts the same injection into a low-consequence one. The tool poisoning attack does not change. The damage it can cause changes by an order of magnitude based on the permissions the agent carries.
The OWASP LLM Top 10 maps this to two intersecting vulnerability classes: LLM01 (Prompt Injection) and LLM03 (Supply Chain). Tool poisoning sits at the intersection because the attack uses injection mechanics delivered through a supply chain channel. Teams that have staffed one concern and not the other have a gap exactly where the attack lands.
What This Means Beyond Cursor
The CVE disclosures involved Cursor because Cursor has the largest user base among MCP-enabled AI IDEs, making it the highest-value target for coordinated disclosure. The underlying vulnerability class is not Cursor-specific. Any application that loads MCP tool descriptors and passes them to a model without sanitization is vulnerable to tool poisoning. Any MCP client that does not pin server configurations is vulnerable to rug pull attacks. Any agent that processes tool call results as trusted context is vulnerable to response injection.
MCP adoption has accelerated faster than the security tooling around it. The protocol specification itself acknowledges the risk: the MCP specification states that there “SHOULD always be a human in the loop with the ability to deny tool invocations.” That normative SHOULD is not a MUST, and most production MCP deployments do not implement it for routine tool calls. The gap between what the specification recommends and what production deployments implement is where all three CVEs and the Supabase incident operated.
For developers building with MCP, the immediate action items are: update Cursor to 1.3.9 or later, update MCP Inspector to 0.14.1 or later, audit MCP server tool descriptions before approving them, avoid service-role or admin credentials for any agent that processes external content, and treat any modification to an approved MCP server configuration as requiring re-evaluation. For teams evaluating MCP server security, the PromptHub statistics provide a baseline: approaching half of public MCP servers have command injection vulnerabilities detectable through basic static analysis. The threshold for trusting a public MCP server should be higher than it is for most teams today.
The broader attack surface of indirect prompt injection provides the architectural context for why tool poisoning works: the model has no privilege system, all tokens receive the same attention, and content that arrives through a trusted channel receives the same processing as content the attacker injects. Tool descriptions arrive through what looks like the most trusted channel in the agent’s architecture. That is precisely why they are the most dangerous injection vector.