Just opening a repo in Cursor can hijack a Windows PC: CVE-2026-63093, and there's still no official fix

A flaw in the Windows version of the popular coding tool Cursor can let attackers take over a computer the moment a user opens someone else's project (a "repository"). It has been assigned CVE-2026-63093, with a severity of 8.8 on the 10-point CVSS scale (higher is worse). The scary part: there is no click, no confirmation dialog, and no warning — the attacker's planted program runs the instant the repository is opened.

Cursor is an "AI code editor" where you describe what you want in plain language and the AI writes or fixes the code for you. It is used by more than 7 million people worldwide. Copying (cloning) code that others have published and opening it is an everyday habit for developers — and that "open" action is exactly the trigger here.

What makes this worse is that, as of this writing, there is no published fixed version number and no formal security advisory. The vendor takes the position that this falls within the "user's responsibility," so "just update and you're done" does not apply. Below we walk through what is happening, how much it affects you, and what to do right now.

What is Cursor?

Cursor is a programming tool developed by the U.S. company Anysphere. It looks and feels much like Microsoft's popular editor Visual Studio Code, but with AI built deep into it: ask it to "add this feature" or "fix this bug" and the AI rewrites the code for you. That convenience drove rapid adoption, and it is now one of the go-to tools for developers who write code with AI.

A very common developer task is to copy someone else's published code onto your own machine and look through it. The bundle of code is a "repository," and copying it is "cloning." Sites like GitHub host countless repositories, and cloning an interesting one and opening it in Cursor is completely routine. This flaw fires on exactly that "clone and open" step.

The flaw was reported by Mindgard, a UK company specializing in AI security. The lead researcher, Aaron Portnoy, is a veteran known for launching the "Pwn2Own" hacking contest and running the "Zero Day Initiative." His warning: this is "simple but high-impact and easy to exploit — if attackers have a target, they will definitely operationalize it."

What happens — swapping out "git.exe"

When Cursor opens a repository, it calls a background tool called "git." Git is the standard tool for tracking code changes, and many development apps use it internally. The problem is that one of the places Cursor searched for the git program (on Windows, a file named git.exe) was the very folder of the repository being opened.

So if an attacker places a malicious git.exe disguised as the real thing at the top level of a repository, then the moment a victim opens that repository in Cursor, Cursor mistakes the fake for the "real git" and runs it. There is no click, no confirmation, and no warning. Worse, while the repository stays open, Cursor keeps invoking the fake again and again.

To demonstrate the risk safely, Mindgard used the Windows Calculator instead of real malware: they renamed it to git.exe and placed it in the repository. Opening that repository in Cursor launched the calculator unprompted, and leaving it open spawned more calculator windows over time. Picture that calculator as actual malware and the danger of this behavior becomes clear.

Who targets this, and why

The people who exploit this are attackers who publish attractive-looking code online and get developers to clone it. For example, they might post a repository on GitHub claiming "I built a handy tool" or "please try this sample," with a fake git.exe tucked into the top level. Sending a repo disguised as a job-application test or coding challenge is another plausible route.

When the targeted developer opens that repository in Cursor, the attacker's program starts running on the PC without the developer noticing. It runs with that developer's own privileges, so the attacker effectively gains a foothold to do whatever the victim can do on the machine.

The potential damage is not small. A developer's PC holds keys for logging into other servers (SSH keys), tokens for connecting to cloud services, employer source code, and access to systems that automatically build and ship software (CI). From there, the damage can spread to the employer's systems and even to products that developer helps ship. This "use a developer as a stepping stone to reach the organization and its users" pattern mirrors attacks that abuse open-source components, which we also cover in our guide to the risks hidden in open-source components.

A technical look — why the fake gets executed

Technically, this is classified as an "Untrusted Search Path" (CWE-426). When a program launches another program, it decides which folders to search for the executable — and here, a folder that should never be trusted (the untrusted working folder) was mixed into that search order.

On Windows, when you start a program by name alone, the system searches several predefined folders in order and runs the first executable it finds. Cursor included "the top level of the currently open repository" in that search path when invoking git. As a result, a git.exe placed inside the repository is found before the real, properly installed git, and gets run. All the attack requires is naming the file exactly git.exe and putting it at the repository's top level — no complex steps and no extra action from the user.

