Cursor Flaw Lets Malicious Cloned Repositories Trigger Windows Code Execution

The rapid adoption of AI-integrated development environments has fundamentally changed how engineers write and review code, but a recently identified vulnerability in the popular Cursor editor serves as a stark reminder that convenience often comes at a cost. Security researchers have uncovered a critical flaw in the Windows version of the application that allows for immediate, silent code execution simply by opening a cloned repository. This discovery highlights a significant blind spot in the security model of modern development tools, turning a routine workflow task into a potential gateway for full system compromise.

The vulnerability specifically targets the mechanism Cursor uses to interact with version control systems. When a user opens a project folder on a Windows machine, the editor attempts to utilize the Git executable. However, instead of restricting its search to a secure, system-defined path, the software prioritizes a file named git.exe located within the root directory of the opened project. The alarming consequence is that if a malicious actor includes a malicious binary with that specific name in a repository, Cursor will execute it instantly. This occurs without any user interaction, security warnings, or approval dialogs, effectively bypassing the standard consent mechanisms users expect from their operating systems and applications.

This issue poses a severe risk to the software supply chain and developer environments. Because the editor runs within the user’s current session, the malicious code inherits all associated permissions and access rights. For a developer, this often means the attacker gains immediate access to source code, proprietary algorithms, SSH keys, and cloud infrastructure tokens. Furthermore, the software repeatedly triggers the executable as long as the project remains active in the interface. This persistence ensures that a malicious payload can maintain a foothold or continuously exfiltrate data without requiring a second trigger event.

For security teams, the implications of this flaw extend far beyond a simple software patch. It represents a broader trend where trusted productivity tools can be weaponized against high-value targets within an organization. Development environments are notoriously difficult to secure because they require high levels of privilege and broad network access to function effectively. This vulnerability underscores the necessity of treating developer workstations as high-risk assets. Security leaders must advocate for the implementation of strict sandboxing for code editors, the use of least-privilege access policies for development credentials, and robust monitoring for unusual process execution patterns originating from trusted applications.