Summary
- A planted git.exe in a repository root can allegedly execute repeatedly when Cursor opens the workspace on Windows.
- Mindgard says it reported the behaviour in December 2025 and disclosed it publicly after seven months without a fix.
- Cursor has not published a technical response or advisory, leaving organisations reliant on isolation and application controls.
A security researcher has disclosed an allegedly unpatched weakness in Cursor that can cause the Windows version of the AI-assisted development environment to execute attacker-controlled code when a developer opens a repository.
Mindgard said Cursor searches several locations for the Git executable while loading a project, including the project workspace itself. A malicious repository containing a file named git.exe at its root can consequently be selected and run without a confirmation dialogue or further user interaction.
The researcher demonstrated the behaviour by renaming Windows Calculator to git.exe and placing it inside a test repository. Opening the repository in Cursor caused Calculator to launch repeatedly as the application continued calling the planted executable.
An attacker could replace the harmless demonstration file with malware running under the current user’s identity. Developer accounts commonly have access to source code, package registries, cloud environments, SSH keys, browser sessions, build systems, and production support tools, giving local execution a route towards more sensitive systems.
Mindgard said it discovered and reported the behaviour on 15 December 2025. Its disclosure timeline records repeated attempts to obtain a vendor response, including submission through Cursor’s private bug-bounty programme.
After the report was initially rejected, the weakness was reportedly reproduced, and HackerOne confirmed that the details had been delivered to Cursor on 20 January. Mindgard says no substantive remediation update followed.
The researcher informed the disclosure platform in June that it intended to publish and released technical details on 14 July. Its last recorded verification took place on 30 April against Cursor 3.2.16 for Windows.
Cursor had not published a security advisory, corrected version, or technical response at the time of writing. No public evidence of exploitation has been identified, while the account of the disclosure process comes from Mindgard and has not been confirmed by the vendor.
The research disclosure recommends opening untrusted repositories only inside Windows Sandbox, a disposable virtual machine, or another isolated environment until the behaviour is corrected.
Managed Windows estates can also use AppLocker or Windows Defender Application Control to prevent executables running from development workspace directories. Hash-based rules are less reliable because an attacker can change the binary, while parent-aware restrictions may require an endpoint detection or application-control platform.
The behaviour arises from executable-search logic rather than the underlying language model, but its consequence is shaped by the level of authority granted to modern development tools. Coding assistants can inspect entire repositories, interact with terminals, alter files, invoke package managers, and access credentials already held by the developer environment.
Opening source code has traditionally been treated as lower risk than compiling or running it. Automatic tasks, extensions, language servers, dependency restoration, notebook execution, and project-specific configuration have already weakened that distinction across modern development environments.
Repository controls should distinguish internal, partner, and public code, while initial inspection of untrusted projects should take place inside an isolated environment. Developer workstations should not retain unnecessary production privileges, and monitoring should detect unexpected child processes launched by code editors and development tools.
Vulnerability intake and customer communication also form part of the enterprise assessment of rapidly updated software. Frequent product releases do not demonstrate that reported security issues are being triaged, corrected, and communicated through a dependable process.
Until Cursor publishes its own assessment, the finding remains a credible researcher disclosure rather than a mutually confirmed vulnerability. Windows users handling untrusted repositories can reduce their exposure through isolation, application control, reduced credential availability, and monitoring for a vendor update.
