Die laute Version lautet: „Ein 0-day in einem KI-Editor führt von selbst Code aus.“ Nützlicher ist die ruhige Version. Mindgard behauptet, Cursor unter Windows könne beim Suchen nach Git eine git.exe aus dem Wurzelverzeichnis eines geöffneten Repositories starten. Cursor sagt, das Risiko sei eng begrenzt und falle unter geteilte Verantwortung für nicht vertrauenswürdige Workspace-Eingaben. Die praktische Lehre: Ein unbekanntes Repository in einem KI-gestützten Entwicklungstool zu öffnen, ist nicht mehr völlig passiv.

Entwicklerarbeitsplatz mit verdächtiger Repository-Datei isoliert von geschützten Secrets

Mindgards Proof of Concept benannte Windows Calculator in git.exe um, legte ihn in die Repository-Wurzel und sah ihn beim Öffnen des Projekts in Cursor starten. Das ist keine Prompt Injection, kein Beweis für kompromittierte Nutzer und keine Bestätigung für macOS oder Linux. Die Bedingungen zählen: Windows, Cursor, eine Datei exakt namens git.exe im Projektroot und ein Projektladevorgang, der Git-Erkennung auslöst.

Was behauptet wird

Mindgard sagt, Cursor prüfe mehrere Orte für Git und könne den Workspace-Binary ausführen. Cyber Security News berichtete von Process-Monitor-Logs, in denen Cursor.exe den Binary mit git rev-parse --show-toplevel startet. The Hacker News ergänzt: Öffentlich ist nicht endgültig belegt, ob Cursor den Workspace selbst durchsucht oder ein unqualifiziertes git an Windows übergibt und damit die Windows-Suchreihenfolge greift.

Für Verteidiger ist das Ergebnis ähnlich: Eine Datei im Projekt wechselt von gelesen zu ausgeführt, bevor eine klare Vertrauensentscheidung fällt. Die Klasse ist alt — untrusted search path / current-directory executable resolution — der Kontext neu: KI-IDEs lesen, starten und ändern mehr automatisch.

Wichtig ist die Beweisgrenze. The Hacker News schrieb, Mindgards letzte datierte Bestätigung betreffe Cursor 3.2.16 vom 30. April, während 3.11 vom 10. Juli als aktuelle Version genannt wurde. Ein offizielles Cursor-Advisory oder CVE speziell zu diesem git.exe-Fall fand sich bei der Prüfung nicht. Teams sollten ihre Version und die Advisories prüfen, statt absolute Annahmen zu treffen.

Cursor’s Sicht

Cursor erklärte den Bericht als außerhalb des Bug-Bounty-Scopes. Kunden entschieden selbst, welche Repositories, Prompts, MCP-Server, Regeln und Tools sie in ihre Umgebung bringen; Cursor stelle Kontrollen für diese Grenze bereit. Das Unternehmen nennt enge Voraussetzungen: Windows und ein Ordner mit bösartiger git.exe im Root. Als Kontrolle nennt es Workspace Trust / Restricted Mode und räumt zugleich Kommunikationsversäumnisse ein.

Geteilte Verantwortung ist sinnvoll, ersetzt aber keine Produktverantwortung. „Ich öffne einen Ordner, um Code zu lesen“ ist nicht „ich erlaube das Ausführen eines Binaries daraus“. Je mehr eine IDE automatisiert, desto klarer muss die Grenze zwischen Lesen und Ausführen sein.

Warum das ohne Panik wichtig ist

Die Diskussion auf Hacker News war erwartbar. Manche verweisen auf bekannte Windows-Risiken mit lokalen Executables. Andere sagen: Repositories zu klonen und zu öffnen ist normale Arbeit für Maintainer, Reviewer und Security Teams. Der Unterschied zwischen manuellem Befehl und automatischem Start beim Öffnen ist die Vertrauensgrenze.

In den geprüften Quellen gab es keine bestätigte Ausnutzung in der Praxis. Das senkt die Alarmstufe, aber nicht den Bedarf an Kontrollen.

Nicht mit DuneSlide vermischen

DuneSlide, CVE-2026-50548 und CVE-2026-50549, war ein anderer Cursor-Fall: Prompt Injection und Sandbox Escape, laut The Hacker News in Cursor 3.0 behoben. Der Mindgard-git.exe-Fall betrifft lokale Executable-Auflösung beim Laden eines Projekts.

Was zu tun ist

Cursor aktualisieren und offizielle Hinweise verfolgen. Workspace Trust oder Restricted Mode für unbekannte Ordner aktivieren. Fremde Repositories nicht direkt auf dem Hauptsystem öffnen, sondern Windows Sandbox, VM, Devcontainer oder Wegwerf-Cloud-Umgebung nutzen. Vor dem Öffnen Projektroot auf Executables, .cmd/.ps1, Hooks, Tasks und Wrapper prüfen.

Teams brauchen praktikable Regeln: unbekannte Repositories isoliert, Produktions-Secrets außerhalb allgemeiner Entwicklungsumgebungen, Agents ohne breite Cloud-Adminrechte. Unter Windows können AppLocker oder Windows Defender Application Control nach Workspace-Pfaden helfen, sollten aber pilotiert werden. EDR kann melden, wenn Cursor.exe Binaries aus Repository-Pfaden startet.

Die Lehre

Das ist kein Grund für Cursor-Panik. Es ist ein Grund, Entwicklerarbeitsplätze als Angriffsfläche zu behandeln. Unbekannte Repositories sind ausführbarer Inhalt, bis das Gegenteil klar ist. KI-Tools brauchen sicherere Defaults und sichtbare Vertrauensgrenzen.