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 no click or approval from the user.
• The behaviour turns any cloned or shared repository into a possible trap for the person who 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 will run it. No click. No pop-up. No warning that anything is about to happen.

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 looks in a list of folders to find the real git.exe. But it also checks the current folder first. Drop a file named git.exe into a project's root directory, and that fake will be found before the real one.

Cursor, first reported by The Hacker News to behave this way, does exactly that lookup as soon as a repository is opened. Whatever that fake binary contains, it runs. As you. 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 sitting on the machine.

And it does not stop. Cursor re-runs the file over and over for as long as the project stays open in the editor.

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 just means downloading a copy of someone else's project to work on locally. If that project happens to contain a git.exe file in its root, opening the folder in Cursor is enough to trigger the attack. The user never runs anything themselves. The editor does it for them.

The practical impact is the sort of thing 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 in the background. From there, the 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 sometimes called binary planting or search-order hijacking, where a program is tricked into loading a file from an untrusted location. What makes this case sharper is that the untrusted location is a project folder, and project folders routinely come from the internet.

What should developers do right now?

Treat any cloned repository as potentially hostile until reviewed. Before opening a downloaded project in Cursor on Windows, check the root folder for anything named git.exe, or any other executable that shares a name with a common command-line tool. On Windows, hidden file extensions make this easier to miss than it should be, so turn on "show file extensions" in File Explorer.

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 also flag when a child process spawns from an editor in an unusual location.

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

Which, for a tool sold on trusting the AI in your editor, is an uncomfortable place to be.