# Cursor 0-Day CVE-2026-63093 Exposes Windows Users to Silent Code Execution > Source: > Published: 2026-08-19 14:46:30+00:00 Security researchers have pulled back the curtain on a dangerous flaw in Cursor IDE that turns a routine action, opening a code repository, into a potential gateway for attackers. The vulnerability, now formally tracked as [CVE-2026-63093](https://www.kobaran.com/tag/CVE-2026-63093), shows how something as simple as browsing a folder in a popular AI-powered coding tool could hand control of a developer’s machine to a malicious actor. What makes this disclosure particularly alarming is the lack of user interaction required. Unlike phishing attacks or malicious downloads that typically demand a click, a download, or an approval prompt, CVE-2026-63093 can trigger just by launching Cursor against an untrusted workspace. For software development teams, security researchers, and IT administrators who rely on modern IDEs daily, this represents a meaningful shift in how workspace trust and executable handling need to be evaluated. The timing of this disclosure adds urgency. As AI-assisted coding tools like Cursor continue gaining ground among developers for their speed and productivity gains, vulnerabilities baked into their core file-handling logic carry outsized risk. CVE-2026-63093 is a reminder that convenience-driven tools still need to meet baseline security expectations, especially when they interact directly with untrusted, externally sourced code. ### What Is CVE-2026-63093 CVE-2026-63093 is a Windows binary-planting vulnerability rooted in how Cursor resolves and executes external binaries when a workspace is opened. Rather than exploiting a bug in application logic or memory handling, the flaw abuses a well-known weakness in how Windows searches for executables, allowing attacker-controlled files to be executed under the privileges of whoever opened the project. #### How the Vulnerability Was Discovered AI security firm Mindgard first flagged the issue to Cursor’s developers on December 15, 2025. Following a standard responsible disclosure period, the technical details were made public on July 14, 2026. That gap gave the Cursor team roughly seven months to investigate and patch the underlying behavior before researchers went public with a full breakdown. The original proof of concept centered on a deceptively simple trick: planting a fake `git.exe` file in the root directory of a repository. When a developer opened that repository in Cursor, the IDE automatically executed Git-related commands in the background, including a routine call to `git rev-parse --show-toplevel` . On Windows systems, the executable search order can prioritize the current working directory over trusted system paths. If Cursor calls `git.exe` without specifying a fully qualified, trusted file path, the operating system may locate and run the attacker’s planted file before ever reaching the legitimate Git binary installed elsewhere on the machine. #### Beyond Git: A Broader Pattern of Risk Follow-up testing by researchers found the vulnerability was not confined to Git. Cursor was also observed attempting to launch `hatch.exe` , a Python build tool, whenever it detected a `pyproject.toml` configuration file in an opened folder. This means a malicious repository could be built from just two innocuous-looking files. | File | Role in the Attack | |---|---| `pyproject.toml` | Acts as a trigger; a basic build declaration referencing Hatch tooling prompts Cursor to search for `hatch.exe` | `hatch.exe` | The malicious payload disguised as a legitimate Python packaging utility | Security researcher Screetsec noted that the project configuration file can look entirely legitimate to a developer, while the accompanying executable is quietly disguised as a normal dependency management tool. Because the repository lacks the usual red flags, such as suspicious VS Code tasks, startup scripts, or unusual shell commands, the attack can slip past both automated scanning and casual manual review. ### Why Workspace Trust Didn’t Stop the Attack #### Cursor vs. Trae IDE Modern code editors typically include a “Workspace Trust” feature designed to isolate untrusted projects and limit what code can execute automatically. Researchers compared Cursor’s implementation against Trae IDE and found a critical difference in default configuration. Trae enables Workspace Trust by default, meaning users must actively designate a folder as trusted before certain execution paths become active. Cursor, by contrast, reportedly shipped with Workspace Trust disabled by default. That single configuration choice effectively turned the vulnerability into a zero-click scenario, since simply opening a repository was enough to trigger unwanted code execution, with no trust prompt standing in the way. #### The Real Problem: Executable Discovery, Not Trust Settings Researchers were careful to point out that toggling Workspace Trust on would not have fully resolved the issue on its own. The core weakness lies in how the IDE searches for and launches executables in the first place. An application that scans attacker-controlled directories for binaries, and runs whatever it finds there without explicit user approval, remains risky regardless of whether a workspace is technically marked as trusted. ### Guidance for Security Teams and Developers #### Detection Recommendations Defenders monitoring only for `git.exe` processes spawned by Cursor risk missing the bigger picture. Because the flaw can manifest through Python tooling, package managers, build systems, and potentially other language-specific utilities, detection strategies need to be broader in scope. Security teams should watch for: - IDE processes launching executables from repository root directories - Unexpected binaries executing from downloads folders or temporary directories - Process creation events tied to nonstandard file paths within opened projects #### Practical Steps Before Opening Untrusted Repositories Developers handling code from external or unverified sources can reduce their exposure with a few precautionary habits: - Inspect repository contents for unfamiliar `.exe` files before opening them in an IDE - Pay particular attention to executables named after common developer tools, since these are the easiest to overlook - Confirm that Workspace Trust settings are enabled and properly configured - Keep Cursor updated to the latest available release ### Current Status of the Fix According to available reporting, Cursor has addressed the specific file-handling and executable-discovery behaviors identified during this research in more recent software releases. Developers running outdated versions remain the most exposed and should prioritize updating. The broader takeaway for IDE vendors extends well past this single case. Researchers emphasized that project source code, including configuration files that appear routine, should be treated as potentially executable content rather than passive text. As AI-integrated development tools proliferate, this incident is likely to influence how other vendors approach executable resolution and workspace isolation going forward.