Critical Cursor 0-day Vulnerability Enables Arbitrary Code Execution Attacks

A binary planting vulnerability in the Cursor IDE that lets a malicious git.exe file, placed at the root of a repository, run automatically the moment a developer opens that project on Windows.

The attack requires no prompt injection, no agent, no AI model in the loop, and no prior access to the victim machine. Mindgard reported the flaw to Cursor on December 15, 2025, and published full technical details on July 14, 2026, roughly seven months later.

When Cursor loads a project, it needs to locate a git binary to run introspection commands such as git rev-parse –show-toplevel. To find that binary, Cursor searches several locations, including the workspace folder itself, and on Windows the executable search order checks the current working directory before trusted system paths.

If an attacker plants a file named git.exe in the repository root and no legitimate copy exists there, Windows resolves and runs the malicious file instead, under the privileges of the logged-in user.

Cursor 0-day Vulnerability

Mindgard proved this by renaming the Windows Calculator app to git.exe and dropping it into a test repository; simply opening the folder in Cursor launched the fake binary.

Cursor initially treated the report as out of scope for its bug bounty program, citing a shared-responsibility model in which customers, not the vendor, are responsible for the repositories and external content they open.

The company later told reporters it addressed the issue on July 13, 2026, just before Mindgard’s public disclosure. However, no formal security advisory acknowledged the severity of the bug.

The issue has since been tracked as CVE-2026-63093, a binary-planting vulnerability rated CVSS 8.7 that can lead to arbitrary code execution via a malicious git.exe in the repository root.

Independent research conducted in the first quarter of 2026 found that the same auto-execution behavior is not limited to git.exe.

Cursor separately attempts to resolve and execute hatch.exe when a pyproject.toml file is present in an opened repository, following the same CreateProcess-based resolution logic as the git.exe case, with pyproject.toml simply acting as a trigger file.

Unlike more commonly monitored execution mechanisms such as tasks.json, a pyproject.toml file with a normal-looking build-system entry raises no red flags to defenders, making this a stealthier variant of the same zero-click execution surface.

Workspace Trust settings are meant to act as a security gate that blocks execution in untrusted folders, but testing on Trae IDE, which enables Workspace Trust by default, showed it still repeatedly attempts to locate git.exe inside an untrusted workspace.

This means Workspace Trust can restrict certain actions. At the same time, the underlying binary resolution behavior still creates an execution path if a malicious binary is present where the IDE searches for it.

According to Maland reports, Cursor ships with Workspace Trust disabled by default, so simply opening a folder can trigger code execution without additional clicks, prompts, or confirmation dialogs.

Security teams that filter solely on the filename “git.exe” leave a blind spot, since other attacker-controlled binaries can trigger identical zero-click execution under different conditions.

The real security boundary is not the executable’s name but the transition from untrusted project content to executable code the moment a folder is opened.

This git.exe flaw is one of several Cursor vulnerabilities disclosed in 2026, including CVE-2026-50548 and CVE-2026-50549, dubbed DuneSlide, which allowed sandbox escape and OS-level remote code execution via prompt injection and were patched in Cursor 3.0.

Separately, researchers found Cursor and Windsurf remain exposed to dozens of unpatched Chromium-based vulnerabilities inherited from outdated Electron builds, affecting an estimated 1.8 million developers.

Together, these disclosures show that AI-powered IDEs are accumulating a broad attack surface spanning binary resolution, sandbox trust boundaries, and outdated embedded components.

Developers should treat every executable file inside a project workspace as potentially executable content, not assume risk is confined to a single filename like git.exe, and exercise caution before opening repositories from unfamiliar or unverified sources.

 Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.