By: Andrey Charikov, Roman Zaikin & Oded Vanunu
Background
Cursor is a developer-focused AI IDE that combines local code editing with large language model (LLM) integrations. Due to its flexibility and deep LLM integration, Cursor is increasingly adopted by startups, research teams, and individual developers looking to integrate AI tooling directly into their development workflow. Like many AI development platforms, one of its features is Model Context Protocol (MCP) — plugin-like configurations that allow the IDE to define and execute workflows that may involve remote APIs, LLM-generated commands, or local command execution.
Research Motivation
As AI-powered developer tools become integrated into daily workflows, they increasingly rely on automation, local execution of model outputs, and collaborative project sharing. Cursor’s support for workspace-linked configuration files and custom plugin behavior presents a unique attack surface — particularly in multi-user environments where files may be synchronized through shared Git repositories.
We set out to evaluate whether the trust and validation model for MCP execution in Cursor properly accounted for changes over time, especially in cases where a previously approved configuration is later modified. In collaborative development scenarios, such changes are common — and any gaps in validation could lead to command injection, code execution, or persistent compromise.
Our goal was to determine whether a single approval action could be abused to enable long-term exploitation without additional user interaction or warnings.
Our Research Findings
We observed that every time a project is opened in Cursor, the IDE scans for the .cursor / directory and automatically processes any MCP-related files inside it. This behavior ensures seamless execution of trusted tools — but also introduces a significant opportunity for abuse in collaborative environments.
Cursor uses a one-time approval model for MCPs: the first time a user encounters an MCP configuration, they are prompted to approve it. However, we discovered that once an MCP is approved, future modifications to its command or arguments are trusted without any additional validation or prompt.
This means that an attacker can:
- Commit a benign
.cursor/rules/mcp.jsonfile with a harmless command (e.g., echo) - Wait for the victim to approve it
- Later change the same MCP entry to execute arbitrary system commands (e.g., cmd.exe, reverse shell)
- And have the modified command executed silently on the victim’s machine — both during repository sync and every time Cursor is reopened
In our proof-of-concept, we demonstrated persistent remote code execution by:
- Getting initial approval for a non-malicious MCP
- Replacing the MCP command with a reverse shell payload
- Gaining access to the victim’s machine every time they opened the project
The vulnerability stems from Cursor binding trust to the MCP key name (e.g., “my plugin”), without verifying whether the underlying command or arguments have changed. This effectively turns a trusted file into a persistent, auto-triggered backdoor.
Technical Deep Dive of Cursor’s MCP Configuration
Cursor allows users to define project-specific tooling using MCP configuration files stored under:
.cursor/rules/mcp.json
Each MCP is structured as a JSON object containing an mcpServers dictionary. Each entry defines a MCP name, a command to execute locally, and an optional list of args. For example:
When a project is opened, Cursor automatically scans the .cursor/ directory and processes any MCP-related configurations it finds. If an MCP has not been previously approved, the user is prompted to allow execution. Once approved, the configuration is trusted for future runs.
However, this trust is bound only to the name (“test1” in the example above). The contents — such as command and args — can be modified later without triggering a new approval prompt.
This means an attacker can perform the following steps:
1. Initial harmless commit:
2. Victim opens the project in Cursor, sees the approval prompt, and accepts.
3. Updated malicious payload after approval:
4. The victim syncs the repository or reopens Cursor. The new (malicious) command is executed silently — no prompt is shown.
We extended this by deploying a reverse shell payload:
Where shell.bat contains reverse shell to attacker.
Each time the victim opens Cursor, the MCP is re-evaluated and the reverse shell is triggered again — making the payload persistent and triggers without any user action.
Real World Consequences
This vulnerability enables persistent, silent, and remote code execution in any Cursor-based development environment. Once an MCP is approved, the attacker can repeatedly inject malicious commands without user awareness.
An attacker with write access to a shared repository can:
- 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 (especially dangerous on developer machines with cloud credentials or source code access)
- Persist indefinitely, as the malicious MCP is re-executed on every project launch or repository sync
This vulnerability breaks Cursor’s security boundary between initial approval and ongoing trust. The approval model assumes that once a MCP configuration is accepted, its future behavior remains trustworthy — yet the command itself can be silently swapped at any time.
In team settings, this makes the .cursor/rules/mcp.json file an ideal vector for stealthy backdoor deployment, especially in internal toolchains or sensitive environments. Without proper validation, such trust-based workflows can be turned into reliable remote execution pipelines with minimal effort — and zero user interaction beyond the first approval.
Responsible disclosure time line:
- Check Point Research responsibly disclosed the issue to the Cursor development team on July 16, 2025.
- Cursor issued an update (version 1.3) on July 29, 2025
- While the release notes did not specifically mention the vulnerability, our independent testing confirms that the issue has been effectively addressed. Now, any change to an MCP configuration—including something as small as adding a space—triggers a mandatory approval prompt. The user must explicitly approve or reject the modified MCP before it can take effect.
To ensure protection against this vulnerability, we strongly recommend updating to the latest version of Cursor.
This disclosure marks the first in a series of vulnerabilities identified by Check Point Research in AI platforms designed for developers. As AI-assisted coding tools and LLM-integrated environments continue to shape modern software workflows, CPR will publish further findings that highlight overlooked risks and help raise the security bar across this emerging ecosystem.
