SURIQ
A malicious code repository can run an attacker's program on your machine the instant you open it in Cursor on Windows, with no click, no prompt, and no warning. Security firm Mindgard published the flaw on July 14, and it now carries the identifier CVE-2026-63093, rated 8.7 out of 10. At the time of writing there is no patch and no vendor advisory.
Cursor is a widely used code editor built on the same engine as Visual Studio Code, aimed at developers who pair it with an AI assistant. That reach is the point. An editor whose whole job is opening other people's code is a natural target for an attack that hides inside a repository.
How opening a repo runs code
When Cursor loads a project on Windows, it looks for a Git program to run in the background. According to Mindgard, one of the places it searches is the project folder itself. An attacker who commits a file named git.exe to the root of a repository gets Cursor to find and run that file in place of the real Git, as part of the editor's normal startup. The program runs with the signed-in user's privileges.
Two details make it worse. The execution needs no interaction, so cloning and opening the repository is enough to trigger it. And it repeats: Mindgard reports Cursor re-runs the resolved Git program on a recurring timer, not only once at launch. In their proof of concept, Mindgard used a harmless stand-in rather than real malware. They took the built-in Windows calculator app, gave it the file name git.exe, and committed it to a test project. Pointing Cursor at that project was enough to make the calculator pop open.
What the CVE says, and what is still unconfirmed
The vulnerability was assigned CVE-2026-63093 by VulnCheck, which lists Anysphere's Cursor for Windows version 3.2.16 as affected and scores it 8.7 on one scale and 8.8 on another. Mindgard says it reported the issue to Cursor on December 15, 2025 and followed up over the next six months before going public. The researchers' last confirmed-vulnerable test was version 3.2.16, run on April 30; later releases were not tested, so whether a more recent build quietly changed the behavior is unverified.
Cursor's maker, Anysphere, responded on its community forum rather than through a security advisory. As reported by The Hacker News, the company said findings that need a malicious file already sitting in the workspace generally fall outside the scope of its bug-bounty program, while acknowledging a process failure in not closing out communication with the researcher sooner. No fix has been published as of this writing.
What to do before you open another repository
- Treat unfamiliar repositories as hostile. Open code you did not write inside a disposable virtual machine or Windows Sandbox, not on your daily workstation.
- Inspect a checkout before opening it. Look at the repository root for executable files that have no business in source code, especially ones named after developer tools: git.exe, node.exe, npx.exe, where.exe.
- Block execution from project folders. If you run Windows AppLocker or App Control, add deny rules for executables under the directories where you clone repositories, so a planted binary cannot run there at all.
- Turn on Workspace Trust where your editor offers it, with the caveat that Mindgard could not confirm it stops the Git probe in every case.
How to hunt for it on hosts you monitor
This is a binary-planting attack: a malicious file borrows the name of a trusted tool and runs from the wrong place. The signal is the same whichever editor is involved. On any Windows host you collect logs from, watch process-creation events (Windows event 4688 or Sysmon event 1) for a developer tool such as git.exe launching from a user's project, Downloads, or temp directory instead of its normal install path under Program Files. File integrity monitoring adds a second angle, because an executable appearing inside a source-code checkout is worth an alert on its own.
If Suriq monitors the host, the process-creation and file-integrity telemetry it already collects is where this pattern shows up, so detecting it is a rule to write, not a new sensor to deploy. Response stays yours to approve. The value here is simply seeing a trusted tool name run from a place it never should.