The same "get them to open malicious code and run it" pattern has surfaced in other dev tools. In the editor "Zed," for example, a set of flaws was disclosed where opening a malicious repository runs arbitrary programs (the Zed vulnerability roundup). Editors that reach out to external programs "just from opening" a project trade convenience for an easy entry point for attackers.

From report to disclosure

It took seven months from report to disclosure. Mindgard says that "because the vendor would not act, full disclosure was the only way for users to protect themselves." Here is the main timeline.

← swipe to move

Is it "already fixed"? Opinions differ

What readers most want to know is simple: is it fixed? On that exact question, the vendor and the researcher disagree. Rather than assert a conclusion, here is what is confirmed versus what remains unclear.

In short, Cursor treats the risk as limited: "Windows only, and only when opening a repo that already contains a malicious executable named exactly git.exe at the project root." Mindgard counters that those conditions are trivially met, and that since it runs without warning on open, the real-world impact is significant. Either way, with no official fixed version published, users should not assume "updating makes it safe" and should take the defenses below.

Am I affected? (Quick reference)

How much this concerns you depends heavily on your OS and on "what kind of code you open." Use the table below to find where you fall.

To be clear, the target group is "people who use Cursor on Windows and open code from untrusted parties." If you only handle code written by you or your employer, sudden compromise is unlikely. But if you casually try out tools you find on GitHub, you are exactly in the line of fire.

What to do right now

With no official fixed version published, the practical answer boils down to "don't carelessly open risky code." Do not open untrusted repositories, unfamiliar job-application tests or coding challenges, or tools of unknown origin directly in Cursor. If you must inspect the contents, first look at the top level of the repository and check for executables that have no business being at a project root — such as git.exe, node.exe, or npx.exe.

A more reliable approach is to open unknown code in a "disposable, isolated environment." Opening it inside Windows Sandbox (built into Windows) or a virtual machine (a throwaway copy of Windows separate from your real system) keeps any malicious program contained even if it runs. If your organization manages machines centrally, consider using tools like AppLocker to deny git.exe from executing out of working folders.

Cursor itself points to a feature called Workspace Trust as mitigation. It lets you mark an opened folder as trusted or untrusted, and holds back automatic actions in untrusted folders. However, Mindgard says it could not fully verify that this feature reliably blocks this technique, so do not over-rely on it. Enable it, but pair it with the "don't open carelessly" habit above.

As of now, there are no reports of this flaw being used in real attacks, and it is not listed on the U.S. CISA catalog of "vulnerabilities known to be actively exploited" (KEV). The only public demonstration is the researchers' harmless calculator test. Still, because the technique is simple and easy to copy, it is best to act before it gets weaponized. You can check whether attacks have started in our tracker of actively exploited vulnerabilities (Japanese).

FAQ

Summary

The Windows version of Cursor, the AI code editor used by over 7 million people, has a flaw (CVE-2026-63093, severity 8.8) that can let someone take over your PC just by opening their code. The mechanism: the "git" that Cursor calls in the background can be swapped for a fake placed inside the repository. It runs with no click and no warning, and what gets stolen — a developer's keys and source code — tends to spread damage outward.

The tricky part is that no official fixed version or advisory has been published, and the vendor treats this as within the "user's responsibility." That is exactly why, for now, the realistic defenses are to "not carelessly open untrusted code," "open it in an isolated environment," and "enable Workspace Trust." We will update this article as an official fix is announced and as we learn whether real-world attacks occur.

Sources

• ▸ NVD - CVE-2026-63093 (Cursor for Windows, untrusted search path)
• ▸ Mindgard - Cursor 0day: When Full Disclosure Becomes the Only Protection Left (the discoverer's writeup)
• ▸ The Hacker News - Cursor Flaw Lets Malicious Cloned Repositories Trigger Windows Code Execution
• ▸ Dark Reading - Cursor IDE Auto-Executes Malicious Code in Poisoned Repos
• ▸ Cursor Community Forum - Addressing the recent Mindgard report (vendor's official position)
• ▸ Hacker News - community discussion
• ▸ Cursor official site