Cursor startet git.exe aus dem Repo-Root
Mindgard beschreibt einen simplen, schweren Fehler in Cursor auf Windows: Liegt im Projektroot eine Datei namens git.exe, startet die IDE sie beim Öffnen des Repos ohne Prompt und ohne Warnung, mit den Rechten des Entwicklers. Disclosure seit Dezember 2025, öffentliche Full Disclosure am 14. Juli 2026, laut Research weiter unpatched.
Das Wichtigste in Kürze
- Kein Klick nötig. Repo öffnen reicht, wenn git.exe im Root liegt.
- Monate ohne Fix. Report 15.12.2025, Full Disclosure 14.07.2026, 197+ Versionen später laut Mindgard noch vorhanden.
- Shadow-IT-Risiko. AI-IDEs gehören in die Software-BOM und ins Allowlisting.
- Mitigation jetzt. AppLocker/App Control gegen Workspace-Executables; untrusted Repos nur in Sandbox oder VM.
Verwandt:TrapDoor Supply-Chain auf npm/PyPI / Source-Code-Leaks und Patch-Umgehung
Der Bug in einem Absatz
Was ist der Cursor-git.exe-Bug? Beim Laden eines Projekts sucht Cursor Git-Binaries an mehreren Orten, inklusive Workspace. Ein im Repository-Root abgelegtes git.exe wird als Teil der Pfadauflösung ausgeführt. Process-Monitor-Traces zeigen Cursor.exe beim Start von git rev-parse –show-toplevel mit dem Workspace-Binary. Der PoC von Mindgard nutzt Windows-Rechner mit umbenannter calc.exe als git.exe. Calculator startet und respawnt im Betrieb.
Definition · Binary Planting in der IDE
Die IDE sucht Tool-Binaries auch im Workspace. Ein vergiftetes Repo liefert git.exe im Root. Beim Öffnen startet die IDE den Angreifer-Code im User-Kontext des Entwicklers.
Kein Prompt-Injection, kein Model-Jailbreak. Binary Planting im Workspace. Für Angreifer reicht ein vergiftetes Repo: clone, mit Cursor öffnen, Code läuft im User-Kontext des Entwicklers. Oft mit Zugriff auf Tokens, SSH-Keys und interne Packages.
Timeline und Vendor-Schweigen
Mindgard meldete am 15. Dezember 2025 an security-reports@cursor.com. Über HackerOne und den CISO-Kanal kam es zu Bestätigung und Repro, danach laut Research lange Funkstille. Am 14. Juli 2026 folgte die Full Disclosure, weil koordinierte Remediation ausblieb. Stand der Research-Publikation: kein Patch, kein öffentliches Advisory des Vendors.
Für CISOs ist das der zweite Befund neben dem Bug: Vendor-SLA und Disclosure-Hygiene gehören in die Bewertung von AI-Coding-Tools. Produktivität allein ist kein Trust-Argument. Cursor ist Shadow-IT in vielen Engineering-Organs. Der Fix-Horizont ist unbekannt.
Was Unternehmen bis zum Fix tun
Bis ein Vendor-Fix greift, bleibt die Maßnahme operational: Inventar der Cursor-Nutzer auf Windows, Policy für untrusted Repos und Endpoint-Controls gegen Workspace-Executables. Die Checkliste unten ist der Mindeststandard für CISOs und Engineering-Leads.
Cursor auf Windows absichern
- ✓Inventar: Welche Teams nutzen Cursor auf Windows (Lizenz, MDM, Downloads)?
- ✓Policy: Untrusted Repos nicht in der produktiven IDE öffnen, nur VM oder Sandbox
- ✓App Control: Ausführung von Executables aus Entwickler-Workspace-Pfaden verweigern
- ✓EDR: Alert wenn Cursor.exe unerwartete Child-Prozesse aus Repo-Pfaden startet
- ✓Software-BOM: AI-IDEs wie jedes Build-Tool mit Owner, Version und Exit-Kriterium
AppLocker oder WDAC sollten pfadbasiert greifen, nicht hashbasiert. Angreifer wechseln den Hash. Generisch keine Executables aus Workspace-Roots zulassen, statt nur git.exe zu blocken. Binary Planting ist ein bekanntes Muster über mehrere AI-IDEs. Wer nur „kein CVE im Scanner“ verlangt, sieht das Risiko nicht. Primärquelle: Mindgard-Blog vom 14.07.2026; Cross-Checks u. a. Dark Reading und The Hacker News.
Häufige Fragen
Jede Frage ist verschlossen. Ein Tippen entriegelt die Antwort.
Betrifft das macOS und Linux?
Die beschriebene Ausnutzung zielt auf Windows und git.exe im Repo-Root. Andere Plattformen separat bewerten. Windows-Devs sind der klare Hotspot.
Reicht es, git.exe zu blocken?
Es ist der aktuelle Trigger. Path-Resolution kann weitere Tool-Namen prüfen. Besser: generisch keine Executables aus Workspace-Roots zulassen.
Ist das dasselbe wie CVE-2026-26268 (Git-Hooks)?
Nein. 26268 betrifft laut Berichten versteckte Git-Hooks. Der Mindgard-Fall ist Binary Planting von git.exe im Root. Anderer Mechanismus, gleiches Outcome: Code Execution.
Was fordern wir vom Vendor?
Patch, Advisory, klare Search-Path-Policy ohne Workspace-Exec sowie nachvollziehbare SLA für Criticals im Bug-Bounty.
Primärquelle?
Mindgard Blog „Cursor 0day: When Full Disclosure Becomes the Only Protection Left“ (14.07.2026).
Lesetipps der Redaktion
LesetippSharePoint-JWT-Bypass öffnet On-Prem-SitesLesetippBitLocker-Bypass bei physischem ZugriffLesetippNihon Kotsu: Dispatch fällt nach Malware
Mehr aus dem MBF Media Netzwerk
cloudmagazinAWS Sovereign Cloud: was wirklich getrennt istMyBusinessFutureDigitaler Produktpass: Was Hersteller tun müssenDigital ChiefsToken-OPEX: Inference steuert, nicht das Seat-Budget
Bildquelle: KI-generiert (Juli 2026)
