Bug in Cursor Allows Simple RCE

There is a critical zero-day vulnerability in Cursor, a widely adopted AI-assisted integrated development environment that has been present for at least eight months and has gone unresolved, despite efforts from security researchers who reported the bug to Cursor in December. The flaw allows for arbitrary code execution on Windows systems simply by opening a repository containing a malicious Git binary.

The vulnerability stems from the IDE's internal logic for locating Git binaries. When a project is loaded, Cursor scans various system paths to find the necessary executables, and this search logic incorrectly includes the root directory of the workspace itself. If an attacker plants a malicious file named git.exe in that root directory, the application automatically executes it as part of its initialization process. 

This exploit occurs entirely in the background, requiring no user approval, dialogue prompts, or interaction. Mindgard researchers demonstrated the exploit by successfully launching the Windows Calculator simply by renaming the application to git.exe and placing it in the root of a test repository.

Mindgard originally identified and reported this issue on Dec. 15 through the disclosure email on the Cursor website. Over the subsequent seven months, the Mindgard attempted to communicate through multiple channels, including direct emails to the company’s email address and through the HackerOne bug bounty program. Despite the release of more than 197 new versions of the IDE during this time, the bug remains present in the latest tested release. After failing to receive any indication that remediation was underway or that users had been informed of the risk, Mindgard opted for full disclosure.

“The industry narrative is that these systems deserve trust because they increase productivity, but history has taught us time and again that trust should not be granted because something is useful."

“Like many security research teams, Mindgard prefers coordinated disclosure. The goal is always security first, publicity second. But coordinated disclosure only works when there is coordination. Seven months after initial disclosure, we have no indication that users are being protected, that remediation is underway, or that affected organizations have been informed. And at this point, withholding information no longer serves users, it serves silence,” Aaron Portnoy of Mindgard wrote in a post on Tuesday. 

Portnoy is a longtime security researcher who helped run the Pwn2Own hacking competition at the CanSecWest conference for many years and has decades of experience reporting vulnerabilities to vendors.

"I think this is a messy space and some of these companies just aren't prepared and don't know how to treat vulnerability reports. The incentives aren't aligned, and they're still trying to figure out a disclosure process that's been in place for decades now," Portnoy said in an interview.

After he published the blog post with details of the Cursor bug, Portnoy said another researcher messaged him and said he had founf the same bug in January and reported it to Cursor through HackerOne, which closed the report as a duplicate.

The vulnerability highlights broader concerns regarding the security posture of AI-driven development tools that frequently request high-level access to local files, terminals, and sensitive secrets. By automating interactions with project repositories, the IDE could create a vector for code execution that bypasses standard security expectations.

“The industry narrative is that these systems deserve trust because they increase productivity, but history has taught us time and again that trust should not be granted because something is useful. It should be earned through behavior. That behavior is reflected in how a company responds to security reports, communicates with affected users, and prioritizes remediation,” Portnoy wrote in the post.

For organizations and individual developers who use Cursor, developers should treat all external repositories as potentially hostile and avoid opening them in their primary Cursor environment. Instead, any untrusted code should be examined within isolated, disposable environments such as Windows Sandbox or virtual machines.