Cursor Reportedly Runs a Malicious git.exe When Windows Users Open a Repository

What happened

Security company Mindgard says Cursor can automatically execute a file from inside a repository when a Windows user opens the project.

The July 14 disclosure concerns a file named git.exe placed in the repository’s root folder. Cursor reportedly finds that file while initializing its Git features and runs it instead of the trusted Git installation elsewhere on the computer.

Mindgard demonstrated the behavior with a harmless test. Its researchers renamed the Windows Calculator application to git.exe and placed it in a test repository. Opening the project in Cursor caused Calculator to launch repeatedly without another click or approval prompt.

Process logs published by Mindgard show Cursor launching the repository-local file with a Git command. The researchers last documented the behavior on April 30 using Cursor 3.2.16 on Windows.

Mindgard says it first reported the issue to Cursor on December 15, 2025. According to the company’s disclosure timeline, Cursor’s private HackerOne program initially classified the report as informational. The report was reopened after reproduction, but Mindgard says it received no substantive update before publishing the details.

Cursor has not publicly confirmed the specific issue, published an advisory, or identified an affected version range. BuilderWithin did not independently reproduce the reported behavior. No public Cursor response to Mindgard’s disclosure was available at publication time.

BuilderWithin contacted Cursor for comment before publication and will update this article if the company responds.

The risk is serious, but its limits matter

This is not a remote attack that compromises every Cursor installation without any action from the user. The reported path requires someone to acquire a malicious repository and open it in Cursor on Windows.

The concerning part happens next. If Mindgard’s finding is accurate, the repository can contain executable code that Cursor runs automatically. The user does not need to start the program, approve an agent command, or accept an additional warning.

That distinction matters for AI-native builders. Opening a repository often feels like opening a folder of text files. Modern coding tools do much more in the background. They inspect Git status, start language services, load extensions, read project instructions, and prepare agents before the builder begins working.

Code execution would give the planted file the same access as the person running Cursor. That could expose source code, local files, API keys, cloud credentials, or other secrets available to that Windows account.

The report only concerns Windows. Mindgard has not claimed that the same behavior affects Cursor on macOS or Linux.

This is a known class of Windows weakness

The underlying problem is broader than AI coding tools. Some Windows applications search the current folder for a requested program before checking trusted installation locations. An attacker can exploit that behavior by giving a malicious program the same filename as a legitimate tool.

This vulnerability class has affected developer software before. In 2020, GitHub fixed a similar issue in Git Credential Manager. A malicious git.exe in a repository could run instead of the expected Git program during certain operations.

That history supports the technical plausibility of Mindgard’s report. It does not independently confirm that current Cursor releases remain affected. Mindgard’s published evidence is still the only public verification of this specific Cursor behavior.

Who should care

Windows users who open repositories from people or organizations they do not know should pay attention. The risk also applies to downloaded project archives and repositories recommended by AI assistants, tutorials, forum posts, or social media accounts.

Builders who use Cursor only with repositories they created themselves face less exposure. Trust still depends on everyone who can add files to those projects and on the security of any source from which the repository was copied.

Mac and Linux users are not included in Mindgard’s report. They should not assume every automatic action in a coding tool is harmless, but this specific warning does not apply to their operating systems based on the available evidence.

What Windows builders should do now

Until Cursor confirms the status of the issue, treat unfamiliar repositories as potentially executable content.

Before opening a downloaded project in Cursor, inspect its top-level folder using File Explorer. An unexpected file named git.exe in the project itself is a warning sign. Do not run it or open that project in Cursor.

For repositories you cannot fully trust, use Windows Sandbox, a disposable virtual machine, or another isolated environment. Mindgard recommends this approach for individual users while the patch status remains unknown.

Managed organizations can consider Windows App Control, AppLocker, or endpoint security rules that prevent executables from running inside development folders. Those controls usually require someone familiar with Windows administration.

If you already opened a suspicious repository containing an unexpected git.exe, close the project and treat the computer as potentially compromised. Run an endpoint security scan and rotate sensitive credentials from a clean device. This includes API keys, cloud tokens, and repository credentials that were accessible from the affected account.

Cursor’s security page says the company communicates critical incidents to affected users. No notice for this reported issue was publicly available when this article was prepared.

The practical takeaway is simple. A repository is not always passive source code. When a development tool automatically initializes a project, opening the folder can be a security decision of its own.

End of article