Exploit in Default Cursor Setting Runs Malicious Code on Dev Machines
▼ Summary
– Cursor, an AI-enhanced code editor, has a default setting that allows malicious code to run automatically when users open certain repositories without their consent.
– This vulnerability stems from Cursor disabling VS Code’s Workspace Trust feature by default, which normally prevents automatic code execution.
– Attackers can exploit this by hiding malicious tasks in public repositories that execute upon opening, potentially stealing data or compromising systems.
– Mitigation options include enabling Workspace Trust (which disables AI features) or configuring Cursor to block automatic task execution entirely.
– The developers of Cursor plan to publish security guidance but have not committed to changing the default Workspace Trust setting.
A newly identified security flaw within the popular Cursor AI code editor could allow attackers to execute harmful code on developers’ machines without their knowledge. This vulnerability stems from a default configuration that bypasses standard security prompts, putting sensitive development environments at risk.
Based on Microsoft’s Visual Studio Code, Cursor enhances the familiar editor with integrated artificial intelligence capabilities. However, unlike its parent application, Cursor ships with the Workspace Trust feature disabled by default. This setting normally acts as a safeguard, preventing automatic execution of code when opening projects from untrusted sources. With it turned off, the editor may run hidden instructions immediately upon folder access, no warnings or consent required.
Malicious actors can exploit this weakness by planting a booby-trapped repository containing a task configured to run on opening. Once a developer accesses the project using Cursor, the harmful script activates silently. This opens the door to a range of attacks, including credential theft, file manipulation, and data exfiltration.
The danger escalates when considering the elevated privileges often found on development workstations. These systems frequently store cloud access keys, API tokens, and active SaaS sessions. A single compromised machine could provide attackers a pathway into continuous integration pipelines, cloud infrastructure, or non-human identities with extensive permissions.
To reduce exposure, users can manually enable Workspace Trust within Cursor’s settings. Unfortunately, this action comes with a significant trade-off: it disables the very AI features that distinguish the editor. For teams relying on these tools, this may not be a practical solution.
Alternate protective measures include disabling automatic task execution through the editor’s configuration and isolating suspicious projects within sandboxed environments like virtual machines or containers. Developers are also advised to avoid storing credentials in easily accessible locations, loading them only when necessary.
The company behind Cursor, Anysphere, has acknowledged the issue and plans to release updated security guidance regarding Workspace Trust. As of now, there is no indication the default setting will change. Security firm Oasis has published a proof-of-concept demonstration and enterprise detection recommendations to help organizations identify potential threats.
Staying informed about emerging vulnerabilities is essential for maintaining a secure development workflow. Regular updates and cautious repository handling remain critical best practices in safeguarding against evolving threats.
(Source: HelpNet Security)
