Article: Cursor’s code-editing tool still runs a malicious git.exe file placed in a project folder, a critical zero-day that has gone unpatched for seven months. The bug lets any executable masquerading as Git run automatically with the user’s privileges, exposing developers to remote code execution without a click or warning.

The flaw was discovered by security researcher Mindgard on 15 December 2025, reported the same day, and remains present in the July 2026 release despite more than 197 incremental updates and a $60 billion company valuation.

How the bug works

Cursor scans a project’s directory for Git binaries in several locations, including the repository root. When it finds a file named git.exe, it launches the program to provide version-control features. The launch occurs silently, with no UI prompt, and inherits the current user’s permissions.

An attacker who can add a file to the repository can replace the expected Git binary with any executable. Mindgard demonstrated the effect by renaming Windows Calculator to git.exe, dropping it in a repo, and opening the folder in Cursor. Calculator windows popped up repeatedly as long as the project stayed open—an illustration of how real malware could execute in the same manner.

Timeline of the disclosure

  • 15 Dec 2025 – Mindgard emails Cursor’s security address with a full report.
  • 15 Jan 2026 – Cursor’s chief information security officer (CISO) replies, a month later.
  • 16 Jan 2026 – HackerOne, the bug-bounty platform used by Cursor, classifies the report as out of scope.
  • 16 Jan 2026 – Mindgard provides a proof-of-concept, prompting HackerOne to reopen the ticket.
  • 20 Jan 2026 – HackerOne confirms that Cursor has formally received the report.

After 20 January, follow-up messages from Mindgard received no response. Cursor kept shipping new features and raising additional funding, but the vulnerability stayed in the codebase.

Why the delay is troubling

The issue is a classic supply-chain risk: any contributor who can push a file to a shared repository can inject malicious code that runs on every developer’s machine.

Mitigation steps you can take now

Enterprise Windows environments

  • Deploy AppLocker or Windows App Control policies that block any executable named git.exe from launching inside workspace directories.
  • Skip hash-based allowlists; attackers can simply change the file’s hash while keeping the name.

Individual developers

  • Open repositories from untrusted sources only inside a virtual machine or Windows Sandbox.
  • Don’t rely on file-hash blocklists; they give a false sense of security.

General best practice

  • Treat every new repository as a potential supply-chain vector. Verify the provenance of all binaries before they are executed.

The episode underscores a broader lesson: AI-driven development tools require deep system access, and that access must be guarded with the same rigor as any other privileged software. When a high-impact vulnerability lingers for months at a multi-billion-dollar firm, developers have a clear signal to reassess the trust they place in the platform.