Code Execution in the Cursor AI Editor via MCP
Two different roads to the same place: attacker-controlled MCP data, or a quietly edited config, and the AI editor runs their code.
| When | August 2025 |
|---|---|
| Target | Cursor AI code editor |
| Researchers | Aim Labs (CurXecute) · Check Point (MCPoison) |
| Technique | MCP prompt injection → config write; approval-persistence TOCTOU |
| CVE | CVE-2025-54135 (CVSS 8.5) · CVE-2025-54136 (CVSS 7.2), per Cursor's advisories |
- 1CurXecute: untrusted MCP data prompt-injects the agent into writing a .cursor/mcp.json entry
- 2MCPoison: an already-approved MCP config is edited later and runs without re-prompting
- 3Cursor executes the attacker's command at the developer's privilege
What happened
In mid-2025, two disclosures showed the Cursor AI code editor could be driven to remote code execution through the Model Context Protocol. Aim Labs' CurXecute (CVE-2025-54135, CVSS 8.5) and Check Point's MCPoison (CVE-2025-54136, CVSS 7.2) reached the same outcome by different routes; MCPoison was fixed in Cursor 1.3 and CurXecute in 1.3.9.
How the attacks worked
CurXecute: untrusted data from an MCP source (e.g. a Slack message the agent ingests) prompt-injects Cursor into writing a new entry in .cursor/mcp.json, which the editor auto-executes — injection to code execution. MCPoison: once a user approves an MCP server config, Cursor did not re-check it when the command or arguments were later edited, so an attacker with repo write access could swap an approved benign entry for a malicious command that ran silently on every project reopen.
Root cause
Model-influenced or previously-approved configuration was treated as trusted-to-execute. Untrusted MCP data could write auto-run config, and approval was not bound to the exact command it approved.
Why it matters
A coding agent runs on the developer's machine with their privileges. Turning injection or a config swap into execution there exposes source code, credentials and the whole workstation.
How to prevent it
- Re-prompt on any change to an approved tool or command (bind approval to content).
- Never let untrusted MCP data write executable config.
- Sandbox agent command execution and least-privilege the editor.
FAQ
Are these the same bug?
No. CurXecute is a prompt-injection→config-write→auto-exec chain from untrusted MCP data. MCPoison is a trust/integrity flaw: approval of an MCP config isn't re-checked when the config is later edited, so an attacker with repo write access swaps in a malicious command.
Why is a coding agent such a dangerous target?
It runs on a developer's machine with their privileges and, in agent mode, executes commands. Turning indirect injection or a config swap into RCE there means source code, credentials and the whole workstation are exposed.
How do you defend?
Re-prompt on any change to an approved tool/command, treat MCP data as untrusted input (never as instructions that can write executable config), and sandbox agent command execution.
Sources
- CurXecute: Remote Code Execution in Cursor via MCP (CVE-2025-54135) — Aim Labs / Cato Networks
- CVE-2025-54136 – MCPoison Cursor IDE: Persistent Code Execution via MCP Trust Bypass — Check Point Research
- Arbitrary code execution from Cursor Agent through a prompt injection via MCP Special Files (GHSA-4cxx-hrm3-49rm) — Cursor / GitHub Security Advisory
- Modification of MCP Server Definitions Bypasses Manual Re-approval (GHSA-24mc-g4xr-4395) — Cursor / GitHub Security Advisory