Skip to content
Cursor IDE Auto

Cursor IDE Auto

Darkreading Alexander Culafi July 14, 2026

Researchers reported the vulnerability to Cursor in December, but it still remains in the popular AI coding platform and can be exploited in poisoned repository attacks.

Researchers say a newly discovered security vulnerability can cause a Cursor development environment to execute a malicious binary effortlessly.

Offensive security firm Mindgard today published new research detailing the vulnerability involving Cursor, an extremely popular AI tool used for software development . The vulnerability allows a developer to implant a malicious "git.exe" in a repository, and if a developer opens a project containing the git.exe binary in the repository at root, the Cursor client will automatically execute the poisoned file.

"The technical issue itself is remarkably straightforward. When loading a project, Cursor attempts to locate Git binaries across multiple locations," Mindgard's blog post read . "One of those locations includes the workspace itself. If an attacker planted a malicious git.exe in the repository root, Cursor will execute it automatically as part of its path resolution logic without warning, approval, or even an indication that executable content from the repository is to run."

In practice, an attacker can publish a malicious repository with a poisoned git.exe file and execute code with the privileges of the developer that inadvertently ran the file. It's a poisoned repository attack with fewer steps than one might normally see.

To showcase the vulnerability in a proof-of-concept (PoC) exploit, Mindgard took the Windows Calculator application, renamed it to git.exe, and placed it at the root of the repository. "Simply launching Cursor against that repository was enough to execute it," the blog post read.

Mindgard said it discovered and reported the vulnerability to Cursor on Dec. 15 of last year and "multiple times since" over the following six months. The issue remains present in the latest tested version of Cursor as of this writing.

A significant portion of the blog post was dedicated to the timeline of disclosing this vulnerability. The report explained that while Mindgard values and prefers coordinated disclosure between security researcher and the software publisher, the firm shared details with Cursor through email, , and a HackerOne bug bounty program. However, Cursor never accepted the report, addressed the issue, or provided any kind of resolution to Mindgard's report, the company said.

"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," the blog post read. "And at this point, withholding information no longer serves users, it serves silence. For that reason, Mindgard is releasing full details of this vulnerability. Organizations using Cursor deserve the opportunity to evaluate their exposure, implement compensating controls, and make informed decisions their security posture."

Dark Reading contacted Cursor for on the reported vulnerability. A spokesperson told Dark Reading on July 13, "I can confirm we are addressing this and will get back to Mindgard accordingly."

For users running on enterprise or managed Windows systems operating the AI-powered coding tool, Mindgard said administrators can use AppLocker or Windows App Control policies to deny execution of git.exe from developer workspace directories. The language around consumer systems is much stronger.

"Until the IDE [integrated development environment] is patched, open untrusted repositories only in an isolated VM, Windows Sandbox, or other disposable environment. Do not rely on file hash blocklists for this issue," the blog post read.

Aaron Portnoy, chief product officer at Mindgard, tells Dark Reading that the vulnerability would be simple to fix but is also exceptionally easy to exploit. Portnoy, who designed and directed the first six Pwn2Own competitions while running the Zero Day Initiative, added that a threat actor would "definitely operationalize this" if they had a target they wanted to go after.

"If you take a remote access Trojan, a ransomware binary, or whatever you want to execute and just call it git.exe, it runs unrestricted on the developer's machine as soon as they open the repo, or shortly thereafter without any notification," he says.

He adds that, "even without their source code, I could fix this vulnerability in five minutes by reverse engineering the one line change they need to make. It's baffling to me that we reported this in December and they've yet to fix it, which is why we're here talking today."

Senior News Writer, Dark Reading

Alex is an award-winning writer, journalist, and podcast host based in Boston. After cutting his teeth writing for independent gaming publications as a teenager, he graduated from Emerson College in 2016 with a Bachelor of Science in journalism. He has previously been published on VentureFizz, Security, Nintendo World Report, and elsewhere.

At Dark Reading, he covers a variety of cybersecurity topics, including the cybercrime ecosystem, open source security, and the intersection between AI and threat actors. In his spare time, Alex hosts the weekly Nintendo podcast, "Talk Nintendo Podcast," and works on personal writing projects, including two previously self-published science fiction novels.

He has received numerous awards, including TechTarget's Writer of the Year in 2022 as well as more than 10 Azbee awards for his reporting between 2022 and today.

The State of Cloud Security: The Latest Challenges

The total economic impact™ of Snyk

How Organizations Are Managing Incident Response

How Enterprises Are Developing Secure Applications

Inside RSAC 2026: security leaders reveal the risks redefining your defense strategy

When AI Becomes an Insider: Rethinking Risk in Critical Infrastructure

Governing the Agent; Identity Security in the Age of Autonomous AI

Securing the AI Era: Shadow AI, AI Agents, and Why AI Detection and Response Changes Everything

Practical Zero Trust Implementation on a Budget in the Age of Mythos

Building a Risk Based Vulnerability Management Program

Extracted Entities