Cursor CurXecute MCP Prompt-Injection Remote Code Execution - CVE-2025-54135

AIM Security disclosed CurXecute, a remote code execution flaw in the Cursor AI code editor, tracked as CVE-2025-54135 (CVSS 8.5) and published August 1, 2025. Through indirect prompt injection, an attacker could make Cursor write its own MCP configuration file and run attacker-defined commands before the developer could approve the change. The flaw affected Cursor 1.2.1 and earlier and was fixed in 1.3.9. This advisory covers what was disclosed and how to inventory and govern this class of MCP-configuration abuse.

What happened

AIM Security found that Cursor did not require user approval before creating or modifying a sensitive MCP configuration file. Through indirect prompt injection - for example a crafted Slack message processed by a connected Slack MCP server and read by Cursor - an attacker could make the agent write or modify the global .cursor/mcp.json file. Cursor then executed commands from the modified configuration immediately, before the user could reject the AI-suggested edit, achieving remote code execution in the developer's context. The injected content did not need a privileged user or a phishing click; it only needed to land in a data source the agent already read.

The flaw affected Cursor 1.2.1 and earlier and was fixed in version 1.3.9, which adds an approval step before MCP configuration changes take effect instead of auto-executing them. AIM Security reported the issue through responsible disclosure on July 7, 2025, and it was not exploited as a zero-day, so the window between disclosure and patch availability was controlled. The root cause is the same pattern that keeps recurring in AI coding tools: agent-readable configuration applied and executed ahead of an explicit trust decision, the same shape as the sibling Claude Code project-file RCE and token exfiltration, where repository configuration ran before consent.

Why this is an agentic-endpoint risk

The attack surface here is not a server or a network path - it is the coding agent's own MCP configuration. The .cursor/mcp.json file defines which MCP servers the agent loads and what commands they launch, and on the affected builds a write to that file took effect without review. That makes the MCP definition both the target an injection wants to reach and the mechanism that runs the payload. The exploit fires on an ordinary agentic action: the agent reading data - a Slack message, an issue, a document - and acting on what it read.

This exposure is hard to see from the controls you already run, because it lives in the AI artifact layer. The malicious .cursor/mcp.json entry sits in a file a developer rarely inspects; the Cursor process looks legitimate to EDR; the spawned command runs as the developer; and the network sees ordinary traffic. MCP server definitions are one of the eight AI artifact types Anomity tracks per endpoint, adopted bottom-up the same way AI agents and MCP servers became the new shadow IT. The question is not whether one laptop is patched; it is which endpoints across the fleet run Cursor before 1.3.9, and which carry an .cursor/mcp.json that was written or changed by the agent rather than by a person - and you cannot answer that without an inventory of the artifact layer.

How Anomity surfaces and governs it

Upgrading Cursor to 1.3.9 closes this specific flaw, but the durable control is to treat MCP configuration as a governed artifact and decide what may write or auto-execute it before it runs. Anomity does that in three steps.

First, inventory. Anomity treats MCP server definitions as a first-class inventoried artifact - one of the eight AI artifact types it tracks on every managed endpoint - then classifies them. It captures the Cursor version and the MCP configuration metadata, including the contents and provenance of .cursor/mcp.json, so you can find builds before 1.3.9 and the projects carrying an MCP entry that was recently added or modified. Metadata only: any secrets embedded in a server definition are redacted on the endpoint before anything leaves it.

Second, decide at the hook. On agents that expose a hook - for example, a Cursor or Claude Code PreToolUse event - Anomity evaluates each tool call against your policy and returns allow, deny, or log before the call runs. A tool call that writes or auto-executes MCP configuration without an explicit allow decision can be denied at the boundary, which is the control runtime governance provides while a vulnerable build is still rolling forward across the fleet. That stops the CurXecute chain at exactly its hinge: the moment an injected instruction tries to turn a data read into a write of .cursor/mcp.json.

Third, keep the record. Every decision, and every added, changed, or removed MCP server definition, lands in a queryable 90-day audit trail, and decisions route to SIEM, Slack, email, or Jira. When a disclosure like CVE-2025-54135 lands, you can answer which endpoints ran the affected Cursor versions, which .cursor/mcp.json files were rewritten and when, and what those MCP entries were allowed to do - from a record, not a guess. Anomity complements Network, EDR, DLP, and GRC tooling; it covers the artifact layer those tools were never built to inventory. See how it works.

What to check across your fleet

• Identify every endpoint running Cursor 1.2.1 or earlier and upgrade to 1.3.9 or later, where MCP configuration changes require an approval step.
• Inventory .cursor/mcp.json across endpoints and flag any entry that was written or modified by the agent rather than by a person, especially recent changes.
• Catalog which MCP servers are connected to coding agents - Slack, issue trackers, document stores - since any one of them is a path for indirect prompt injection through untrusted content.
• Confirm a policy denies tool calls that write or auto-execute MCP configuration without an explicit allow decision, at the agent hook, not just at patch time.
• Verify MCP configuration changes are captured in an audit trail and routed to your SIEM, so a rewrite of .cursor/mcp.json is a recorded, reviewable event.
• Treat any unexpected MCP entry that launches a shell command on load as untrusted input until a person has reviewed and approved it.

CurXecute is one instance of a recurring pattern in AI coding agents: untrusted content reaching the agent turns into agent-readable configuration that runs before anyone approves it. Patching Cursor to 1.3.9 closes this case; governing the artifact layer is what closes the class. For the broader pattern and the related disclosures, see the pillar on securing AI coding agents and CLIs, compare Anomity against the tools you already run on the comparison, and when you are ready to inventory and govern MCP configuration across your fleet, request early access.