Cursor, die KI-gestützte Entwicklungsumgebung mit Millionen Nutzern, führt beim Öffnen eines Projekts eine bösartige git.exe aus dem Projektordner ohne Rückfrage aus. Der Sicherheitsanbieter Mindgard hat den Fehler im Dezember gemeldet, über sieben Monate aber keine Reaktion erhalten, und legt ihn nun vollständig offen. Für Entwicklerteams heißt das: Ein fremdes Repository zu öffnen kann bereits Codeausführung bedeuten.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Ein Cursor-Zero-Day beschäftigt gerade die Entwicklerwelt, und brisant ist weniger die Lücke selbst als der Umgang damit. Seit dem 15. Dezember 2025 liegt der Bericht beim Hersteller, mehr als 70 Versionen später fehlt der Patch noch immer. Der Anbieter Mindgard hat deshalb alle technischen Details veröffentlicht.
Das Wichtigste in Kürze
- Cursor startet eine als git.exe getarnte Datei aus dem Projektordner beim Öffnen automatisch, ohne Klick, Dialog oder Warnung.
- Ursache ist ein fehlendes Workspace-Trust-Konzept, kombiniert mit der Windows-Eigenart, das aktuelle Verzeichnis vor dem Systempfad zu durchsuchen.
- Der Fehler ist seit dem 15. Dezember 2025 gemeldet und in Version 3.2.16 weiterhin offen, während Cursor parallel zwei kritische Prompt-Injection-Lücken geschlossen hat.
- Fremde Repositories gehören in eine isolierte Umgebung, das git-Programm auf einen festen Systempfad.
Wie wird ein Repository zur Waffe?
Cursor sucht beim Projektstart an mehreren Orten nach dem git-Programm, darunter im geöffneten Projektordner selbst. Liegt dort eine Datei namens git.exe, startet Cursor sie mit den Rechten des angemeldeten Nutzers, wiederholt und ohne jede Rückfrage.
Der Anbieter Mindgard hat das Verhalten mit dem Windows-Taschenrechner gezeigt, den die Forscher schlicht in git.exe umbenannt haben[1]. Cursor hat das Programm beim Öffnen des Ordners von selbst ausgeführt.
Dahinter steckt eine bekannte Windows-Eigenart: Das System durchsucht bei einem Programmaufruf zuerst das aktuelle Arbeitsverzeichnis und erst danach den Systempfad. Eine passend benannte Datei im Ordner schiebt sich damit vor das echte Git.
Der eigentliche Mangel ist ein fehlendes Sicherheitsnetz. Der Vorläufer VS Code, auf dem Cursor aufsetzt, hat fast ein Jahrzehnt dasselbe Verhalten gezeigt, bis Microsoft 2021 das Konzept Workspace Trust eingeführt hat, das Code aus nicht vertrauenswürdigen Ordnern erst nach Freigabe ausführt. Genau diese Rückfrage fehlt hier. Dieselbe Klasse von Angriffen hat zuletzt auch andere Werkzeuge getroffen, etwa als ein Symlink Claude Code und Copilot austrickste. Dass ausgerechnet das hoch bewertete Cursor diese Rückfrage nicht kennt, macht den Fall so heikel.
Warum patcht Cursor die eine Lücke, die andere nicht?
Cursor hat im April zwei kritische Lücken mit dem Höchstwert 9.8 geschlossen, die per Prompt Injection aus der Sandbox ausbrachen. Den seit Dezember gemeldeten git.exe-Fehler hat der Anbieter dagegen monatelang unbeantwortet gelassen, während über 70 neue Versionen erschienen sind.
Der Anbieter Cato Networks beschreibt unter dem Namen DuneSlide zwei zusammenhängende Schwachstellen (CVE-2026-50548 und CVE-2026-50549), die per manipuliertem Text die Sandbox aushebelten und zu Codeausführung auf dem Betriebssystem führten[2]. Version 3.0 hat beide am 2. April 2026 behoben.
Der Kontrast legt das eigentliche Problem frei: nicht die einzelne Schwachstelle, sondern ein Meldeprozess, der versagt. Ein Automatisierungsfehler hat den Bericht zunächst als nicht zuständig geschlossen, danach ist er monatelang unbeantwortet geblieben. Genau dieses Muster, bei dem das bloße Anschauen eines fremden Repositorys Code startet, kennen Entwickler bereits von neuen Prompt-Injection-Angriffen und von der oft brüchigen Agenten-Infrastruktur.
Nicht die Windows-Eigenart ist der Skandal, sondern ein Meldeprozess, der sieben Monate lang ins Leere läuft. Sicherheit entsteht nicht durch Schweigen.
— Markus Seyfferth, Chefredakteur Dr. Web
Cursor und die getarnte git.exe: die Zahlen zum Fall
Was sollten deutsche Entwicklerteams jetzt tun?
Bis ein Patch vorliegt, sollten Teams fremde Repositories nur in einer isolierten Umgebung öffnen, das git-Programm auf einen festen Systempfad festlegen und statt der Eingabeaufforderung eine Shell nutzen, die das aktuelle Verzeichnis nicht automatisch durchsucht.
Im DACH-Raum sitzt Cursor in vielen Dev-Teams, und die Gefahr wächst mit dem Autopiloten: KI-Agenten klonen fremde Repositories inzwischen selbstständig zur Analyse. Aus der Frage, wer schon eine git.exe in ein Repository legt, wird so ein realistischer Lieferketten-Vektor. Teams, die Agenten laufen lassen, geben ihnen deshalb besser eine eigene Wegwerf-Umgebung als Zugriff auf den Arbeitsrechner.
Praktisch heißt das: git im Editor auf den absoluten Installationspfad festnageln und ungeprüften Fremdcode nur in einer Sandbox öffnen, nie direkt auf der Produktivmaschine. Eine Einordnung, welche KI-Werkzeuge im Team welche Rechte brauchen, liefert unser LLMs-Ratgeber. Der Fall zeigt vor allem, dass der Editor selbst zur Angriffsfläche geworden ist.
Quellen
[1] Mindgard: „Cursor 0day: When Full Disclosure Becomes the Only Protection Left“ ↩
[2] Cato Networks: „DuneSlide: Two Critical RCE Vulnerabilities via Zero-Click Prompt Injection in Cursor IDE“ ↩
Mehr Newshunger?
- Fünf neue Prompt-Injection-Angriffe: Wie sich KI-Agenten heimlich umprogrammieren lassen
- GitLost: Wie sich GitHubs KI-Agent zur Preisgabe privater Repositories verleiten lässt
- Codex verschlüsselt jetzt die Prompts seiner Sub-Agenten
- Wenn der KI-Agent die Malware selbst startet
- 27.800-mal mehr Daten als nötig: Grok Build lud ganze Git-Repositories zu xAI hoch
