Cursor on Windows Runs Rogue git.exe From Any Opened Repo, No Warning

Key points

• Cursor, an AI-powered code editor, will silently run a file called git.exe if it sits in the root of a project folder opened on Windows.
• The program runs with the developer's own permissions, giving it access to source code, SSH keys, and cloud login tokens.
• Cursor keeps re-running the rogue file for as long as the project is open, with nothing from the user to trigger it.
• The behaviour turns any cloned or shared repository into a possible trap for whoever opens it.

Open a project in Cursor on Windows and, if someone has slipped a file called git.exe into the top of that folder, Cursor runs it. There's no pop-up, no warning that anything is about to execute.

Cursor is a code editor built around AI, popular with developers who want a chatbot sitting next to their source code. It leans heavily on Git, the standard tool programmers use to track changes to their files. That leaning is the problem.

On Windows, when a program asks the operating system to run "git", the system searches a list of folders to find the real git.exe. It also checks the current folder first. Drop a file named git.exe into a project's root directory and that fake gets found before the real one.

Cursor does exactly that lookup as soon as a repository is opened. Whatever the fake binary contains, it runs with your files, your saved passwords, your SSH keys (the digital credentials that let you log into servers without typing a password) and any cloud tokens on the machine. It doesn't stop there: Cursor re-runs the file over and over for as long as the project stays open.

This is the third Cursor vulnerability we've reported since 3 July, when our first story on the editor's code-execution flaws found researchers had flagged similar silent-execution behaviour months earlier.

How does a developer end up running a stranger's code?

By doing something developers do dozens of times a week: cloning a repository. Cloning means downloading a copy of someone else's project to work on locally. If that project contains a git.exe file in its root, opening the folder in Cursor triggers the attack. The user never runs anything themselves; the editor does it quietly in the background.

The practical damage is the kind that keeps security teams awake. A developer who reviews a pull request, tries out an open-source library, or opens a repo shared by a colleague could hand over their credentials without seeing a thing. From there, an attacker can push malicious code into other projects the developer has access to, steal secrets from cloud accounts, or move sideways into a company's internal systems.

This is a variant of a long-known Windows behaviour called binary planting or search-order hijacking, where a program is tricked into loading a file from an untrusted location. What sharpens this particular case is that the untrusted location is a project folder, and project folders routinely come from the internet.

Should you worry if you already cloned something?

Yes, if you opened it in Cursor on Windows without checking. Before opening any downloaded project in the editor, look in the root folder for anything named git.exe, or any executable sharing a name with a common command-line tool. Windows hides file extensions by default, making this easier to miss than it should be, so turn on "show file extensions" in File Explorer first.

Organisations running Cursor at scale should look at controlling which folders are trusted and consider policy settings that block executables from running out of user-writable directories. Endpoint detection tools can flag when a child process spawns from an editor in an unexpected location.

Cursor has been contacted about the behaviour. Until a fix ships in a signed update, opening an unfamiliar repository in the editor is effectively the same as running whatever code that repository's author chose to include.

For a tool sold on the idea that you can trust the AI sitting in your editor, that's an uncomfortable position to be defending.