Is Cursor AI Safe? A Security Review for Engineering Leaders

Cursor is safe enough for most engineering organizations to deploy, on three conditions: you run version 3.0 or later, you enforce Privacy Mode centrally rather than per developer, and you keep the list of connected MCP servers short and owned. Three critical vulnerabilities were published against Cursor in 2026 and all three are patched. The risk that remains after patching is not really about the editor at all. It is about what the agent can reach using the credentials already sitting on a developer's laptop.

That is the short version. The rest of this explains why the answer is not "yes" or "no," what the published vulnerabilities actually did, and which of the many settings are worth arguing about.

What are the Cursor AI security concerns?

Four, and they are not equally serious. In rough order of how often they cause real problems:

1. Prompt injection reaching the agent through content it reads while working. Not a developer typing something reckless. A poisoned repository file, a web search result, or text returned by a connected tool. This is the root cause of every published critical Cursor CVE so far.
2. Third-party MCP servers. Cursor does not vet them, says so plainly, and leaves the trust decision to whoever pasted the config.
3. Credentials on the machine. The agent has a terminal. The terminal can read the environment file with the production database URL in it. No editor setting changes that.
4. Approval fatigue. Cursor asks before running terminal commands by default. Humans approve reflexively after about a day, and Cursor offers Run Modes so trusted calls can skip the prompt entirely.

Notice that only the first two are Cursor's to fix, and the third is usually the one that turns an incident into an outage.

What is the DuneSlide vulnerability?

DuneSlide is the name Cato AI Labs gave to a pair of critical Cursor vulnerabilities, CVE-2026-50548 and CVE-2026-50549, both scored CVSS 9.8. Both let prompt injection escape Cursor's sandbox and execute code on the underlying operating system with the developer's privileges. Neither required a click. As the researchers put it, "There is no click to fall for and no approval box to ignore."

The mechanics are worth understanding because the pattern generalizes. Cursor runs agent terminal commands inside a sandbox that allows writes to the command's working directory. In the first flaw, the agent could change which directory that was, so the sandbox happily granted write access to a path outside the workspace. NVD describes the outcome as writing "arbitrary files outside the workspace under the user's privileges," and the specific trick was overwriting the sandbox helper binary itself so that every later command ran unsandboxed. The second flaw reached the same place through symlink resolution: when Cursor's check that a link pointed inside the project failed for an incidental reason, it fell back to trusting the link's stated path.

A third, earlier issue is worth knowing about too. CVE-2026-26268, published in February 2026 and fixed in Cursor 2.5, let an agent write to git configuration including hooks. NVD notes that "No user interaction was required as Git executes these commands automatically." It was scored 9.9 by NIST and 8.0 by the vendor coordinating the CVE, a gap that reflects a genuine disagreement about required privileges rather than anyone being wrong.

All three are fixed. The disclosure timeline for DuneSlide is also a reasonable snapshot of how young this field is: Cato reported the pair on February 19, 2026, Cursor initially declined them on February 23 because the threat model did not cover MCP misuse, Cato escalated on February 26, and the fixes shipped in Cursor 3.0 on April 2. Reasonable people disagreed for a week about whether hostile text returned by a connected tool counts as attacker-controlled input. It does, and everyone now agrees, which is progress.

Is Cursor AI safe to use with MCP servers?

It is as safe as the servers you connect, and Cursor is honest that this is your problem. Its documentation says to "Only install MCP servers from trusted developers and repositories," to check what data and APIs a server will access, and to review the source of anything critical. The line that matters most: "Remember that MCP servers can access external services and execute code on your behalf."

Cursor is not unusual here. Anthropic states that it "does not security-audit or manage any MCP server" either. The whole ecosystem works this way, which means MCP server vetting is a program you run, not a feature you buy.

The approval model is the counterweight, and on paper it is genuinely strong: every MCP connection needs approval, and each tool call needs individual approval before running. Two things erode it in practice. Teams relax approvals for convenience, which is exactly what Run Modes are for. And approval happens at the wrong moment. Invariant Labs demonstrated this against Cursor back in April 2025 with a tool poisoning attack, where malicious instructions hide inside a tool description that the user never reads but the model treats as authoritative. Their proof of concept exfiltrated the developer's own MCP config file and their private SSH key. Reviewing a server's source code does not help when the payload lives in the description string it serves at runtime, and can change after you approve it.

