Cursor 0-Day Lets Attackers Execute Malicious Code by Opening a Repository

A recently disclosed security issue in Cursor IDE exposed a serious Windows binary-planting vulnerability that could allow malicious code to execute simply by opening an untrusted repository.

This flaw, tracked as CVE-2026-63093, relates to Cursor’s executable resolution behavior and demonstrates how files controlled by attackers placed in a workspace could be executed with the current user’s privileges.

Cursor 0-Day

AI security firm Mindgard initially reported the issue to Cursor on December 15, 2025, and publicly disclosed the technical details on July 14, 2026.

The original proof of concept involved planting a malicious `git.exe` in the root of a repository. When Cursor opened the workspace, it executed Git-related commands, including `git rev-parse –show-toplevel`.

On Windows, the executable search behavior can prioritize the current working directory. Therefore, if Cursor invokes `git.exe` without a fully qualified trusted path, a rogue executable located in the opened repository may be found before the legitimate Git binary installed on the system. This results in code execution within the security context of the developer opening the project.

Further testing indicated that the vulnerability is not limited to `git.exe`. Under specific conditions, Cursor may also attempt to execute `hatch.exe` if it detects a Python project configuration file, such as `pyproject.toml`, in the open folder.

A malicious repository could include two seemingly simple files:

malicious-repository/
├── hatch.exe
└── pyproject.toml

In this case, the `pyproject.toml` file acts as a trigger rather than an overt payload. A basic build system declaration referencing Hatch tooling could prompt Cursor to look for `hatch.exe`.

If the application uses an unsafe executable lookup process, a malicious `hatch.exe` in the workspace could be executed automatically.

This is particularly concerning because the repository might not contain familiar high-risk artifacts such as malicious VS Code tasks, startup scripts, or suspicious shell commands.

According to Screetsec, the project configuration can appear legitimate while the executable is disguised as a normal utility related to dependencies.

Workspace Trust is often presented as a safety measure against untrusted code and project settings. However, research into Cursor and Trae IDE revealed that trust controls may not fully address the issue of executable discovery behavior.

In Trae, Workspace Trust is enabled by default, requiring users to select a trusted folder before some workspace-driven execution paths become active.

In contrast, Cursor reportedly had Workspace Trust disabled by default, making the demonstrated behavior resemble a zero-click scenario: simply opening the repository could trigger execution.

The key issue is not whether the workspace is marked as trusted, but rather whether the IDE searches attacker-controlled directories for executables and launches them without explicit user approval.

Defenders should avoid monitoring only for `git.exe` spawned by Cursor, as this approach can overlook alternative execution paths involving Python, package management, build tools, or language-specific utilities.

Security teams should monitor process creation where IDE processes launch executables from repository roots, downloads folders, temporary directories, or other nonstandard paths. Developers should also inspect repositories for unexpected binaries before opening them, especially files named after common developer tools.

Cursor has reportedly addressed the known file-handling and executable-discovery vulnerabilities in later releases. Nonetheless, this research highlights a broader lesson for IDE vendors: project content should be treated as potentially executable, rather than merely passive source code.

Prevent incidents due to slow investigations. Power your Tier 1 with threat intelligence from 15K SOCs: Integrate TI Lookup in your SOC