The vendor has published a fix. Version details are below where the sources state them.
Steps
Written by AI from the record
Check your installed Cursor version; if it is 1.2.4 or below, you are affected.
If you work from shared Git repositories that include previously approved MCP server definitions, identify whether any collaborators (or anyone with repo write access) could modify those files.
Update Cursor to version 1.3 or later.
After updating, review your MCP server approvals (especially in shared repos) and remove/disable any unexpected MCP entries.
Cursor is a code editor built for programming with AI. In versions 1.2.4 and below, attackers can achieve remote and persistent code execution by modifying an already trusted MCP configuration file inside a shared GitHub repository or editing the file locally on the target's machine. Once a collaborator accepts a harmless MCP, the attacker can silently swap it for a malicious command (e.g., calc.exe) without triggering any warning or re-prompt. If an attacker has write permissions on a user's active branches of a source repository that contains existing MCP servers the user has previously approved, or allows an attacker has arbitrary file-write locally, the attacker can achieve arbitrary code execution. This is fixed in version 1.3.
In plain language
Written by AI from the record
CVE-2025-54136 lets an attacker slip in a malicious MCP server definition without triggering Cursor’s usual re-approval, which can lead to code running on your machine; if you use Cursor with MCP servers in shared repositories you collaborate on, you should update to Cursor 1.3.
In Cursor (1.2.4 and below), attackers with repo write access (or arbitrary local file-write) can modify already-approved MCP server definitions in a way that bypasses manual re-approvals, leading to remote and persistent code execution.
If you're affected
Full workstation compromise
Persistent malicious access
Operational disruption
Client/customer data exposure
What is it
Cursor can connect to extra “service” definitions called MCP servers. Normally, when something changes, Cursor asks you to re-approve it. This bug allows a bad change to be swapped in without that re-approval, so harmful code can run on your computer.
Who is affected
This matters to you if you run Cursor (1.2.4 and below) and you use MCP servers that have already been approved, especially when those approvals live in files inside shared source repositories you collaborate on. An attacker still needs write access to the target’s active repository branches (or the ability to edit the relevant files on your machine) for the bypass to work. If neither repo write access nor local file-write is possible, exposure is much less likely.
How urgent is it
This is an AMBER issue because it can enable remote and persistent code execution and Cursor versions are directly impacted. Even though there’s no clear dated public “already exploited widely” report in the findings, there is a public proof-of-concept and the issue has been resurfacing with a vendor patch.
What to do — in detail
Confirm the Cursor version
On the affected machine, open Cursor and check the version number in the app’s About/Settings area.
If the version is 1.2.4 or below, treat the machine as affected.
Confirm MCP usage patterns
Identify whether you use MCP servers in Cursor and whether any MCP server definitions have already been approved by users.
Pay special attention if those MCP definitions are stored/managed through shared Git repositories (e.g., configs committed in repos) that multiple people can edit.
Identify whether an attacker could modify those definitions
Determine who has write access to the relevant repositories/branches you actively work on.
If your workflow includes third parties, contractors, or broad “write” permissions, this is the key risk check.
If there is any possibility of arbitrary local file-write (malware, other vulnerabilities, or scripts writing to those files), also consider the machine at risk.
Upgrade to the fixed version
Upgrade Cursor to version 1.3 or later.
The vendor fix is documented under GHSA-24mc-g4xr-4395 and is available via the Cursor downloads page.
Post-upgrade review (prevents lingering risk from swapped approvals)
Re-check your MCP server definitions/approvals in Cursor.
Remove or disable any unexpected MCP entries.
If your repo is shared, consider tightening permissions (limit write access) and review recent changes to the MCP-related configuration files.
Temporary containment if you can’t upgrade immediately
Reduce the chance of malicious modification by restricting write access to repos/branches that contain MCP server definitions.
Avoid using Cursor MCP approvals from untrusted/shared branches while you wait for the upgrade.
What to monitor
After upgrading, monitor for unexpected MCP server changes in your repos (new commits touching MCP config/definition files) and for any unusual Cursor behavior related to MCP services.
Technical context
Severity/impact: The findings indicate remote and persistent code execution in Cursor (1.2.4 and below) through modification of MCP server definitions that were previously approved. Weakness type: CWE-78 (bypass of security mechanisms).
Mechanism: An attacker modifies an already trusted MCP configuration file so Cursor does not trigger manual re-approval, allowing the attacker to swap a harmless MCP server definition for a malicious command.
Attack vector and prerequisites: Network-based for the repo scenario; attackers need write access to a victim’s active branches of a source repository that contains existing MCP servers the victim has previously approved, or they need arbitrary file-write locally.
Exploit status: Public proof-of-concept exists (1 known). KEV listing was not found in the provided findings, and there’s no clear dated real-world exploitation claim in the provided press findings. The vendor has fixed the issue in Cursor 1.3.
KEV meaning: Since this CVE is not listed in CISA KEV (per the findings), the findings treat exploitation status as not confirmed by KEV at this time.
This is a general assessment based on public vulnerability data. It does not account for your specific infrastructure — when in doubt, consult a security specialist.