The team-scale answer is to stop asking individuals to make this call. Turn on Cursor's enterprise MCP allowlist, keep it short, and give each entry a named owner who can explain what the server does. If you run more than a handful, route them through one control point so servers are allowlisted centrally and tool definitions are pinned by hash. We go through that architecture on MCP gateway, and the underlying attack class on MCP server security.

Is Cursor AI safe for company code?

For the training-data question, which is what most legal teams actually ask: Cursor offers Privacy Mode to all users and states that when it is enabled, "we will not train on your data. We also implement technical controls and contractual requirements with our model providers to protect your data." A SOC 2 Type II attestation report is available on request through its trust center. Request it and read the exceptions rather than the cover page.

The mistake is stopping there. Teams spend six weeks on the training question and no time on the fact that the same laptop holds a long-lived production token that the agent's terminal can read and use. An assistant that cannot train on your code but can call your internal API with a staff engineer's credentials is not contained in any way that matters.

There is one more Cursor recommendation worth quoting because it lands directly on a common workflow: "For untrusted repos, use a basic text editor instead." If your developers review external pull requests, audit vendor code, or open customer-supplied repositories, that advice is aimed at you. A repository someone else wrote is attacker-controlled input, and every DuneSlide-class bug is what happens when attacker-controlled input meets an agent with a shell.

Is Cursor safer than other AI coding tools?

Roughly comparable, and the CVE count is a bad way to judge it. Three published critical vulnerabilities means Cursor is being seriously researched, reported to, and patched, which is what you want. A tool with no published CVEs is more likely under-examined than hardened.

The third row is the one that generalizes to every tool in this category, including whatever your team adopts next. A human approval step is not a control when there is no human, so anything running a coding agent unattended in CI needs its policy somewhere other than the agent. The Anthropic-specific version of this is on Claude agent security.

It is also worth noticing how far past the IDE this has gone. The same trust question now applies to agents that open pull requests on their own, agents that run in your pipeline, and tools that will generate an entire site end to end from a description. The editor was simply the first place most companies noticed.

How to make Cursor safe for your team

Five things, in order. The first three are free.

• Enforce a version floor of Cursor 3.0 or later, and verify it from an inventory rather than a policy document. This closes all three published sandbox escapes, and an unpatched install is the entire remaining exposure.
• Enforce Privacy Mode as an administrator setting, so it survives new hires, reinstalls and personal machines.
• Enable the MCP allowlist and keep it short. Servers that touch production deserve a higher bar than servers that read docs.
• Get long-lived production credentials off developer machines. Short-lived, narrowly scoped tokens issued at the point of use turn a stolen credential into a session that expires. This is the single highest-value change on the list and it has nothing to do with Cursor.
• Log agent tool calls somewhere the laptop cannot edit, so that when someone asks what an agent touched between Tuesday and Thursday, the answer exists. Local history is not evidence.

Blanket bans generally fail, for the same reason they fail with every popular developer tool: the work moves to an unmanaged machine where you can enforce nothing and see nothing. Decide by device and by repository instead. Managed laptop, enforced version, enforced settings, short allowlist, no untrusted repositories opened in it.

The honest bottom line

Is Cursor AI safe? Safe enough, patched, and more transparent about its limits than most tools in this category. The three critical CVEs are all fixed, and the vendor documentation tells you plainly which risks it is handing back to you rather than pretending they do not exist. That is a better security posture than a marketing page claiming everything is handled.

What should worry you is the part no editor setting reaches. An agent with a terminal, a developer's credentials and a network route to production is a powerful thing, and prompt injection remains unsolved as a detection problem. The durable answer is containment rather than filtering: give agent traffic its own scoped identity, make egress default-deny, gate irreversible actions on a human, and keep an append-only record off the machine. Those controls keep working on the day a fourth sandbox escape is published, which there will be.

The full breakdown of Cursor's controls, what its documentation actually commits to, and the risks a policy layer does not fix is on our Cursor AI security page. For the wider program across every coding agent your teams run, see coding agent security, and for how the same pattern played out at infrastructure scale, the Hugging Face security incident is the clearest case study available.