Security researchers have disclosed an unpatched Cursor vulnerability that can allow a malicious Git repository to execute attacker-controlled code automatically when opened on a Windows system.
The flaw does not involve prompt injection, an AI agent, or manipulation of a language model. According to Mindgard’s technical disclosure, the only required user action is opening a project containing a malicious executable named git.exe in its root directory.
Cursor Executes Git From the Workspace
When Cursor loads a project, it attempts to locate a Git executable across several possible locations. One of the locations searched is the current workspace.
An attacker can exploit this behavior by placing a malicious git.exe file inside a repository. When the victim opens that repository, Cursor may treat the attacker-controlled file as the legitimate Git binary and execute it without displaying an approval dialog or warning.
Mindgard demonstrated the issue using Windows Calculator renamed to git.exe. Opening the project caused Cursor to launch Calculator automatically and continue launching additional instances while the workspace remained open.
Process Monitor logs showed Cursor.exe spawning the repository-controlled executable using the command:
git rev-parse --show-toplevel
In a real attack, the harmless Calculator demonstration could be replaced with malware capable of stealing credentials, deploying ransomware, installing a backdoor, or accessing source code and development secrets under the current user’s privileges.
No Prompt or AI Interaction Required
Unlike many recently disclosed AI coding assistant vulnerabilities, this attack does not require the Cursor agent to read malicious instructions or approve a command.
The code-execution path occurs during normal project loading, before the developer needs to interact with the repository’s contents. There are no confirmation prompts, authorization requests, or visible indications that executable content inside the workspace is being launched.
Cursor may also invoke the malicious file repeatedly as it performs background Git operations, allowing the payload to run more than once while the repository remains open.
Reported Seven Months Before Disclosure
Mindgard discovered and reported the vulnerability to Cursor on December 15, 2025.
The researchers said an internal automation failure initially prevented their report from reaching Cursor’s private HackerOne program. The report was later resubmitted, initially closed as informational, and reopened after HackerOne reproduced the issue.
Mindgard subsequently sent multiple requests for an update but said it received no meaningful information about remediation. The firm publicly disclosed the vulnerability on July 14, 2026, after more than seven months of attempted coordination.
The public technical evidence identifies Cursor 3.2.16 on Windows as the last specifically documented affected version, tested on April 30. Mindgard says the vulnerability remained present after more than 197 Cursor releases, but its disclosure does not identify the exact version used for its most recent test.
As of July 15, Cursor had not published a security advisory identifying a fixed release, and no CVE had been assigned.
Temporary Mitigations
Until Cursor publishes a confirmed patch, developers should avoid opening unknown or newly cloned repositories directly on their primary Windows environment.
Untrusted projects should instead be inspected inside Windows Sandbox, a disposable virtual machine, or another isolated development environment. Security teams can also use AppLocker or Windows Defender Application Control to block executables such as git.exe from running inside repository and workspace directories.
Because attacker-supplied files can have different hashes, Mindgard recommends using path-based restrictions rather than relying only on hash blocklists.
Organizations with endpoint detection and response capabilities should also monitor for unusual child processes launched by Cursor.exe, especially executables originating from source-code directories.
The vulnerability highlights a broader development security risk: cloning and opening a repository should not automatically grant executable content inside that repository permission to run. Developer workstations frequently contain source code, API keys, cloud credentials, SSH keys, and access to production infrastructure, making them valuable targets for poisoned-repository attacks.
