Eine Sicherheitslücke im KI-Codeeditor Cursor kann unter Windows dazu führen, dass beim Öffnen eines präparierten Projekts automatisch eine darin enthaltene Programmdatei gestartet wird. Der Hersteller bestätigt die technischen Voraussetzungen, sieht darin jedoch keinen klassischen Produktfehler und verweist auf Schutzmechanismen für nicht vertrauenswürdige Arbeitsbereiche. Wie viele Nutzer tatsächlich gefährdet sind und ob aktuelle Versionen das Verhalten unverändert zeigen, bleibt offen.
Berlin, 17. Juli 2026. Die Cursor Sicherheitslücke betrifft einen Vorgang, der für Entwickler zum Alltag gehört: das Öffnen eines fremden Softwareprojekts. Liegt im Hauptverzeichnis eines solchen Projekts eine manipulierte Datei mit dem Namen git.exe, kann die Windows-Version des Editors diese Datei automatisch ausführen. Eine zusätzliche Warnung oder eine ausdrückliche Freigabe war in den dokumentierten Tests nicht erforderlich.
Das Sicherheitsproblem betrifft nach bisherigem Kenntnisstand ausschließlich Windows. Nutzer von macOS oder Linux sind von diesem konkreten Angriffsszenario nicht betroffen. Voraussetzung ist außerdem, dass ein Anwender ein manipuliertes Verzeichnis oder Repository öffnet, in dem die präparierte Datei bereits enthalten ist.
Cursor Sicherheitslücke nutzt die Git-Suche unter Windows aus
Cursor basiert auf Visual Studio Code und erweitert den Editor um Funktionen für künstliche Intelligenz. Entwickler können damit Quellcode schreiben, analysieren und automatisiert verändern lassen. Für die Verwaltung von Softwareprojekten greift das Programm unter anderem auf Git zurück, eines der wichtigsten Werkzeuge für Versionskontrolle.
Genau dort setzt die Cursor Sicherheitslücke an. Unter bestimmten Bedingungen sucht der Editor offenbar nicht nur an einem eindeutig festgelegten Ort nach der regulären Git-Anwendung. Befindet sich im geöffneten Projektordner eine ausführbare Datei namens git.exe, kann Cursor stattdessen diese lokale Datei starten.
Für einen Angriff müsste ein präpariertes Projekt also lediglich so gestaltet sein, dass es auf den ersten Blick wie ein gewöhnliches Repository wirkt. Die darin enthaltene git.exe könnte jedoch beliebigen Programmcode ausführen. Die KI-Funktionen des Editors spielen dabei keine Rolle. Weder eine manipulierte Eingabe noch ein Angriff auf ein Sprachmodell sind notwendig.
Das Sicherheitsunternehmen Mindgard demonstrierte den Ablauf mit einer ungefährlichen Testdatei. Die Forscher benannten den Windows-Taschenrechner in git.exe um und legten ihn in das Hauptverzeichnis eines Projekts. Nach dem Öffnen des Ordners in Cursor startete das Programm automatisch. Nach ihren Angaben geschah dies während der Nutzung des Projekts mehrfach.
Der ausgeführte Prozess läuft mit den Rechten des angemeldeten Benutzers. Damit könnte eine manipulierte Datei grundsätzlich auf alle Daten und Dienste zugreifen, die diesem Konto offenstehen. Dazu können Quellcode, lokale Dokumente, Zugangsdaten, SSH-Schlüssel oder gespeicherte Cloud-Verbindungen gehören. Welche Informationen im Einzelfall erreichbar sind, hängt von der jeweiligen Systemkonfiguration ab.
Hersteller bestätigt das Szenario, lehnt einen Patch aber ab
Mindgard meldete das Verhalten nach eigenen Angaben bereits am 15. Dezember 2025 an Cursor. Die technischen Details veröffentlichte das Unternehmen am 14. Juli 2026, nachdem über Monate keine Einigung über eine Behebung erzielt worden war. Cursor reagierte am folgenden Tag mit einer öffentlichen Stellungnahme.
Der Hersteller bestreitet die beschriebenen Voraussetzungen der Cursor Sicherheitslücke nicht. Er ordnet den Fall jedoch anders ein. Aus Sicht des Unternehmens entsteht das Risiko vor allem dadurch, dass Nutzer fremde oder nicht vertrauenswürdige Projekte öffnen. Der Bericht falle deshalb nicht unter die Kriterien des eigenen Bug-Bounty-Programms.
Cursor verweist auf ein Modell geteilter Verantwortung. Entwickler müssten kontrollieren, welche Dateien und Repositories sie in ihre Arbeitsumgebung übernehmen. Gleichzeitig solle die Funktion Workspace Trust verhindern, dass unbekannte Projektordner sofort mit allen Rechten geöffnet werden.
Im eingeschränkten Modus sollen automatische Prozesse, Erweiterungen und andere potenziell riskante Funktionen blockiert oder begrenzt werden. Unternehmen können diese Einstellung nach Angaben des Herstellers zentral vorgeben und über ihre Geräteverwaltung durchsetzen.
Mindgard bezweifelt allerdings, dass Workspace Trust die Cursor Sicherheitslücke in jeder Konstellation zuverlässig entschärft. Eine unabhängige technische Prüfung, die diese Frage abschließend beantwortet, liegt bislang nicht vor. Ebenso unklar ist, bei welchen Installationen die Schutzfunktion standardmäßig aktiv ist und wie häufig Nutzer zuvor bereits dauerhaft Vertrauen für Projektordner erteilt haben.
Keine Hinweise auf reale Angriffe
Bislang gibt es keine belastbaren Belege dafür, dass Kriminelle das Verhalten bereits für konkrete Angriffe genutzt haben. Weder Malware-Kampagnen noch Fälle von Datendiebstahl oder Erpressungssoftware wurden öffentlich eindeutig mit der Cursor Sicherheitslücke in Verbindung gebracht.
Der Begriff Schadcode beschreibt daher zunächst das technische Potenzial. Eine präparierte Datei könnte schädliche Funktionen enthalten, sofern ein Nutzer das manipulierte Projekt unter Windows öffnet. Ob diese Möglichkeit bereits missbraucht wurde, ist nicht bekannt.
Auch die häufig genannte Zahl von sieben Millionen Nutzern verlangt eine genaue Einordnung. Sie bezieht sich auf die gesamte aktive Nutzerschaft von Cursor. Wie viele davon den Editor unter Windows verwenden, ist nicht öffentlich bekannt. Ebenso wenig lässt sich beziffern, auf wie vielen Geräten Workspace Trust fehlt oder unwirksam konfiguriert ist.
Von sieben Millionen unmittelbar betroffenen Nutzern kann deshalb keine Rede sein. Die Zahl verdeutlicht vor allem die Reichweite des Produkts. Die tatsächlich gefährdete Gruppe ist kleiner, lässt sich auf Grundlage der verfügbaren Angaben aber nicht seriös bestimmen.
Unklarer Patch-Status bei neueren Cursor-Versionen
Die letzte konkret dokumentierte Prüfung erfolgte am 30. April 2026 mit Cursor in der Version 3.2.16. Als die Sicherheitswarnung veröffentlicht wurde, waren bereits neuere Ausgaben des Editors verfügbar. Diese Versionen wurden von Mindgard nach eigenen Angaben nicht erneut vollständig getestet.
Cursor hat bislang keine Version genannt, mit der die beschriebene Programmsuche grundsätzlich geändert oder die Cursor Sicherheitslücke geschlossen worden wäre. Auch ein ausdrücklich als Sicherheitsupdate ausgewiesener Patch wurde nicht angekündigt. Die Stellungnahme des Unternehmens legt vielmehr nahe, dass Cursor das Risiko weiterhin über Vertrauenseinstellungen und den vorsichtigen Umgang mit fremden Projekten begrenzen will.
Damit bleibt ein entscheidender Punkt ungeklärt: Ob jede aktuelle Windows-Version weiterhin eine lokale git.exe aus dem Projektverzeichnis startet, ist nicht unabhängig und öffentlich nachvollziehbar geprüft. Hinzu kommt, dass für das Problem bislang keine eigene CVE-Kennung und keine offizielle Bewertung des Schweregrads vorliegen.
So lässt sich das Risiko begrenzen
Für Windows-Nutzer ist vor allem beim Öffnen unbekannter Repositories Vorsicht geboten. Das gilt besonders für Projekte, die über öffentliche Plattformen, Foren, soziale Netzwerke oder direkte Nachrichten verbreitet werden und deren Herkunft nicht verlässlich geprüft werden kann.
Eine ausführbare Datei namens git.exe im Hauptverzeichnis eines Projekts ist ein auffälliges Warnsignal. Sicherheitsforscher empfehlen, fremden Quellcode zunächst in einer isolierten Umgebung zu untersuchen. Dafür kommen virtuelle Maschinen, Windows Sandbox oder eigens abgesicherte Testsysteme infrage.
- Unbekannte Repositories vor dem Öffnen auf ausführbare Dateien prüfen.
- Bei einer git.exe im Projektstamm besondere Vorsicht walten lassen.
- Workspace Trust aktivieren und in Unternehmen zentral vorgeben.
- Fremde Projekte nur in isolierten Entwicklungsumgebungen testen.
- Die Ausführung von Programmen aus Download- und Projektordnern einschränken.
Unternehmen können zusätzlich mit Anwendungskontrollen verhindern, dass unbekannte Programme aus Projektverzeichnissen gestartet werden. Auch Schutzsysteme für Endgeräte können auffällige Prozesse erkennen oder blockieren. Solche Maßnahmen ersetzen keinen Patch, reduzieren aber die Wahrscheinlichkeit einer erfolgreichen Ausnutzung.
Die offene Frage ist nicht nur technischer Natur
Die Cursor Sicherheitslücke berührt einen grundsätzlichen Konflikt in der Softwareentwicklung. Entwicklungsumgebungen arbeiten mit fremdem Code, Erweiterungen und automatisierten Werkzeugen. Gleichzeitig verfügen sie oft über weitreichenden Zugriff auf besonders sensible Daten: interne Quelltexte, Zugangsschlüssel, Cloud-Dienste und technische Dokumentationen.
Cursor argumentiert, dass Nutzer nicht vertrauenswürdige Projekte nur mit den vorgesehenen Schutzmechanismen öffnen sollten. Die Sicherheitsforscher halten dagegen, dass bereits das Öffnen eines Ordners nicht ohne weitere Bestätigung zum Start einer darin enthaltenen Programmdatei führen dürfe.
Fest steht: Das Verhalten konnte unter Windows reproduziert werden, und Cursor hat bislang keinen ausdrücklich ausgewiesenen Patch angekündigt. Nicht belegt sind dagegen Millionen unmittelbar gefährdeter Nutzer oder bereits erfolgte Angriffe. Entscheidend ist nun, ob der Hersteller die Programmsuche künftig technisch verändert oder dauerhaft darauf setzt, dass Anwender ihre Projekte konsequent isolieren und Vertrauenseinstellungen richtig konfigurieren.
