A developer clones a repository, opens the folder in Cursor, and their machine executes arbitrary code. The mechanism is a classic implementation of CWE-426, or Untrusted Search Path. On Windows, Cursor searches the workspace root for git binaries before checking the system PATH. By placing a malicious git.exe at the root of a repository, an attacker ensures that the IDE executes their binary automatically. There is no prompt, no approval, and no warning. Because the IDE repeatedly invokes the binary to perform tasks like checking the repository status, the execution repeats on a cadence as long as the project remains open. The process runs with the privileges of the developer, effectively turning a simple git operation into a persistent execution vector. Mindgard researchers verified this using a renamed Windows Calculator binary, which Cursor executed automatically upon opening the repository.
Mindgard discovered this vulnerability on December 15, 2025, and reported it the same day. What followed was a 213-day period of silence. During this window, Cursor shipped over 197 versions of its software. The disclosure process was marked by friction: HackerOne initially closed the report as “Informative and out of scope,” only reopening it after a challenge from the researchers. Even after confirmation, the vendor went silent. No CVE was assigned, no public advisory was issued, and no version notes acknowledged the fix. The patch was eventually applied silently on July 13, 2026, as reported by Tech Times, without any formal communication from the company.
This timeline aligns with the $60 billion all-stock acquisition of Anysphere, the company behind Cursor, by SpaceX. The acquisition was announced on June 16, 2026, with an expected closing date in the third quarter of 2026. Mindgard researchers noted that full disclosure is the “nuclear option,” reserved for when every other path has failed. The fact that they reached this point suggests a breakdown in the expected responsiveness of a platform serving over 7 million active users and 50,000 companies.
Cursor is an agent-native tool that integrates deeply into the developer’s workflow. By design, these tools are intended to automate tasks, often with elevated permissions. When an IDE is configured with Workspace Trust disabled by default — as noted by Oasis Security in September 2025 — and features like tasks.json allow for execution without verification, the IDE itself becomes a supply chain breach vector. Every developer using the platform becomes a potential entry point for an attacker who can weaponize the very repositories the developer is working on.
The fix for this vulnerability is trivial: the application should use a fully qualified path, such as C:\Program Files\Git\bin\git.exe, rather than relying on PATH resolution. That this was not implemented for over 200 days, despite repeated follow-ups, highlights a disconnect between the rapid pace of AI feature deployment and the slower, more deliberate requirements of secure software engineering. The vulnerability was verified as recently as April 30, 2026, using Sysinternals process monitor logs, which showed Cursor.exe executing the malicious git.exe with the command “git rev-parse –show-toplevel.”
The community response on platforms like Hacker News, where the issue drew 453 points and 202 comments, drew direct comparisons to the legacy risks of Windows autorun.exe. The sentiment is clear: cloning a repository should not grant an IDE the authority to execute arbitrary binaries on a host machine. As AI agents become more integrated into the software development lifecycle, the security posture of the IDE becomes a critical component of the enterprise attack surface. If the tools used to build software are themselves vulnerable to trivial execution exploits, the entire supply chain is compromised.
For CISOs and security engineers, the Cursor disclosure demonstrates that AI-native tooling requires the same, if not more, scrutiny than traditional development environments. The convenience of automation cannot come at the expense of basic path security. Organizations must treat IDEs as high-risk components of their infrastructure, ensuring that default configurations prioritize security over seamless automation. Relying on vendor responsiveness during periods of rapid corporate change is insufficient; security teams must proactively audit the tools that developers use to interact with sensitive codebases.