Security researcher Aaron Portnoy of Mindgard AI security firm published a full public disclosure of a code execution vulnerability in the Cursor AI code editor after reporting the flaw to Cursor in December 2025 and receiving no patch across seven months of follow-up. The vulnerability allows an attacker who controls a malicious repository to execute arbitrary code silently on a developer’s Windows machine the moment the developer opens the project folder in Cursor — with no approval dialog, no warning, and no additional action required from the target.
How a Trojanized git.exe Silently Executes When Cursor Opens a Repository
When Cursor loads a project folder on Windows, the editor searches for a Git binary in multiple filesystem locations — including the workspace root, which is the directory the developer just opened. Cursor then runs the probe command git rev-parse --show-toplevel against whatever binary it finds at that location, as part of its standard project initialization. If a file named git.exe sits in the project root of the repository the developer just cloned, Cursor executes that file immediately — with no prompt, no warning dialog, and no indication to the developer that anything beyond normal project loading is occurring.
An attacker constructing an exploit for this flaw would place a git.exe trojan alongside legitimate-looking source code files in a repository hosted on any public code platform. When a developer clones the repository and opens the project folder in Cursor on a Windows machine, the trojanized binary executes automatically with whatever permissions the developer’s process carries. Because the execution is triggered by Cursor’s own initialization sequence rather than any developer action beyond opening a folder, it bypasses the developer’s instinct to not run unknown executables.
The Seven-Month Disclosure Timeline From Mindgard’s Report to Public Release
Portnoy reported the vulnerability to Cursor on December 15, 2025. Over the seven months that followed, Cursor published no security advisory and released no patch. Mindgard’s disclosure on July 15, 2026 came after that remediation window expired without vendor action.
The disclosure notes that Mindgard confirmed the flaw in Cursor version 3.2.16 during testing on April 30, 2026. Critically, Mindgard confirmed the vulnerability “survives in the newest version it tested” — Cursor 3.11, which shipped on July 10, 2026. Five days after Cursor’s most recent release, the flaw remained present. As of the disclosure date, Cursor had published no security advisory acknowledging the vulnerability.
The seven-month gap between initial report and public disclosure is notable in context. Industry norms typically frame 90 days as a standard coordinated disclosure window, with extensions granted when vendors demonstrate active remediation progress. Seven months without a patch and without a public advisory exceeds any reasonable extension of that window.
Why Developer Workstations Are the High-Value Target in This Attack Scenario
The Cursor vulnerability’s severity is amplified by what developer workstations contain. Professional developers, particularly those using an AI-accelerated code editor like Cursor, routinely work with source code repositories, cloud provider credentials, SSH keys, API tokens, and configurations that grant access to CI/CD pipelines and production infrastructure.
A git.exe trojan that executes inside a developer’s Cursor session on a machine with AWS credentials in ~/.aws/, SSH private keys in ~/.ssh/, and access tokens in environment variables or configuration files can silently exfiltrate all of that material before the developer finishes reviewing the repository they opened. Because the malicious execution happens before the developer has looked at the code, the developer may never observe any indication that data was stolen.
Supply Chain Risk From Cursor’s Binary Path Search Behavior
The attack vector in this vulnerability is the normal developer workflow of discovering, cloning, and exploring open-source or third-party repositories — an action developers perform daily. Malicious actors who publish repositories designed to exploit this flaw can target developers broadly by attracting repository visits through popular search terms, dependency names, or code samples relevant to common development tasks.
This is distinct from the DuneSlide vulnerability documented in an earlier Cursor disclosure. DuneSlide was a prompt injection attack that targeted Cursor’s AI sandbox; this flaw operates at the operating system level through Cursor’s workspace loading behavior and has nothing to do with Cursor’s AI components. The two represent different attack surfaces within the same product.
Until Cursor patches the binary search path behavior or adds a warning when a project root contains an executable named git.exe, developers on Windows should avoid opening repositories from unfamiliar or untrusted sources inside Cursor. Portnoy and Mindgard directed the disclosure to the public after the remediation timeline expired, with the intent of prompting Cursor to acknowledge and patch the flaw.
