BlogTechnical

Reviewing Cursor deployments — Privacy Mode is off by default

Cursor's Background Agents and Workspace Trust controls are real. Privacy Mode, which stops code from being stored or used for training, isn't on by default — not unless someone turns it on.

Drel Research7 min read

Cursor is a standalone VS Code fork with AI built into the editor itself — Composer and Agent Mode for multi-file edits, Background Agents for longer-running tasks, and repository-wide code understanding. It maintains SOC 2 Type II compliance and publishes its security posture through a trust center. The single most consequential fact for a review isn't in any of that — it's a default setting most teams never revisit.

Cursor, briefly

Cursor's Agent has tools to search the codebase, read and edit files, run shell commands, use a browser, and fetch context — a broad toolset by default, scoped down by two controls worth knowing about: Workspace Trust, which requires explicit approval before enabling features that could execute code (helping prevent automatic execution of malicious code from a freshly cloned repository), and First-Party Tool Restrictions, which limit the agent to a curated safe set unless additional tools are explicitly enabled.

Privacy Mode defaults to off

Three defaults a review should confirm, not assume

SettingDefault stateWhat it actually means
Privacy ModeOff, on Free and Pro plansCode, prompts, and editor actions may be stored and used to train models — by default, not by misconfiguration.
Workspace TrustRequires explicit approval before code-executing features activateBlocks automatic execution from a freshly cloned, untrusted repository — but only if left enabled.
First-Party Tool RestrictionsAgent limited to a curated safe tool setShell and browser access require an explicit opt-in to widen — narrow until a team chooses otherwise.

For a review, this is the first setting to confirm, not the last — everything else about Cursor's tool permissions and sandboxing is downstream of whether the organization's code is even meant to leave the local environment in the first place.

The rules-file surface, and what limits tool access

Cursor shares the Rules File Backdoor exposure covered in reviewing GitHub Copilot's coding agent — hidden Unicode in a project's AI rules file can steer generated code silently. Cursor's own stated position is that responsibility for reviewing rule-file content lies with the user, which for a review means: treat any rules file pulled from outside the organization as untrusted input requiring inspection, the same as any other third-party dependency.

Where Cursor differs from a purely cloud-sandboxed agent is that Agent Mode and Background Agents can run with direct access to the local machine's shell and browser, depending on configuration — the First-Party Tool Restrictions default is what keeps that surface narrow until a team explicitly widens it.

DuneSlide — a zero-click sandbox escape

The trigger requires nothing from the user — Cato's own description names “an innocuous MCP server request, or a poisoned web result” as sufficient. Every version before 3.0 was affected; the fix shipped April 2, 2026. Given Cursor's maker states more than half the Fortune 500 uses the product, this is exactly the class of finding a review should confirm is closed by version number, not by general reputation for the product being well-regarded.

Separately, CVE-2026-26268 (CVSS 8.1) showed that simply cloning a malicious repository containing a poisoned Git hook could trigger code execution on the developer's machine — no agent interaction required at all. Fixed February 2026. Between this and the five earlier 2025 RCE disclosures against Cursor (CVE-2025-59944 and four related CVEs), the pattern is a repeat one, not a single incident.

A second attack surface: the bundled Chromium

Beyond Cursor's own code, researchers at OX Security (Nir Zadok, Moshe Siman Tov Bustan, and Mustafa Naamnih) found that Cursor and Windsurf both shipped an Electron/Chromium build dated March 21, 2025 — despite materially newer Chromium releases being available — carrying 94 known Chromium CVEs into every install. They weaponized one, CVE-2025-7656 (a V8 Maglev JIT integer-overflow bug triggerable via a JavaScript function called with roughly 40,000 arguments), to demonstrate real exploitability rather than theoretical exposure, with combined exposure across both products cited at roughly 1.8 million developers.

The review-relevant pattern here generalizes past Cursor specifically: any Electron-based agentic IDE inherits its bundled browser engine's CVE history as a second, independent attack surface — separate from the agent's own tool-calling logic — and a review should ask what the bundled Chromium version actually is, not assume it tracks upstream releases closely.

Review checklist

For any team deploying Cursor, a design-time review should be able to answer:

  • Is Privacy Mode explicitly enabled organization-wide, verified per plan/seat rather than assumed?
  • Have the project's own AI rules files been audited for hidden Unicode or suspicious instructions, especially any adopted from external templates?
  • Beyond First-Party Tool Restrictions' defaults, which additional tools (shell, browser, custom MCP servers) have been explicitly enabled, and for whom?
  • Is Workspace Trust enforced for any repository the team clones from outside the organization?
  • Is Cursor pinned past version 3.0, closing the DuneSlide sandbox-escape CVEs (CVE-2026-50548, CVE-2026-50549) and the Git-hook RCE (CVE-2026-26268)?
  • What Chromium/Electron version does the installed Cursor build actually bundle, and is it tracked separately from Cursor's own release version?

Sources

Blog

Get new posts in your inbox

AI security review, OWASP Agentic Top 10, ISO 42001 evidence, and what AI Committees actually need. No cadence promises — we publish when there's something worth reading.

Review a Cursor deployment before it ships

Privacy Mode configuration, rules-file provenance, and tool-access scope — mapped to a disposition your AI Committee can act on.

A note on scope: Drel reviews assessed systems against documented architecture, configuration and intent. It does not ingest live telemetry from production environments. Dispositions reflect the assessed system at the time of review and the re-assessment triggers that govern when the disposition must be revisited.