Cursor 0day: When Full Disclosure Becomes the Only Protection Left

TL;DR Highlight

A git.exe planted in a repo root runs in Cursor on Windows without warning; unpatched for seven months.

Who Should Read

Developers who open outside repositories in Cursor on Windows, and teams responsible for dev-environment security.

Core Mechanics

Cursor runs git.exe from the repo root
- On Windows, Cursor looks for git binaries in several locations after loading a project.
- One of those locations is the workspace itself, so a malicious git.exe in the root runs with no click or prompt.
- The result is arbitrary code execution as the current user.
It keeps re-executing while the project is open
- The proof of concept was Calculator renamed to git.exe.
- More Calculator windows kept appearing while the project stayed open.
- Process Monitor logged it as launched with git rev-parse --show-toplevel.
No prompt injection needed
- No exploit chain, jailbreak, or memory corruption is required.
- Opening a project that contains git.exe is enough, per the post.
- Last verified April 30, 2026 against Cursor 3.2.16 on Windows.
Seven months without a fix or reply
- Found and reported December 15, 2025.

Community Reactions

Opinion that Workspace Trust is the deeper issue
- One comment says Cursor ships with Workspace Trust disabled by default.
- It notes that .vscode/tasks.json with runOn: folderOpen already runs arbitrary code.
Opinion that this is a Windows quirk, not just Cursor
- Several comments note Windows searches the current directory before PATH.
- They compare it to why Unix PATH omits ".", and say agents should be no different.
- Some still say Cursor should show a trust-this-directory dialog.
Pushback that severity is overstated
- Some argue the attacker must already have placed an exe in your folder, meaning you are already compromised.
- Another comment says npm install on an untrusted repo is just as dangerous.
- Others worry about supply-chain risk since people let coding agents pull and push from git.
Reports of failed reproduction and complaints about the writing
- One commenter copied Calculator to git.exe in several repos and saw nothing execute.

How to Apply

Check your repo roots for a stray git.exe
- Today, search your Windows dev work folders for git.exe.
- Example: Get-ChildItem -Path $env:USERPROFILE\source -Recurse -Filter git.exe
- Delete or quarantine any hit that lives inside a repository.
Open outside repos only in a sandbox
- Open repos of unknown origin in Windows Sandbox or a VM when using Cursor.
- Write this rule into your team onboarding doc until a patch ships.
Add path-based execution deny rules on managed PCs
- In AppLocker or Windows App Control, deny execution of git.exe under repo root paths (e.g. %USERPROFILE%\source\repos\*\git.exe).
- Do not use hash-based rules.
Verify Workspace Trust settings yourself
- Check in Cursor settings whether Workspace Trust is enabled.
- If off, turn it on and ship it as a team standard setting.

Try It

copy & run

# Paste into Windows PowerShell: find suspicious git.exe files in your work folders (read-only, deletes nothing)

$root = "{{your work folder, e.g. $env:USERPROFILE\source\repos}}"

Get-ChildItem -Path $root -Recurse -Filter git.exe -ErrorAction SilentlyContinue |
  Select-Object FullName, Length, LastWriteTime

# Next: if a hit is not under the official Git install path (e.g. C:\Program Files\Git), quarantine it and add that folder to an AppLocker path rule

Terminology

0dayA vulnerability the vendor has not patched yet. Defenders have zero days to prepare.

Full DisclosurePublishing the details when a vendor is unresponsive so users can protect themselves.

Coordinated DisclosureTelling the vendor first and giving time to patch before going public. It needs two-way communication.

Workspace TrustA VS Code-family feature that asks whether you trust a newly opened folder and limits code execution until you do.

AppLockerA Windows policy tool that allows or blocks executables by path or signature.