Opening a Git repository in a vulnerable version of Cursor could be enough to give attackers code execution on a developer\u2019s Windows machine.<\/p>\n
Security researchers at Mindgard discovered that Cursor would execute a malicious git.exe file planted in the root of a cloned repository, allowing attacker-controlled code to run with the logged-in user\u2019s privileges. The company quietly patched the flaw roughly seven months after receiving a private disclosure, shortly before researchers made the vulnerability public.<\/p>\n
Seven months after the vulnerability was initially disclosed, Cursor<\/a> has silently patched it, just before Mindgard\u2019s public disclosure of the issue.<\/p>\n Because AI coding assistants sit at the center of development workflows, weaknesses in how they launch trusted tools can expose developers during routine tasks such as cloning repositories. As these tools become more embedded in everyday developer workflows, longstanding security weaknesses such as untrusted search paths can have far greater consequences because the editor itself becomes part of the execution chain.<\/p>\n Details of the vulnerability<\/p>\n Mindgard, a cybersecurity firm, said it discovered the vulnerability last year and privately disclosed it to Cursor on Dec. 14.<\/p>\n The vulnerability stems from how Cursor handles Git files during project initialization. According to a Proof of Concept demonstration from Mindgard, as cited by Latest Hacking News<\/a>, when calc.exe (Windows Calculator app) was renamed to git.exe, instead of validating that it was launching a legitimate Git installation, Cursor executed the git.exe binary from the root of a repository.<\/p>\n Mindgard reiterated the issue at Cursor\u2019s HackerOne bug bounty program in January 2026, where the company confirmed the vulnerability. Still, nothing was done.<\/p>\n However, a report from TechTimes<\/a> said that Cursor quietly fixed the vulnerability on July 13.<\/p>\n On July 14, seven months after the initial disclosure, Mindgard published the vulnerability. The firm stressed that full disclosure had become necessary to help organizations understand and mitigate their exposure.<\/p>\n The flaw is now tracked as CVE-2026-63093<\/a> and carries a CVSS severity score of 8.8 (High). It affects Cursor for Windows version 3.2.16.<\/p>\n Must-read security coverage<\/p>\n Why this flaw matters<\/p>\n While the vulnerability itself is dangerous, what\u2019s more worrying is how simple it is to fall victim to it. According to Mindgard, the vulnerability \u201cdoes not depend on a complex chain of exploitation, prompt injection, model manipulation, jailbreaks, memory corruption, or sophisticated attacker tradecraft.\u201d<\/p>\n All a developer needed to do was open a Cursor project containing a malicious git.exe file in the repository\u2019s root directory. Because developers routinely clone repositories from various sources, the exploitation of the vulnerability fits naturally into an everyday workflow without requiring unusual user behavior.<\/p>\n Additionally, developers don\u2019t just write code; their machines often house proprietary technologies, sensitive files, credentials, and deployment secrets. Beyond the immediate compromise of a workstation, an attacker who gains access to a developer\u2019s environment could tamper with software before it reaches customers, turning a single compromised machine into the starting point for a wider software supply chain<\/a> attack.<\/p>\n That is why development platforms have become increasingly attractive targets for attackers. As AI coding tools such as Cursor take on more agentic coding tasks, longstanding security weaknesses can become far more dangerous because the IDE itself becomes a trusted component in the developer workflow.<\/p>\n For developers, the vulnerability underscores that trusted development tools deserve the same scrutiny as production software. As AI coding platforms<\/a> become more deeply integrated into software engineering workflows, weaknesses in how they interact with local tools and repositories could become increasingly valuable targets for attackers.<\/p>\n