Cloning and opening a repository in Cursor can execute arbitrary code on a developer's machine before a single line is typed or a prompt is sent to the AI. The flaw isn't in the language model but in the VS Code architecture Cursor inherits: tasks.json, recommended extensions, and MCP server configs load automatically when a folder opens. Cursor doesn't always enforce the Workspace Trust confirmation VS Code has required by default since 2020. On Windows, the malicious child process spawns from a signed binary (cursor.exe), which lowers traditional antivirus and EDR alerting.
What actually happens when you open a cloned repo in Cursor
A repository can ship a .vscode/tasks.json file with runOptions.runOn set to folderOpen. If the folder is already trusted or Workspace Trust is off, the task runs with no further confirmation. No targeted phishing or AI chat interaction is required: the vector is the act of opening the folder itself.
MCP: the backdoor with a name (MCPoison and CurXecute)
The Model Context Protocol adds a second AI-IDE-specific attack surface. In 2025, Check Point Research documented MCPoison: an attacker silently swaps the command behind an already-approved MCP server, and reopening the project runs the new command without re-prompting. That same year, Aim Security described CurXecute, where a manipulated MCP tool response made the AI agent itself write to its own config file, chaining prompt injection into code execution.
Why this isn't 'just' a prompt injection problem
The entry point is the editor acting as a folder-config interpreter, not the AI model. Policies focused only on what the AI can see or do leave the more direct vector uncovered: native code execution triggered by simply opening a folder.
- Developers clone and open any repo in Cursor with no prior review, Workspace Trust off or waved through by habit.
- Unverified repositories open first in an isolated VM or WSL sandbox, with no corporate credentials or internal network access, and only graduate after a .vscode/.cursor review.
The uncomfortable truth: banning Cursor isn't the answer
At Blurtek we don't recommend blocking Cursor as a first move: the productivity gain is real, and giving it up just pushes developers toward using it unmanaged on personal machines, which is the worse outcome.
Checklist: what your company must check before rolling out Cursor to developers
- Confirm Workspace Trust is on and doesn't default-trust new folders or subfolders of an already-trusted repo.
- Disable or audit automatic task execution (runOn: folderOpen) at the editor policy level, not per project.
- Manually review tasks.json, launch.json, and mcp.json before opening any external or unverified fork.
- Restrict which MCP servers a developer can register and block silent re-approval of changed configs.
- Clone and first-open external repos in a VM, container, or WSL with no corporate credentials or internal network access.
- Enforce least privilege: no local admin rights by default on machines running Cursor.
- Add EDR rules that flag cursor.exe spawning powershell.exe or cmd.exe outside a developer's usual pattern.
Minimum recommended Windows configuration
- Group Policy or MDM that prevents individual users from disabling Workspace Trust.
- Development account with no local admin rights, strict UAC.
- Separate working folder for external repos, isolated from environments holding production credentials or corporate VPN.
- Centralized logging of cursor.exe child processes via Sysmon or corporate EDR.
What to do if Cursor is already deployed without these controls
Start with a real inventory of which machines run it and under what privileges. Then prioritize removing local admin rights and enable Workspace Trust centrally before anything else.
If your company is evaluating or already using Cursor, Windsurf, or another AI IDE and isn't sure which Workspace Trust, MCP, or local-privilege controls are actually active on developer machines, Blurtek audits the real configuration against written policy and closes the gaps first.
Solicitar diagnóstico