Cursor auf Windows führt git.exe aus Projektordner ohne Warnung aus

Der von Mindgard beschriebene Mechanismus ist einfach: Cursor sucht beim Laden eines Projekts an mehreren Stellen nach einer Git-Binärdatei, darunter im Arbeitsverzeichnis selbst. In der technischen Analyse zeigt eine Process-Monitor-Aufzeichnung laut Mindgard, dass Cursor.exe die Binärdatei im Repository-Stamm mit der Befehlszeile „git rev-parse –show-toplevel“ startet. Das entspricht der Repository-Prüfung, die auch Microsoft in der Dokumentation zu VS Code beschreibt. Ob Cursor diese Pfade selbst durchsucht oder Windows ein unqualifiziertes „git“ übergibt und damit die Suchreihenfolge des Systems nutzt, lässt die Veröffentlichung offen.

Der von Mindgard gezeigte Proof of Concept bestand aus dem Windows-Rechnerprogramm, umbenannt in „git.exe“ und im Projektstamm abgelegt. Danach reichten Klonen und Öffnen des Repositories aus. Ein Screenshot in der Analyse zeigt, wie sich die Rechnerfenster selbstständig weiter öffnen, während das Projekt geöffnet bleibt.

Mindgard betont, dass die vermeintliche Voraussetzung — eine Angreifer-Binärdatei im Stammverzeichnis des Projekts — in der Praxis gerade kein hoher Aufwand sei. Das Klonen fremder Repositories sei genau der Weg, über den solche Dateien überhaupt auf dem Datenträger landen. Der Fehler überbrücke damit die Distanz zwischen einem beliebig veröffentlichten Repository und Codeausführung im Kontext des angemeldeten Nutzers.

Einen wichtigen Vorbehalt gibt es bei der Versionslage. Die jüngste datierte Bestätigung von Mindgard stammt vom 30. April 2026 für Cursor 3.2.16. Die aktuelle Version ist 3.11 und wurde am 10. Juli ausgeliefert. Die Analyse erklärt zwar, die Schwachstelle bestehe auch in der neuesten getesteten Version fort, nennt diese Version aber nicht. The Hacker News sichtete nach eigenen Angaben alle 33 von Cursor veröffentlichten Security Advisories und fand bis zum 15. Juli keinen Eintrag zu dem Problem. Eine CVE-Nummer gibt es nicht.

Da kein Patch verfügbar ist, bleiben nur Umgehungsmaßnahmen. Für verwaltete Windows-Umgebungen empfiehlt Mindgard AppLocker oder Windows App Control mit Sperrregeln nach Dateiname und Pfad unterhalb von Workspace-Wurzeln, etwa nach dem Muster „%USERPROFILE%\source\repos*\filename.exe“. Pfadregeln seien sinnvoller als Hashes, weil Angreifer-Binärdateien ihren Hash ändern können. Eine allgemeine eingebaute Windows-Regel, die einen Kindprozess nur dann blockiert, wenn ihn ein bestimmter Elternprozess startet, gebe es nicht; eine solche Durchsetzung erfordere in der Regel EDR. Andere Nutzer sollten nicht vertrauenswürdige Repositories in einer Wegwerf-VM oder in Windows Sandbox öffnen.

Ergänzend verweist der Bericht auf Empfehlungen von Cymulate, ein geklontes Repository oder ein entpacktes Archiv vor dem Öffnen zu prüfen. Dateien wie „git.exe“, „npx.exe“, „node.exe“ und „where.exe“ gehörten nicht in den Projektstamm.

Der Fall wirft auch Fragen zum Umgang mit Meldungen auf. Auf der Security-Seite von Cursor heißt es, das Unternehmen bestätige „Schwachstellenmeldungen innerhalb von fünf Geschäftstagen“. Laut Mindgard kam die erste inhaltliche Antwort erst einen Monat nach der Dezember-Meldung von Cursors CISO, der erklärte, eine Automatisierung habe versäumt, Mindgard in das private HackerOne-Programm einzuladen. Der erneut eingereichte Bericht wurde am nächsten Tag als informativ und außerhalb des Geltungsbereichs geschlossen, nach Widerspruch von Mindgard aber wieder geöffnet und von HackerOne reproduziert. HackerOne bestätigte die Zustellung am 20. Januar. Danach habe es Nachfragen im Februar, März und April gegeben, jedoch keine weitere Antwort.

Mindgard ist nicht das erste Unternehmen, das diese Fehlerklasse in AI-Werkzeugen beschreibt. Cymulate veröffentlichte im Juni Befunde zu demselben Muster unter Windows: Mehrere Werkzeuge lösen Hilfsprogramme über die Standard-Suchreihenfolge auf, bei der das Arbeitsverzeichnis vor vertrauenswürdigen Systempfaden geprüft wird. Betroffen waren laut Cymulate GitHub Copilot CLI, Gemini CLI und die Codex-Desktop-App; bei letzterer erfolgte die Ausführung wie bei Cursor beim Öffnen des Ordners. Zum Stand der Veröffentlichung vom 4. Juni hatte keiner dieser Anbieter einen Fix für die Berichte über platzierte Binärdateien ausgeliefert. Eine Ausnahme betraf AWS Kiro mit CVE-2026-10591, doch dabei handelte es sich laut Bericht um einen anderen Fehler: eine Agent-Dateischreibschwäche mit automatischer Ausführung über eine manipulierte „.vscode/tasks.json“.

Die zugrunde liegende Schwäche ist älter. Der Bericht verweist auf den unsicheren Suchpfad unter Windows als Ursache und auf das Platzieren einer Binärdatei an einem vom Suchmechanismus geprüften Ort als Angriff. Dieselbe Konstellation betraf 2020 bereits Git Credential Manager Core in CVE-2020-26233: Ein bösartiges „git.exe“ im Stamm eines Repositories wurde bei einem rekursiven Klonvorgang statt der echten Git-Datei gestartet. Behoben wurde das in GCM 2.0.289.