Cursor Security: The 2026 Enterprise Hardening Guide

TL;DR

• Cursor shipped 11+ CVEs and named vulnerabilities in the 2025–2026 window: CVE-2026-26268 (sandbox escape via .git config, CVSS 9.9 Critical, patched 2.5), CurXecute / CVE-2025-54135 (CVSS 8.6, indirect prompt injection writes .cursor/mcp.json), MCPoison / CVE-2025-54136 (CVSS 7.2, MCP approve-once bound to key name), CVE-2025-64106 (CVSS 8.8, MCP installer spoofing), CVE-2025-64110 (CVSS 8.7, .cursorignore bypass), CVE-2025-59944 (case-sensitivity bypass), CVE-2025-52882 (CVSS 8.8, WebSocket origin), the OpenVSX namespace-squatting class, the open-folder autorun issue, TrustFall (no CVE, unpatched), and the 94 unpatched Chromium CVEs (OX Security) riding along in Cursor's release lag.
• Architecturally the CVEs cluster into four patterns — pre-trust execution / TOFU bypass, indirect prompt injection → file write → RCE, sandbox escape via privileged side-channel, and supply chain (OpenVSX + Chromium lag).
• Anysphere's enterprise security posture is structurally good — SOC 2 Type II, Privacy Mode default for teams, SSO/SCIM 2.0, model blocklists, MDM deployment. The gap is AI-activity audit logging: tenant admin actions are logged, but "no detailed audit log of AI activities" — your security team cannot reconstruct which prompts ran or which files an agent read from Cursor's logs alone.
• The single highest-leverage hardening move is pinning to Cursor 2.5 or later via MDM. That closes CVE-2026-26268, all 2025 MCP CVEs, and the .cursorignore / case-sensitivity classes in one push.
• TrustFall is the active unpatched issue as of May 2026 — Cursor CLI had not issued a public response at the time of the May 7 disclosure. Block project-local MCP servers via managed config until that changes.

Cursor crossed one million daily active developers in 2025 and has continued to grow through 2026. Its security record has grown alongside the user base — and that record is now substantial enough that "is Cursor safe?" is no longer the right question. The right question is: what does it take to deploy Cursor safely in an enterprise environment? This guide answers that, grounded in every documented Cursor CVE and named vulnerability through May 2026.

The argument runs three ways: (1) what the CVE record actually says; (2) the four architectural patterns that produced it; (3) the eight-move hardening checklist that closes the known surface — pinned to specific CVE IDs, not generic platitudes.

The 2025–2026 Cursor CVE register#

What follows is the complete public record of Cursor security disclosures from June 2025 through May 2026. Each entry includes CVE, CVSS, the affected version range, the patched version, and the technical mechanism. This is the table to keep in your vendor file.

Eleven entries. Seven CVEs. Two named-but-uncatalogued issues. Two class-level disclosures (Chromium lag, OpenVSX). One unpatched issue at the time of writing (TrustFall).

The four architectural patterns#

The CVE list looks like a parade of individual bugs. The patterns underneath it are not.

Pattern 1 — Pre-trust execution / TOFU bypass. Open-folder autorun, TrustFall, MCPoison, OpenVSX squatting. All of these exploit the same Trust-On-First-Use model: Cursor asks once whether you trust a folder or extension, and once approved, the trust persists indefinitely against a target that the user does not control. MCPoison was the canonical demonstration that "approve once" should bind to the content being approved, not the name of the entry. TrustFall is the same lesson, restated, at the project-scoped MCP layer.

Pattern 2 — Indirect prompt injection → file write → RCE. CurXecute, CVE-2025-59944, CVE-2025-64110, and CVE-2026-26268 fit this pattern. The shape: untrusted content (from a repository, a Slack channel via MCP, an issue thread) flows into the agent's context window, the agent writes a security-critical file (.cursor/mcp.json, .git/config, .cursorignore), and the execution boundary is crossed by what the file does after the write. The fix in each case has been to harden the specific file path against the specific attack. The root cause — agents being able to write to security-critical paths at all — is still live.

Pattern 3 — Sandbox escape via privileged side-channel. CVE-2026-26268 is the canonical example. The sandbox enumerated some FS locations but missed .git/. Anything that the sandbox is allowed to write that something else will later execute is a sandbox-escape candidate. Git hooks are the cleanest example; future variants are likely to find other "second-step" execution surfaces (shell completion files, IDE task definitions, pre-commit hooks).

Pattern 4 — Supply chain. OpenVSX namespace squatting, the Chromium lag (94 CVEs piggybacking on slow upstream cadence), and the MCP-installer spoof (CVE-2025-64106). These are the issues where the bug is not in Cursor but in Cursor's vendor chain — Anysphere has the same dependency surface as VS Code without all of Microsoft's upstream-tracking machinery, and that gap shows up regularly enough to be a pattern.

