Cursor's 'git.exe' Blind Spot: Silent RCE via Malicious Repositories

The recent report regarding Cursor automatically executing a git.exe binary found in the repository root on Windows represents a significant failure in supply chain security. It is bad enough that it executes without user interaction, but the fact that it loops continuously makes it a nightmare for containment. Effectively, cloning a repo becomes an immediate code execution attack vector, granting attackers access to source code, SSH keys, and cloud tokens.

Since there isn't a CVE assigned yet, manual detection is critical for defensive teams. You can scan your development environments for potentially malicious binaries using this PowerShell script. It looks for git.exe instances residing outside of standard installation or .git internal directories:

$scanPaths = @("C:\Dev", "C:\Source", "$env:USERPROFILE\Documents")
Get-ChildItem -Path $scanPaths -Recurse -Filter "git.exe" -ErrorAction SilentlyContinue | 
    Where-Object { 
        $_.FullName -notmatch '\\.git\\' -and 
        $_.FullName -notmatch 'Git\\cmd' -and 
        $_.FullName -notmatch 'mingw64\\bin' 
    } | 
    Select-Object FullName, Length, LastWriteTime | Format-Table -AutoSize

The lack of a sandbox or simple warning dialog here is inexcusable for a modern editor. Cursor keeps re-running the binary, meaning any payload maintains persistence without needing a separate scheduled task or registry modification. Until Cursor patches this behavior, we must treat any unvetted repo as hostile malware.

How are you handling IDE trust policies in your organization? Are you reverting to standard VS Code, or have you found a way to lock down Cursor’s execution environment?