Cursor 0day: When Full Disclosure Becomes the Only Protection Left (mindgard.ai)

Article summary

A vulnerability in the Cursor development environment allows for arbitrary code execution when a malicious git.exe is present in the repository root. The issue was first reported to Cursor in December 2025, but remains unfixed despite multiple follow-ups. The vulnerability can be exploited by opening a project containing a malicious git.exe, with no user interaction or prompts required. This has raised concerns about the security practices of Cursor, a widely-used AI-assisted development environment.

Main themes

• Cursor vulnerability
• Arbitrary code execution
• Windows default behavior
• AI-assisted workflows
• Vulnerability disclosure
• Security practices
• User safety
• Transparency and accountability

What commenters say

• The vulnerability is a result of Windows' default behavior of searching for executables in the current directory before searching in the PATH.
• The exploit requires a malicious payload to be present on the system, which may not be the case in all scenarios.
• The issue is not unique to Cursor and can be exploited in other situations where a shell is used to run commands.
• The lack of response from Cursor is more concerning than the vulnerability itself, as it indicates a potential lack of prioritization of user safety.
• The use of AI-assisted workflows can lead to vulnerabilities due to the complexity and automation of these systems.
• The exploit can be triggered simply by opening a project in Cursor, without requiring any further user interaction.
• The vulnerability can be mitigated by using AppLocker or Windows App Control policies to deny execution of the affected executable.
• The incident highlights the need for transparency and accountability in vulnerability disclosure and remediation.