Technischer Kontext
Ich sehe selten eine so bodenständige und zugleich unangenehme Lücke: Cursor unter Windows kann selbst eine bösartige git.exe starten, wenn sie im Stammverzeichnis eines geöffneten Repository liegt. Keine Klicks, kein Prompt Injection, keine eleganten KI-Angriffe. Einfach den Ordner geöffnet, und los geht’s.
Gerade bei solchen Geschichten prüfe ich üblicherweise die Reife der KI-Implementierung in einem Unternehmen. Wenn ein Entwicklerwerkzeug bei der Suche nach einer Binärdatei im Arbeitsbereich versagt, liegt das Problem nicht mehr am Modell oder am Agenten, sondern an der grundlegenden Produkthygiene.
Laut Mindgard liegt die Ursache des Bugs in der Git-Suchlogik: Cursor prüft mehrere Pfade und greift sich eine ausführbare Datei direkt aus dem Projektverzeichnis. Es folgt eine typische beliebig Code-Ausführung mit den Rechten des aktuellen Benutzers. Die Demo war fast schon hämisch einfach: Sie benannten den Taschenrechner in git.exe um und Cursor führte ihn stillschweigend aus.
Was mich daran fasziniert hat, war nicht nur die Codeausführung, sondern die Stille darum. Keine Warnung, keine Bestätigung, nicht einmal ein Hinweis darauf, dass die IDE gerade eine Binärdatei aus einem nicht vertrauenswürdigen Repository anfasst.
Die Geschichte wird durch das Timing noch schlimmer. Mindgard gibt an, das Problem am 15. Dezember 2025 gemeldet und dann mehrfach nachgehakt zu haben, auch über HackerOne, und die Schwachstelle war mindestens in der am 30. April 2026 geprüften Version 3.2.16 weiterhin reproduzierbar. Wenn die Zahlen stimmen, sind das über sechs Monate und mehr als 197 Releases ohne Fix.
Zum jetzigen Zeitpunkt, dem 15. Juli 2026, ist die Neuigkeit nicht mehr frisch im Sinne von „gerade entdeckt“, sondern eher eine anschauliche Analyse, wie die vollständige Offenlegung zur letzten Verteidigung wird, wenn der Anbieter auf Zeit spielt. Cursor erklärte gegenüber Dark Reading, man sei dabei, das Problem zu „beheben“, doch die öffentliche Bekanntgabe sagt bereits viel über den Reaktionsprozess aus.
Was das für Unternehmen und Automatisierung bedeutet
Verlierer sind Teams, die externe Repositorys auf produktiven Windows-Entwicklerrechnern ohne Isolation öffnen. Gewinner sind diejenigen, die schon lange vertrauenswürdige und nicht vertrauenswürdige Umgebungen getrennt haben und KI-Automatisierung sowie Dev-Tools innerhalb von Richtlinien-Grenzen betreiben.
Meine praktische Schlussfolgerung ist einfach: Alle KI-IDEs und Agenten müssen in dasselbe Bedrohungsmodell aufgenommen werden wie Browser, E-Mail und RDP-Client. Wenn ein Entwickler Code von außen holt, braucht er eine Sandbox, und unter Windows mindestens AppLocker oder Windows App Control.
Und ja, das trifft nicht nur die Sicherheit, sondern auch die Prozessarchitektur. Ich würde überdenken, wo genau Ihre KI-Integration für die Entwicklung angesiedelt ist, wer externe Projekte lokal öffnen darf und welche Binärdateien überhaupt aus dem Arbeitsbereich gestartet werden können.
Wenn Ihr Team bereits auf Cursor, Copilot, Agenten und interne Tools angewiesen ist, würde ich nicht auf die nächste solche Geschichte warten. Bei Nahornyi AI Lab helfen wir genau dabei, KI-Automatisierung und Schutzvorkehrungen so aufzubauen, dass Entwickler nicht an Geschwindigkeit verlieren und das Unternehmen nicht für einen versehentlich geöffneten Ordner bezahlt. Wenn Sie möchten, schauen wir uns gemeinsam Ihre Umgebung an und erstellen eine solide Architektur ohne überflüssige Magie.