The reason the patterns matter is that each individual patch closes the specific vulnerability, not the architectural shape that produced it. A team that wants to deploy Cursor safely should track the patterns, not just the CVE list.

Anysphere's published security posture — what you actually get from the vendor#

Anysphere has built out the platform-level security controls that an enterprise buyer needs. The summary, pulled verbatim from cursor.com/security and Anysphere's trust portal at trust.cursor.com:

• Privacy Mode with Zero Data Retention (ZDR) terms with model providers. Code is not stored by providers or used for training. Default-on for team members.
• SOC 2 Type II — available on request via trust.cursor.com. Annual third-party penetration tests with executive summaries also on the trust portal.
• Geo: Cursor "does not use or maintain any infrastructure in China" and avoids Chinese-headquartered vendors.
• SSO via SAML / OIDC — Okta, Entra, Google Workspace.
• SCIM 2.0 for user provisioning (Enterprise + SSO only).
• Audit logging for tenant admin actions.
• MDM deployment support.
• Model blocklists — "will not send requests to models on a blocklist."
• CMEK (customer-managed encryption keys) and domain allowlisting for corporate proxies.
• Vulnerability disclosure: security-reports@cursor.com, acknowledgement SLA of 5 business days. No public bug bounty program — confirmed via forum threads from January and May 2025; an HN thread similarly notes the absence.
• Cursor Security Review (beta, April 30, 2026) — a PR-time "Security Reviewer" agent plus a scheduled "Vulnerability Scanner" on Teams/Enterprise tiers.

The honest caveat is the audit-log gap. Several enterprise sources note that Cursor's audit log does not include AI-activity telemetry — you get tenant admin actions, not detailed records of which prompts ran, which files an agent read, or which MCP tools were invoked. This is the gap that turns a future Cursor-side incident into an unprovable one for the customer. Closing it is on Anysphere's roadmap, not in shipping product.

What to do this week if your org runs Cursor#

Eight moves, ranked by leverage. None of these require Anysphere to ship anything new. All of them are deployable today.

1. Pin to Cursor 2.5 or later via MDM. This single move closes CVE-2026-26268 (sandbox escape, CVSS 9.9), all the 2025 MCP CVEs (CurXecute, MCPoison, CVE-2025-64106), the .cursorignore bypass (CVE-2025-64110), and the case-sensitivity bypass (CVE-2025-59944). Force-update via MDM rather than relying on auto-update — your fleet should be on a known version.

2. Force Workspace Trust on, fleet-wide. Counters the open-folder autorun class and the OpenVSX recommended-extensions trap. This is a one-line policy push and it removes an entire pre-trust execution category.

3. Disallow project-local MCP servers via managed config — or auto-deny on any change to .cursor/mcp.json. This is the single highest-impact mitigation. It closes CurXecute, MCPoison, TrustFall, and CVE-2025-64106 in one move. If your team needs MCP servers, deploy them through a centrally-managed allowlist, not via project-scoped files.

4. Lock extension installs. Allowlist OpenVSX publishers; block any unpinned recommended extensions. Koi's placeholder-claim approach to namespace squatting is mitigation, not a fix. Your team should not be one community-maintained registry away from supply-chain compromise.

5. Enforce Privacy Mode org-wide and enable the model blocklist for any third-party model your security team hasn't risk-reviewed. Privacy Mode is the default for teams, but verify via the trust portal that the policy bundle is applied. Block third-party models you do not have a data processing agreement with.

6. Pull the SOC 2 Type II + latest pentest executive summary from trust.cursor.com for the vendor file. Needed for any enterprise security review anyway; also a useful artifact when explaining the deployment to your audit team.

7. Do not run Cursor agents in CI with high-scope tokens. This is the Comment and Control and TrustFall lesson applied to Cursor. Any agent that reads PR/issue text and holds a GITHUB_TOKEN with write scope is one crafted title or one malicious .mcp.json away from a supply-chain incident. Scope tokens to the minimum each step needs; separate triage agents from build agents.

8. Set update-cadence telemetry. Alert when Cursor's bundled Chromium falls more than 30 days behind upstream. The OX Security finding shows this is recurring, not a one-off, and the lag is visible from the version string. Build the alert once, watch it for free.

What's structurally still vulnerable#

This part is informed speculation, flagged as such. Listing it because security planning that ignores adjacent unknowns ages badly.

MCP marketplace / "skills" surface. Cursor's MCP catalog is community-curated. Same trust topology as OpenVSX recommended extensions. A namespace-squat or typosquat advisory in this layer is a 6–12 month forward look. (This is exactly the category SkillCheck was built to scan.)

