Two Cursor Flaws, 'CurXecute' and 'MCPoison,' Let Attackers Run Code via Poisoned AI Config
- Date
- Aug 2025
- Tools involved
- Cursor
- Impact
- Two rated CVEs in the Cursor AI editor: CVE-2025-54135 (CurXecute, CVSS 8.6) and CVE-2025-54136 (MCPoison, CVSS 7.2). MCPoison enabled persistent, silent code execution every time a shared project was reopened.
- Root cause
- Cursor auto-wrote and auto-ran MCP configuration files, and did not re-validate an MCP server entry after approval, so prompt injection or a later config swap could execute code without a fresh prompt.
What happened
In early August 2025, researchers disclosed two remote-code-execution vulnerabilities in the Cursor AI code editor. Together they showed how Cursor's support for the Model Context Protocol (MCP), the mechanism that lets the agent connect to external tools, expanded the attack surface for code execution.
CurXecute (CVE-2025-54135, CVSS 8.6), disclosed August 1 by Aim Security, used indirect prompt injection. Malicious content fed to the agent could cause it to write an MCP configuration file to disk and execute it before the user had a chance to approve or reject the change. That gave an attacker code execution on the developer's machine.
MCPoison (CVE-2025-54136, CVSS 7.2), disclosed August 5 by Check Point Research, abused how Cursor validated MCP config. Once a user approved an MCP server entry, an attacker could silently change what that entry actually ran. Because the swap happened after approval, it enabled persistent, silent code execution every time the project was reopened, a real supply-chain risk for any shared repository.
Cursor addressed the issues and added mandatory confirmation for MCP configuration changes in version 1.3, released July 29, 2025. Tenable, Check Point, and Dark Reading covered the pair as evidence that AI-editor conveniences like MCP auto-start can turn prompt injection into remote code execution.
Impact
Two rated CVEs affected Cursor: CVE-2025-54135 (CurXecute, CVSS 8.6) and CVE-2025-54136 (MCPoison, CVSS 7.2). CurXecute could run code before the user approved a config change. MCPoison was arguably worse for teams: after a one-time approval, the underlying command could be swapped, giving persistent, silent code execution every time a shared project was reopened.
Root cause
Both bugs came from how Cursor handled MCP configuration. CurXecute let the agent write and auto-run an MCP config file in response to injected content before the user could intervene. MCPoison trusted an MCP server entry once it was approved and did not re-validate it, so its command could be changed later without prompting again. The fix was to require explicit confirmation whenever MCP configuration changes.
How to not be this entry
- Update Cursor to version 1.3 or later, which requires explicit confirmation for MCP configuration changes.
- Treat any file or web content the agent ingests as untrusted input. Indirect prompt injection is the delivery mechanism here, so review what the agent is about to write to disk before it runs. Read the fix guide: SQL injection and XSS in AI-generated code
- Review MCP server entries in shared repositories the way you review dependencies. A previously approved entry can point somewhere new, so re-check config that arrives through a pull request.
- Do not let the agent auto-execute commands you have not seen. Approval that happened once should not authorize whatever the config runs later. Read the fix guide: Cursor Agent Deleted My Files (Wiped Uncommitted Work)
Tools that actually fix this
Recommended because they address the failure mode above, not because of the payout. Some are affiliate links; see how we choose.
Snyk Code catches injection and XSS right in your editor, and Snyk Open Source flags vulnerable and malicious packages. It covers several AI-code failure modes at once and is free for open source.
Try Snyk →All-in-one appsec (code scanning, dependencies, secret detection, containers) with low-noise output, built for small teams that cannot run five separate tools. One dashboard covers several failure modes.
Try Aikido Security →Frequently asked questions
What are CurXecute and MCPoison in Cursor?
CurXecute (CVE-2025-54135, CVSS 8.6) and MCPoison (CVE-2025-54136, CVSS 7.2) are two remote-code-execution vulnerabilities disclosed in the Cursor AI code editor in early August 2025. Both abused Cursor's handling of Model Context Protocol (MCP) configuration: CurXecute wrote and ran an MCP config file via prompt injection, and MCPoison silently swapped what an already-approved MCP server entry executed.
How did CurXecute achieve code execution?
CurXecute (CVE-2025-54135) used indirect prompt injection. Malicious content fed to the Cursor agent could make it write a Model Context Protocol configuration file to disk and execute it before the user had a chance to approve or reject the change, yielding code execution on the developer's machine.
Why was MCPoison dangerous for teams?
MCPoison (CVE-2025-54136) abused Cursor's MCP config validation: once a user approved an MCP server entry, an attacker could silently change what that entry actually ran. Because the swap happened after approval and did not prompt again, it gave persistent, silent code execution every time the project was reopened, which is a supply-chain risk for any shared repo.
Is there a fix for the Cursor MCP vulnerabilities?
Yes. Cursor added mandatory confirmation for MCP configuration changes in version 1.3, released July 29, 2025. Update to 1.3 or later, and review MCP server entries that arrive through shared repositories or pull requests, since a previously approved entry can be pointed at a new command.
Sources
- Check Point Research: Cursor vulnerability 'MCPoison' (CVE-2025-54136)
- Tenable: FAQ on CVE-2025-54135 and CVE-2025-54136 (CurXecute, MCPoison)
- Cato Networks: CurXecute remote code execution in Cursor
Related error guides
The Vibe Oops briefing
One email when something ships to production that should not have. New incidents, new error guides, no filler.