Cursor IDE 0day Vulnerability Allows Arbitrary Code Execution by Opening Malicious Repository
- Sophie Larsen
- 3 hours ago
- 2 min read
Cursor IDE contains a zero day vulnerability that lets attackers execute arbitrary code simply by tricking users into opening a malicious repository on Windows. No clicks or explicit approval are needed once the folder loads.
Security firm Mindgard found the issue on December 15 2025. The flaw stems from how Cursor searches for the Git binary across many folders including the workspace itself.
How the Flaw Lets Code Run Without Interaction
Cursor looks for git.exe in several places when a project opens. One of those places is the current workspace folder. An attacker can place a malicious file named git.exe inside the repository.
When a user clones or opens the folder Cursor runs the attacker file automatically. The execution happens because the search order places the workspace location ahead of safer system paths on Windows.
The attack needs no further user action after the repository is first loaded. Researchers tested the vector on current Windows builds and confirmed consistent execution.
Timeline Shows Repeated Reports Met Slow Fixes
Mindgard contacted Cursor multiple times over seven months. The company CISO acknowledged the reports yet an internal automation failure stopped the issue from reaching the engineering queue.
More than seventy new versions shipped during that period. None addressed the search order or added validation for the Git binary.
Cursor still ships without a fix today. The disclosure moved to full public status when internal remediation showed no progress.
Practical Steps Users Can Take Right Now
AppLocker rules can block execution of any file named git.exe from workspace directories. The policy prevents the malicious binary from running even if Cursor attempts to call it.
Running untrusted repositories in an isolated virtual machine also limits exposure. The virtual machine keeps the host system safe if the code launches.
Cursor users on macOS face lower risk because the search path behavior differs from Windows. Linux builds show similar exposure when workspace paths take priority in the binary lookup.
Why IDE Search Logic Creates Ongoing Risk
Many editors rely on system environment variables to locate tools such as Git. Cursor expands that logic to include project folders for speed. The added flexibility widens the attack surface when repositories arrive from unknown sources.
Similar patterns have appeared in other developer tools that auto detect binaries. Each case required explicit allow lists or hash checks before the risk dropped.
Cursor has not published a public statement describing new safeguards or a planned release date. The vendor continues to ship updates that leave the original lookup order unchanged.
What Remains Unclear After Disclosure
Mindgard has not released a full proof of concept or exploit chain. The exact scope of other binaries that Cursor might discover through the same search remains unknown.
It is still unclear whether the company plans to restrict workspace binary lookup or rely solely on user side policies. No coordinated disclosure timeline with other IDE vendors has been announced.
Developers who open repositories from unknown contributors should apply the mitigation steps today. The issue demonstrates how convenience features in IDEs can undermine standard operating system protections when search paths remain unchecked.