Background-agent / cloud Cursor environment escape. Cursor's May 2026 changelog notes that egress and secrets are "scoped at the environment level" — the use of the present tense suggests this is a recent change. Older background-agent jobs almost certainly shared a wider blast radius. A retrospective advisory is plausible.

Cursor Security Reviewer self-injection. A PR-time security reviewer agent reading diffs is itself a Comment-and-Control target. A malicious commit message could attempt to instruct the reviewer to approve the PR or exfiltrate secrets. Anysphere will need to publish an isolation model for this layer.

.cursorrules and agent rule files. Same TOFU class as .cursor/mcp.json. CVE-2025-59944's case-sensitivity fix was scoped narrowly; expect siblings.

Audit-log gap as the unprovable-incident risk. Not a CVE, but the most consequential structural issue. If something goes wrong with a Cursor deployment, the platform's logs will not tell you what happened. Plan for endpoint-level observability (eBPF, audit subsystems, agent-process monitoring) to fill the gap.

Frequently asked questions#

Is Cursor safe to deploy in an enterprise environment?

Cursor is deployable in an enterprise environment with hardening, not by default. The Anysphere security posture (Privacy Mode, SOC 2 Type II, SSO/SAML/SCIM 2.0, MDM deployment, model blocklists) provides the platform-level controls. But the agent's runtime has shipped 11+ CVEs in the 2025–2026 window — including CVE-2026-26268 (CVSS 9.9), CurXecute, MCPoison, CVE-2025-64110, CVE-2025-64106, the OpenVSX namespace-squatting class, and the unpatched TrustFall trust-dialog issue — that require version pinning, MCP governance, and credential scoping to mitigate.

What is the most critical Cursor CVE in 2026?

CVE-2026-26268, published February 13, 2026 and fixed in Cursor 2.5, scored CVSS 9.9 Critical at NVD. The mechanism is sandbox escape via .git configuration writes: a sandboxed agent could write to improperly protected .git settings, including git hooks, which then executed out-of-sandbox on the next git operation.

What is MCPoison and how does it affect Cursor?

MCPoison (CVE-2025-54136, CVSS 7.2 High) is a Cursor MCP trust-model bug surfaced by Check Point Research in July 2025 and patched in Cursor 1.3. The mechanism: Cursor's MCP approve-once trust was bound to the key name of the server entry, not the command body. An attacker could ship a benign-looking MCP entry, get the user to approve it, then swap the command for a malicious one.

Does Cursor have a public bug bounty program?

No public bug bounty program as of May 2026. Anysphere accepts vulnerability reports at security-reports@cursor.com with a stated acknowledgement SLA of 5 business days. Forum requests in January and May 2025 confirmed the absence of a HackerOne or equivalent public bounty.

What should an AppSec lead do this week if their org runs Cursor?

Eight concrete moves: (1) Pin to Cursor 2.5 or later via MDM. (2) Force Workspace Trust on. (3) Disallow project-local MCP servers. (4) Allowlist OpenVSX publishers and block unpinned recommended extensions. (5) Enforce Privacy Mode org-wide and the model blocklist. (6) Pull SOC 2 Type II + pentest exec summary from trust.cursor.com. (7) Scope CI tokens; separate triage agents from build agents. (8) Set telemetry that alerts on Chromium-lag drift.

How does Cursor compare to Claude Code on security?

Cursor and Claude Code share most of the architectural attack surface — both run as workstation agents with full user privileges, both ingest project-scoped configuration files that can drive privileged execution, both use MCP servers with approve-once trust semantics. Cursor's enterprise tier (SSO/SCIM 2.0, Privacy Mode default for teams, audit logging) is structurally more developed than Claude Code's. Both share the audit-log gap on AI-activity telemetry. Anthropic has patched specific CVEs in the project-settings family while declining TrustFall; Cursor has patched its own MCP CVEs but remains exposed to TrustFall.

Where Repello fits#

Repello's workstation agent security cluster covers exactly the architectural patterns this guide describes — privileged agent runtimes processing adversary-controllable content with insufficient input segregation and inadequate sandbox enumeration. ARTEMIS carries payload batteries for the full Cursor CVE list above, plus the TrustFall and Comment and Control test suites. SkillCheck audits the MCP and skill-file layer that has driven half the Cursor CVE record. Agent Wiz (OSS, 375 stars) generates STRIDE threat models against your specific agent stack, naming which of the four patterns above is the highest-priority gap in your environment. If your organization runs Cursor in production and wants the test suite that covers the full CVE history plus the live unpatched issues, get in touch.