Cursor MCPoison Persistent Code Execution via MCP Trust Bypass - CVE-2025-54136

Check Point Research disclosed MCPoison, a persistence flaw in the Cursor AI code editor, tracked as CVE-2025-54136 (CVSS 7.2) and published August 5, 2025. Cursor's one-time approval of an MCP server bound trust to the server's name rather than its contents, so a later change to the underlying configuration was treated as already trusted and ran without a fresh prompt. The flaw affected Cursor 1.2.4 and earlier and was fixed in version 1.3. This advisory covers what was disclosed and how to inventory and govern this class of MCP-trust abuse.

What happened

Check Point Research found that when a developer approved an MCP server in Cursor, the editor recorded that trust against the server's name, not the contents of its definition, and never re-validated the entry afterward. So the command behind a trusted name could change while the stored trust stayed in place. An attacker who could modify a previously approved MCP entry - for example through a shared repository configuration that teammates pull - could silently replace a benign command with a malicious one. The next time Cursor loaded that trusted name, it executed the changed command without asking again, giving the attacker code execution in the developer's context.

Because the recorded trust persisted across edits and sessions, this was a persistence primitive: every developer who had once approved the server name would run the swapped command on the next load, with no new approval. The flaw affected Cursor 1.2.4 and earlier. Check Point Research reported it through responsible disclosure on July 16, 2025, and Cursor's version 1.3 fix, released July 29, 2025, makes any change to an MCP configuration trigger a mandatory approval prompt instead of inheriting prior trust by name. The root cause is the same pattern that keeps recurring in AI coding tools: a trust decision bound to an identifier rather than to the contents it vouches for, a close cousin of the sibling Claude Code project-file RCE and token exfiltration and of the same-week Cursor CurXecute MCP prompt-injection RCE, where MCP configuration executed before review.

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 trust state. The recorded approval defines which MCP servers Cursor will load and run without prompting, and on the affected builds that approval kept vouching for a name even after the command behind it changed. That makes the MCP definition both the target an attacker wants to alter and the mechanism that runs the payload, with the developer's earlier click of trust standing in for a review that never re-happens.

This exposure is hard to see from the controls you already run, because it lives in the AI artifact layer. The swapped command sits inside an MCP entry a developer rarely re-inspects after the first approval; 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, and which carry an approved MCP server whose definition has changed since it was trusted.

How Anomity surfaces and governs it

Upgrading Cursor to 1.3 closes this specific flaw, but the durable control is to treat MCP approval as a governed artifact and re-check the contents behind a trusted name before the command 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 each approved server, so you can find builds before 1.3 and detect when an approved server's definition has changed from the version that was trusted. Metadata only: 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 launched by an MCP entry whose contents changed since approval can be denied at the boundary rather than inheriting stale name-based trust - the control runtime governance provides while a vulnerable build is still rolling forward. That stops the MCPoison chain at its hinge: the moment a silently swapped command tries to ride a prior approval into execution.

Third, keep the record. Every approval, every added, changed, or removed MCP server definition, and every decision lands in a queryable 90-day audit trail, and decisions route to SIEM, Slack, email, or Jira. When a disclosure like CVE-2025-54136 lands, you can answer which endpoints ran the affected Cursor versions, which approved MCP entries were modified after approval and when, and what those 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 or request early access.

What to check across your fleet

• Identify every endpoint running Cursor 1.2.4 or earlier and upgrade to 1.3 or later, where any MCP configuration change forces a fresh approval prompt.
• Inventory approved MCP servers per endpoint and flag any whose definition has changed since the approval was granted, especially recent edits.
• Audit shared repository MCP configurations that teammates pull, since a single edit there can ride an old approval onto every developer who trusted the name.
• Confirm a policy denies tool calls launched by an MCP entry whose contents changed since approval, at the agent hook, not just at patch time.
• Verify MCP approvals and configuration changes are captured in an audit trail and routed to your SIEM, so a post-approval swap is a recorded, reviewable event.
• Treat any approved MCP server whose command was modified after the fact as untrusted until a person re-reviews and re-approves the new contents.

MCPoison is one instance of a recurring pattern: a trust decision attached to an identifier keeps vouching for contents that quietly changed underneath it. Patching Cursor to 1.3 closes this case; governing the artifact layer is what closes the class. For the broader pattern and 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 govern MCP trust across your fleet, request early access.