Cursor CurXecute: Prompt Injection to RCE via mcp.json

What to do

1. Confirm every Cursor install is current (Help > About, or `cursor --version`); remove pinned or offline-installed old builds.
2. Review committed `.cursor/mcp.json` files in shared repos and require code review for changes to them.
3. Keep MCP approval prompts on and avoid broad auto-run settings for agent terminal commands.
4. Be cautious about connecting MCP tools that ingest untrusted content (public Slack channels, issues, web pages) in the same session as powerful local tools.

How to check if you are affected or compromised

• Audit `.cursor/mcp.json` in projects and `~/.cursor/mcp.json` for MCP server entries you didn't add or whose command changed.
• Check git history for commits that modify MCP config files, especially swaps of `command` or `args` after initial approval.
• Look in EDR for shells or network tools spawned by the Cursor process around agent sessions that touched external content.

What happened#

Aim Labs (Aim Security) disclosed "CurXecute," CVE-2025-54135, in the Cursor AI code editor. Cursor's agent could create new files in the workspace without asking the user. Editing an existing dotfile required approval, but creating a new one did not. If .cursor/mcp.json didn't exist yet, an indirect prompt injection could make the agent write one that registered a malicious "MCP server," which is just a command, and Cursor would launch it.

Aim's demo, as reported by The Hacker News, worked like this. The victim has a Slack MCP server connected. The attacker posts a payload in a public Slack channel. When the victim asks Cursor to summarize their Slack messages, the agent reads the payload and writes the rogue config. Aim noted that "even if the edit is rejected, the code execution had already happened."

A related flaw, Check Point Research's "MCPoison" (CVE-2025-54136, CVSS 7.2), attacked Cursor's trust model. Approval was tied to an MCP entry's name, not its command. Anyone with write access to a shared repo could commit a harmless entry, wait for a collaborator to approve it, then swap in a malicious command. That command would run silently every time the project opened, according to Check Point's write-up.

Who is affected#

For CurXecute, the GHSA and CVE record list Cursor below 1.3.9 as affected, with 1.3.9 as the patched version. The Hacker News, SecurityWeek and Aim say the fix landed in Cursor 1.3, released July 29, 2025. The sources also disagree on the score: the CVE record and press say CVSS 8.6, while the GHSA page shows 8.5 with the same vector. For MCPoison, Cursor 1.3 is the fix, and it now requires re-approval whenever an MCP entry changes.

Do you really need to act?#

Probably not today. Both are fixed, Cursor updates itself, and there are public demos but no reports of in-the-wild exploitation. Neither CVE is in CISA KEV. CurXecute needed a connected MCP tool that pulls in attacker-controlled content. MCPoison needed write access to a repository the victim works in, or local file-write access.

What still matters is the pattern. Any agent that can write its own tool configuration, and any IDE that trusts a config by name, turns a prompt injection or a malicious commit into code execution. The same release also fixed a bypassable auto-run denylist (replaced by an allowlist) and README-based injection reported by HiddenLayer, per The Hacker News.

What to do now#

1. Verify Cursor versions across the team (Help > About or cursor --version). Anything frozen on a pre-1.3 build, or pre-1.3.9 if you follow the advisory strictly, should be updated.
2. Treat .cursor/mcp.json as executable code: require review for changes to it (CODEOWNERS works) and be wary of repos from untrusted contributors.
3. Leave approval prompts on, and keep agent terminal auto-run narrow.
4. Avoid mixing tools that ingest untrusted content (public channels, issues, web pages) with powerful local tools in one agent session.

How to tell if you were hit#

No public indicators exist. Audit project and user-level mcp.json files for entries you didn't create, and check git history for commits that changed an existing entry's command or args, the MCPoison pattern. In EDR, look for shells, curl or PowerShell spawned by Cursor during sessions that read external content.

Timeline#

• Jul 7, 2025 — Aim Security reports CurXecute to Cursor (per press reports).
• Jul 16, 2025 — Check Point reports MCPoison to Cursor.
• Jul 29, 2025 — Cursor 1.3 released with fixes.
• Aug 1, 2025 — CurXecute public; GHSA-24mc-g4xr-4395 (CVE-2025-54136) published.
• Aug 2, 2025 — GHSA-4cxx-hrm3-49rm (CVE-2025-54135) published.
• Aug 5, 2025 — Check Point publishes MCPoison research.

Vulnerability records

• CVE-2025-54135 · Cursor is a code editor built for programming with AI.
• CVE-2025-54136 · Cursor is a code editor built for programming with AI.

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. GitHub — GHSA-4cxx-hrm3-49rm: Arbitrary code execution via prompt injection in Cursor Agent github.com
2. GitHub — GHSA-24mc-g4xr-4395: Modification of MCP Server Definitions Bypasses Manual Re-approval github.com
3. CVE Program — CVE-2025-54135 record (JSON) cveawg.mitre.org
4. Check Point Research — Cursor IDE: Persistent Code Execution via MCP Trust Bypass (MCPoison) research.checkpoint.com

Coverage and analysis

1. The Hacker News — Cursor AI Code Editor Fixed Flaw Allowing Attackers to Run Commands via Prompt Injection thehackernews.com
2. SecurityWeek — Several Vulnerabilities Patched in AI Code Editor Cursor securityweek.com