The Trust That Never Expires

Cursor is an AI-powered code editor that has rapidly gained adoption among developers, startups, and research teams. Built on top of VS Code's foundation, it integrates large language model capabilities directly into the editing experience - code completion, natural-language refactoring, chat-based debugging. One of its extension points is the Model Context Protocol (MCP), which allows the IDE to load plugin-like configurations that define workflows involving remote APIs, LLM commands, or local command execution. MCP configurations live in project files, which means they can be committed to Git repositories and shared among collaborators.

On August 1, 2025, Check Point Research disclosed CVE-2025-54136, a vulnerability they named "MCPoison." The flaw was in how Cursor handled trust for MCP configurations: once a developer approved an MCP config file, Cursor remembered that approval permanently. If the config file was later modified - even to replace a harmless command with a reverse shell or arbitrary code execution payload - Cursor would execute the modified configuration without asking the developer to re-approve it. No warning. No prompt. No indication that anything had changed.

The vulnerability affected Cursor versions 1.2.4 and below and carried a CVSS score ranging from 7.2 to 8.8 (High), depending on the scoring methodology applied.

How the Attack Worked

Check Point's research laid out a four-step attack chain that was disturbingly simple to execute.

Step 1: An attacker contributes a benign MCP configuration file (.cursor/mcp.json or .cursor/rules/mcp.json) to a shared repository. The configuration does something harmless - maybe it echoes a string or runs a basic utility. In a popular open-source project or a team's internal repository, this kind of tooling configuration file would look normal.

Step 2: A developer clones the repository and opens it in Cursor. The IDE detects the MCP configuration and prompts the user to approve it. The developer reads the config, sees it's harmless, and clicks approve.

Step 3: The attacker later updates the MCP configuration file. Instead of echoing a string, it now points to a malicious server with remote code execution capabilities, or it directly executes system commands - launching a reverse shell, exfiltrating files, installing backdoors.

Step 4: The developer opens the repository in Cursor again (or syncs changes). Cursor loads the MCP configuration without re-prompting, because the approval from Step 2 is still cached. The malicious commands execute silently with the full permissions of the developer's user account.

The attack persisted across sessions. Every time the victim opened the repository in Cursor, the malicious MCP would execute again. The attacker had, in effect, installed a persistent backdoor that activated whenever the developer did the most routine thing a developer does: opened their code editor.

The Trust Model Failure

The technical root cause was a design decision about trust persistence. Cursor's approval model assumed that once an MCP configuration was accepted, its future behavior would remain consistent with what was approved. The system cached the approval decision but did not track the content that was approved. When the content changed, the cached approval still applied.

This is a common pattern in security design and a common source of vulnerabilities. The principle is called TOCTOU - Time of Check, Time of Use. The check (user approval) happens at one point in time. The use (execution) happens at a later point. If the thing being used can change between the check and the use, the check becomes meaningless.

In Cursor's case, the window between check and use wasn't a race condition measured in milliseconds. It could be days, weeks, or months - however long the attacker waited between committing the benign config and swapping in the malicious one. The longer the gap, the less likely the developer would remember approving the MCP config in the first place, and the less likely they would notice a silent update to a dotfile buried in their project directory.

The Supply Chain Angle

What made MCPoison particularly dangerous was its natural fit into software supply chain attacks. Modern development is built on shared repositories. Developers clone open-source projects, fork internal tools, and work in team repositories where multiple people have commit access. MCP configuration files live alongside the code in these repositories.

An attacker who gained write access to a popular repository - through a compromised maintainer account, a malicious pull request that slipped through review, or legitimate contributor access to a shared project - could plant a benign MCP config, wait for developers to approve it, and then weaponize it at will. The attack surface scaled with the number of developers who cloned the repository and opened it in Cursor.

For internal enterprise repositories, the implications were sharper. Developer machines typically have access to cloud credentials, deployment keys, source code for the organization's products, and internal network resources. A persistent RCE on a developer's machine, activated every time they opened their project, provided a foothold that most lateral movement playbooks would envy.

Check Point's analysis noted that an attacker could "achieve ongoing remote access by embedding a reverse shell into an MCP configuration, execute arbitrary local commands silently every time the victim opens Cursor, escalate privileges within the user context, and persist indefinitely as the malicious MCP is re-executed on every project launch or repository sync."

Disclosure and Fix

Check Point Research disclosed the vulnerability to Cursor's development team on July 16, 2025. Cursor issued an update (version 1.3) on July 29, 2025 - a 13-day turnaround from disclosure to fix. The release notes did not specifically mention the vulnerability, but Check Point independently confirmed that the fix was effective.

The fix was straightforward: any change to an MCP configuration, no matter how small (Check Point noted that even adding a single space triggered it), now requires a mandatory re-approval prompt. The user has to explicitly approve or reject the modified configuration before Cursor will execute it. This addressed the TOCTOU gap by ensuring that the cached approval was invalidated whenever the approved content changed.

The CVE was also tracked under GitHub Security Advisory GHSA-24mc-g4xr-4395.

MCPoison Wasn't Alone

CVE-2025-54136 was not the only vulnerability Check Point found in Cursor. The same research effort also identified CVE-2025-54135, dubbed "CurXecute," which was a separate code execution flaw in how Cursor handled MCP servers. Tenable published an analysis covering both vulnerabilities, and SecurityWeek reported that "several vulnerabilities" were patched in the AI code editor.

Check Point stated that the MCPoison disclosure "marks the first in a series of vulnerabilities identified by Check Point Research in AI platforms designed for developers." The firm indicated that it planned to publish additional findings from its research into AI-assisted coding tools and LLM-integrated environments.

The Broader Pattern

MCPoison fits into a pattern that security researchers had been documenting throughout 2025 and into 2026: AI development tools introduce new trust boundaries that traditional security models don't account for. An IDE that can execute arbitrary commands based on configuration files in a repository creates a different threat surface than an IDE that just edits text. The MCP protocol specifically was designed to give AI tools the ability to take actions in the real world - calling APIs, running commands, reading files. That capability is the feature, and the attack surface is directly proportional to it.

The fix - re-prompting on any config change - is the right answer for this specific vulnerability. But the design question it exposed remains: how should AI development tools handle trust for configurations that can execute code? A single approval prompt, even one that re-triggers on modification, still relies on the developer reading and understanding what the configuration will do. If the malicious configuration is sufficiently obfuscated, or if the developer is in the habit of clicking through approval prompts the way most people click through cookie banners, the re-approval mechanism provides a speed bump rather than a barrier.

For developers using Cursor or similar AI-enhanced editors, the practical takeaway from MCPoison was to treat MCP configuration files in shared repositories with the same scrutiny as any other executable code. Review them in pull requests. Pin MCP server versions. Use config file integrity monitoring. And update to Cursor v1.3 or later, where the one-time approval loophole no longer exists.