Mindgard researchers have disclosed a zero-day in Cursor, an AI-powered integrated development environment (IDE), that allows arbitrary code execution on Windows simply by opening a repository.
Published on July 14, 2026, the finding shows Cursor’s Git binary discovery logic searches workspace paths for a usable git executable and will run a git.exe located at the project root without user interaction, effectively giving an attacker a way to execute code with the logged-in user’s privileges.
The vulnerability stems from Cursor’s path-resolution behavior: when a workspace loads, the application probes several locations to locate a Git binary, including the active project directory.
Cursor zero-day
An attacker who can place or commit a malicious git.exe at the repository root, via a cloned repo, archive, dependency, or social-engineering vector, can cause Cursor to invoke that binary as part of its routine discovery.
Mindgard’s proof-of-concept renamed Windows Calculator to git.exe, placed it in a test repository, and demonstrated that opening the repository in Cursor launched the executable. Process Monitor telemetry included in the report shows Cursor creating a process that ran “git rev-parse –show-toplevel,” confirming the app invoked the workspace-resident executable.
Worryingly, the researchers observed repeated invocations while the workspace remained open, not a single one-time check, increasing the attack’s potential impact.
Verified on April 30, 2026 against Cursor version 3.2.16 on Windows, this bug enables a realistic attack chain: a threat actor could swap the benign file for malware capable of exfiltrating source code, harvesting credentials, installing persistence mechanisms, or performing lateral movement across development environments.
Because developers frequently pull repositories from external contributors, open-source projects, vendors, or internal collaboration channels, the attack surface is broad and aligns with common developer workflows.
Mindgard’s disclosure timeline also highlights challenges in vulnerability reporting: the issue was reported to Cursor on December 15, 2025 through the company’s security contact and its HackerOne program, but the initial report was closed as “informative/out of scope.”
After subsequent reproduction and escalation, Cursor eventually received the findings, yet Mindgard reports receiving no meaningful remediation update over seven months and multiple product releases. This delayed response prolonged the window of exposure for users.
Until Cursor ships a patch, organizations and individual developers should assume untrusted workspaces pose a serious threat on Windows.
Recommended mitigations focus on preventing execution of workspace-controlled binaries: enterprises can implement AppLocker or Windows App Control policies that block execution from developer workspace and repository directories.
Path-based execution controls are preferable to hash blocklists since attackers can trivially modify a binary to evade hash-based defenses. For individuals or small teams, opening untrusted repositories only inside isolated environments, such as virtual machines, Windows Sandbox, or disposable containers, reduces risk.
This disclosure underscores a wider supply-chain and product design risk tied to AI-assisted development tools. IDEs and AI agents that manage source code, terminals, credentials, and repository access must avoid executing workspace-controlled binaries during routine environment discovery.
Vendor-side fixes should ensure secure binary discovery (for example, restricting search paths, validating binaries against known system installations, and requiring user consent) and provide transparent, timely communication to security researchers and customers.
Until then, defensive controls and cautious handling of external repositories remain the most reliable protections for development teams.
No Comment! Be the first one.