A newly disclosed security vulnerability in the AI powered code editor Cursor could allow attackers to execute arbitrary code on Windows systems simply by convincing users to open a malicious Git repository. Security researchers revealed that the flaw enables a fake git.exe file placed inside a project’s root directory to run automatically without requiring any user interaction, warning message, or approval prompt. The issue allows the malicious executable to run with the same permissions as the logged in user, potentially exposing source code, SSH keys, cloud credentials, and other sensitive information.
The vulnerability was discovered by AI security company Mindgard, which reported the issue to Cursor on December 15, 2025. After waiting seven months without a security update or public advisory, the company released its full technical findings. According to the report, Cursor searches for a Git executable when loading a project on Windows, and one of the locations it checks is the repository’s root folder. Process Monitor logs published by the researchers show Cursor launching the executable using the command “git rev-parse –show-toplevel” as part of its repository detection process. Mindgard demonstrated the flaw by renaming Windows Calculator to git.exe and placing it in the project directory. Once the repository was cloned and opened in Cursor, Calculator launched automatically and continued reopening as long as the project remained open. The exploit does not require prompt injection, AI model manipulation, prior system access, or additional user interaction beyond opening the repository. Researchers noted that the attack scenario is practical because developers frequently clone repositories from external sources, making it possible for attackers to distribute malicious repositories that include the fake executable. Mindgard most recently confirmed the vulnerability on April 30, 2026, using Cursor version 3.2.16. Although the company stated the issue remained present in the latest version it tested, it did not identify the specific release. Cursor version 3.11 became available on July 10, 2026, but no confirmation has been provided regarding whether the flaw has been addressed. As of July 15, Cursor had not published any advisory or received a CVE identifier for the vulnerability.
Until an official fix becomes available, security experts recommend several temporary mitigation measures. Mindgard advises organizations managing Windows environments to implement AppLocker or Windows App Control rules that block unauthorized executables within repository directories by using path based restrictions instead of file hashes, since attacker created binaries can easily change. Because Windows does not natively support blocking child processes based on their parent application, organizations may require Endpoint Detection and Response solutions for more advanced enforcement. Individual developers are encouraged to open untrusted repositories inside Windows Sandbox or disposable virtual machines to reduce the risk of compromise. Researchers also recommend inspecting cloned repositories and extracted archives before opening them, specifically checking for unexpected executables such as git.exe, npx.exe, node.exe, or where.exe in the project root, as these files generally should not be present. Mindgard also questioned Cursor’s vulnerability disclosure process, stating that although the company’s security policy promises acknowledgment of reports within five business days, communication on this issue stalled after initial responses despite repeated follow ups throughout February, March, and April. According to the researchers, HackerOne successfully reproduced the issue after the report was reopened, but no public fix followed.
The findings also highlight a wider security concern affecting multiple AI development tools on Windows. Earlier research published by Cymulate identified the same class of vulnerability in GitHub Copilot CLI, Gemini CLI, and the Codex desktop application, where helper executables could be resolved using Windows’ default search order, allowing a malicious git.exe placed inside a workspace to execute automatically. At the time of Cymulate’s publication, none of the vendors had released fixes for this specific issue. GitHub reportedly accepted the report, awarded a bug bounty, and later reduced its severity rating. Google acknowledged the Gemini CLI finding without issuing a patch, while OpenAI classified the Codex report as not applicable, arguing that replacing git.exe already required system access, a position the researchers disputed. Cursor similarly categorized a related report as informative. AWS was the only vendor to issue a fix, although it addressed a different vulnerability in Kiro involving automatic execution through a poisoned tasks configuration file, tracked as CVE-2026-10591. Researchers noted that this type of weakness is not new, pointing to a similar untrusted search path issue that affected Git Credential Manager Core in 2020, where a malicious git.exe could also be executed during repository operations. Security experts say the recurring nature of these vulnerabilities serves as a reminder that cloned repositories should be treated as executable content on Windows systems until stronger protections are widely adopted.
Follow the SPIN IDG WhatsApp Channel for updates across the Smart Pakistan Insights Network covering all of Pakistan’s technology ecosystem.
