MCPoison: Cursor trusted an MCP server by name, so its contents could change to code execution

What happened

Cursor lets a project define MCP servers, and asks the user to approve one before it runs. Check Point Research disclosed a trust-bypass vulnerability, tracked as CVE-2025-54136 and nicknamed MCPoison, in how that approval persisted.

Once a user approved an MCP server with a project-specific configuration, Cursor treated subsequent changes to that entry as trusted based on the MCP server's name rather than re-verifying its contents. An attacker who could modify the shared project configuration — for example through a repository an engineer collaborates on — could silently swap the approved entry's command for a malicious one. Because the name still matched, no re-approval was prompted, and the malicious command executed each time the project was opened, giving the attacker persistent code execution. The flaw affected Cursor versions 1.2.4 and below and was fixed in version 1.3. It carried a CVSS score in the high range.

Root cause

• LLM03 Supply Chain. Trust was anchored to a name in shared project configuration, so a poisoned config change flowed to every collaborator who had once approved it.
• LLM06 Excessive Agency. The tool re-ran an approved MCP command automatically on project open, with no content re-verification, so a changed definition executed without a human gate.

How it would have been caught

A test that approves an MCP entry, then mutates only its command while keeping the name, and checks whether Cursor re-prompts or silently executes, would have caught the bypass directly. The distinction from a superficial pass matters: the tool did not crash and the approved name still resolved, so a check that only verifies "the server loaded" reports green while the swapped command runs. File-integrity monitoring on mcp.json and a policy that any content change to an approved server voids the prior approval are the load-bearing checks.

How to prevent it

• Bind approval to the full content (a hash) of an MCP server definition, not to its name — any content change must force re-approval.
• Treat project-supplied MCP configuration as untrusted supply-chain input, reviewed like any other executable dependency.
• Log and surface every configuration change so a silent swap cannot execute unnoticed.

The Breachwire test (red → green)

Approve a benign MCP entry, then silently change its command while keeping the name, reopen the project, and confirm the malicious command executes without re-approval (the RED control proving persistent RCE). Apply content-hash-bound approval, then confirm the changed entry is blocked pending re-approval, while a legitimately re-approved change still runs (the positive control).