The main Cursor security risks are code that runs when a repository is opened, MCP servers that can change after you approve them, hidden instructions in rules files, Run Modes that let the agent act without review, and code leaving for model providers when Privacy Mode is off. Each has a documented case behind it, from the CurXecute and MCPoison vulnerabilities in 2025 to research showing folders that run code on open. Cursor has fixed the vulnerabilities and publishes enterprise controls for the rest, but several of those controls are off until someone turns them on.
Opening a folder can run code: Workspace Trust
Cursor is built on VS Code, which has a feature called Workspace Trust that opens unknown folders in a restricted mode. Oasis Security reported in September 2025 that Cursor ships with Workspace Trust disabled by default. A repository with a .vscode/tasks.json file set to run on folderOpen can therefore execute code as soon as a developer opens it, with no prompt. That code runs as the user and can read secrets, change files or send data out.
Cursor's response was that users can enable Workspace Trust. Its enterprise hardening guide now recommends enforcing it through device management, with the caveat that restricted mode limits AI features, so it suits genuinely untrusted code. Oasis also suggests turning task.allowAutomaticTasks off and opening unknown repositories in a disposable container or virtual machine.
MCP servers and the CurXecute and MCPoison vulnerabilities
Cursor reads MCP servers from ~/.cursor/mcp.json for every project and .cursor/mcp.json inside a repository. Two 2025 vulnerabilities, summarized by Tenable, showed how those files could be turned against the user.
CVE-2025-54135, which Aim Security named CurXecute and which is rated 8.5, let a prompt injection delivered through an MCP server such as Slack rewrite the global mcp.json. The new command ran immediately, before the user could reject the agent's suggested edit. It was fixed in Cursor 1.3.9. CVE-2025-54136, which Check Point Research named MCPoison and which is rated 7.2, came from Cursor trusting an approved server by its name rather than its contents. An attacker with access to a shared repository could later change that server's command in the project mcp.json, and it would run without a new approval. It was fixed in Cursor 1.3. Tenable reports that neither was exploited before disclosure.
Both flaws were fixed in 2025 releases, so the first check on any Cursor install is its version.
MCPoison is a rug pull: a server that passes review and changes afterward. Our write-up of every malicious MCP server reported so far shows the same pattern outside Cursor.
Rules files can carry hidden instructions
Cursor rules files tell the agent how to write code for a project, and they are usually committed to the repository. In March 2025, Pillar Security showed that attackers could hide instructions in these files using invisible Unicode characters, such as zero-width joiners and bidirectional text markers. A reviewer sees a normal rules file. The model reads extra instructions telling it to add vulnerable code or a backdoor. The research covered both Cursor and GitHub Copilot, and both vendors responded that users are responsible for reviewing what the tools generate.
The practical defense is to treat rules files as code: review them in pull requests, and use a diff tool or linter that shows hidden Unicode. Rules files copied from public collections deserve the same check, because a file shared widely spreads a hidden instruction to every project that adopts it.
How to check a repository before opening it in Cursor
Until Workspace Trust is enforced, the safest assumption is that opening a folder can run code. For a repository you did not write, look at four files before you open it in Cursor: .vscode/tasks.json for any task set to run on folderOpen; .cursor/mcp.json for server commands, especially npx lines with no version and anything that pipes to a shell; rules files under .cursor/rules or a .cursorrules file, viewed in a tool that shows hidden characters; and .vscode/settings.json for settings that change how the editor behaves.
Reading these from a terminal or the repository's web page takes a few minutes and does not execute anything. If something looks wrong, open the project in a disposable container or virtual machine instead of on your laptop, as Oasis Security recommends.
Run Modes decide what happens without approval
By default, Cursor asks before using an MCP tool and shows its arguments. Run Modes change that, and MCP tools follow the same Run Mode as terminal commands. Allowlist runs the actions on your allowlist without approval and can sandbox supported shell commands. Auto-review runs allowlisted calls immediately, sandboxes shell commands when it can, and sends everything else to a classifier. Run Everything runs every tool call with no sandbox and no classifier; Cursor's own documentation warns that you accept the full risk of every call the agent makes.
The risk in a permissive Run Mode is not one bad command. It is that every other risk on this page becomes automatic. A prompt injection in a web page, a poisoned rules file or a changed MCP server needs the agent to take an action, and Run Everything removes the moment where a person could say no.
Cursor's hardening guide recommends setting the organization's Run Mode policy to Auto-review rather than Run Everything, and notes that Auto-review is best effort, so it should be paired with hooks.
Privacy Mode and where your code goes
To answer questions, Cursor sends code and prompts to model providers. Cursor's data use page explains the two settings. With Privacy Mode on, Cursor does not train on customer data and has zero data retention agreements with its providers. Files are still cached temporarily on Cursor's servers, encrypted with client-generated keys, and prompts that trigger abuse detection may be kept for investigation. With Privacy Mode off, Cursor may store and use codebase data, prompts and snippets to improve its features and train models. The hardening guide recommends enforcing Privacy Mode org-wide, and says it is on by default for Enterprise.
Privacy Mode governs Cursor and the model providers it routes to. It does not cover MCP servers. A server that sends data to its own backend, such as a hosted search or documentation service, handles that data under its own terms, so each server needs its own review.
How to reduce Cursor security risks across a team
Cursor's enterprise hardening guide sets out the controls in one place. Enforce Privacy Mode for the whole organization so members cannot switch it off. Enforce Workspace Trust through device management. Approve MCP servers through the MCP Allowlist in Team Settings, which can approve local servers by command pattern and remote servers by URL pattern, limit which tools run automatically, and give each local server a network mode of allow all, allowlist, deny all or no sandbox. Set the Run Mode policy to Auto-review. Allowlist extension publishers. Enable sandboxing.
Two gaps remain. The MCP Allowlist approves configurations but does not tell you which servers developers already run, and these controls apply only to Enterprise teams that turn them on. An inventory of what is installed today, and a per-server review using the MCP security checklist, fills both.
The same questions apply to other agents; our write-up of Windsurf security concerns covers its auto-run modes, and our guide to vibe coding security risks covers what happens when generated code ships unread.
Next step: find the Cursor security risks already in your org
Cursor security risks depend on which machines run it, with which settings and which MCP servers. Find out before you write policy. Run a Discovery Scan to list every Cursor install and every server in its config files, with a risk score for each.