Cursor-Zero-Day: Warum vollständige Offenlegung zum einzigen verbleibenden Schutz wurde

• Cursor für Windows führt beim Öffnen eines Projekts automatisch die git.exe im Workspace-Root aus. Dadurch kann schon das Öffnen eines Repositorys mit einem bösartigen Binary dazu führen, dass beliebiger Code ohne Benutzerinteraktion ausgeführt wird
• Der Suchbereich für den Git-Pfad umfasst das Repository selbst; Dateien werden nicht nur ohne Warnung oder Bestätigung ausgeführt, sondern während das Projekt geöffnet ist auch regelmäßig erneut gestartet
• Mindgard meldete den Fehler am 15. Dezember 2025 und schloss die Reproduktion sowie Weiterleitung über HackerOne ab. Dennoch bestand das Problem auch nach mehr als 6 Monaten und über 197 neuen Versionen noch in der neuesten Testversion
• Verwaltete Windows-Umgebungen sollten pfadbasierte Deny-Regeln in AppLocker oder Windows App Control anwenden; normale Nutzer sollten nicht vertrauenswürdige Repositorys bis zu einem Patch nur in einer VM oder in Windows Sandbox öffnen
• Da Mindgard zu dem Schluss kam, dass ein koordinierter Offenlegungsprozess das Risiko für Nutzer nicht reduzieren konnte, veröffentlichte das Unternehmen alle Details. Bei der Auswahl von AI-Entwicklungstools sollten auch die Sicherheitsreaktion und Kommunikationsfähigkeit des Anbieters als Vertrauenskriterien gelten

---

git.exe, das allein durch das Öffnen eines Repositorys ausgeführt wird

• Cursor sucht beim Laden eines Projekts an mehreren Orten nach dem Git-Binary; zu den Suchzielen gehört auch der aktuelle Workspace
• Platziert ein Angreifer eine bösartige git.exe im Repository-Root, führt Cursor sie automatisch aus – ohne Warnung, Bestätigungsdialog oder zusätzlichen Klick
• Der Angriff beginnt allein dadurch, dass ein Entwickler das Projekt öffnet; Prompt Injection, Modellmanipulation, Jailbreaks, Speicherfehler oder komplexe Exploit-Ketten sind nicht erforderlich
• Der ausgeführte Code läuft im Berechtigungsumfang des aktuellen Cursor-Nutzers

Reproduktionsablauf und Protokoll der wiederholten Ausführung

• Mindgard benannte für einen sicheren Proof of Concept den Windows Calculator in git.exe um und platzierte ihn im Repository-Root
• Als das Repository in Cursor geöffnet wurde, startete der Calculator; blieb das Projekt geöffnet, erschienen zusätzlich mehrere Fenster
  • Der Forscher hat nicht manuell mehrere Fenster geöffnet
  • Es handelte sich nicht um ein einmaliges Startverhalten, sondern um das Ergebnis einer regelmäßigen erneuten Ausführung der ausführbaren Datei im Workspace während der normalen Nutzung
• In einem realen Angriff könnte statt des Calculators vom Angreifer kontrollierter Code platziert werden
• In den Aufzeichnungen von Sysinternals Process Monitor ist festgehalten, dass Cursor.exe die git.exe im Repository ausführte und dabei folgenden Befehl übergab

git rev-parse --show-toplevel

• Die letzte Verifikation erfolgte am 30. April 2026 mit Cursor 3.2.16 für Windows

Eine Schwachstelle, die in einer großen Nutzerbasis bestehen blieb

• Cursor ist eine AI-gestützte Entwicklungsumgebung mit folgender Nutzung
  • über 7 Millionen aktive Nutzer
  • über 1 Million tägliche Nutzer
  • über 1 Million zahlende Nutzer
  • über 50.000 Unternehmen als Nutzer
• Der berichtete Marktwert liegt bei 60 Milliarden US-Dollar
• Mindgard entdeckte die Schwachstelle am 15. Dezember 2025 und meldete sie am selben Tag
• Nach den Angaben im Einstieg war die Schwachstelle auch nach mehr als 6 Monaten und über 197 neuen Versionen noch in der neuesten Testversion vorhanden
• Im Abschnitt zum Reaktionsverlauf wird festgehalten, dass während fortlaufender Feature-Ergänzungen und Ankündigungen über 70 Versionen veröffentlicht wurden, das Problem jedoch bestehen blieb
• Eine einfache und leicht reproduzierbare Schwachstelle zur Ausführung beliebigen Codes blieb monatelang ungelöst, wodurch sowohl Einzelpersonen als auch Organisationen betroffen waren, die Cursor ausgerollt hatten

Vorübergehende Gegenmaßnahmen vor einem Patch

• Auf verwalteten Windows-Systemen können AppLocker- oder Windows-App-Control-Richtlinien verwendet werden, um die betreffenden ausführbaren Dateinamen in Entwicklungs-Workspace-Verzeichnissen zu blockieren
• Da sich Hashes je nach Binary ändern können, eignen sich pfadbasierte Deny-Regeln, die auf Repository- oder Workspace-Roots beschränkt sind, besser als hashbasierte Blocklisten

%USERPROFILE%\source\repos\*\filename.exe

• Windows bietet keine allgemeine eingebaute Regel, die beliebige Child-Executables nur dann blockiert, wenn sie von einem bestimmten Parent-Prozess gestartet wurden
  • Für Parent-Prozess-bewusste Kontrollen sind EDR oder maßgeschneiderte Endpoint-Security-Produkte erforderlich
• Normale Nutzer sollten nicht vertrauenswürdige Repositorys bis zum Patch der IDE nur in einer isolierten VM, in Windows Sandbox oder in einer wegwerfbaren Umgebung öffnen
• Da sich der Hash bei jeder Änderung des Binarys ändern kann, sollte man sich bei dieser Schwachstelle nicht auf Datei-Hash-Blocklisten verlassen

Ein koordinierter Prozess, der nach der Meldung stecken blieb

• Die erste Meldung wurde an die in Cursors security.txt angegebene E-Mail-Adresse für Sicherheitsmeldungen gesendet, es kam jedoch keine Empfangsbestätigung
• Mindgard versuchte über Folge-E-Mails und eine öffentliche Kontaktanfrage die richtige Sicherheitskontaktperson zu finden
• Der Cursor-CISO antwortete, dass ein internes Automatisierungsproblem den vorgesehenen HackerOne-Prozess nicht gestartet habe, und lud Mindgard manuell in das private Bug-Bounty-Programm ein
• Der erneut über HackerOne eingereichte Bericht wurde zunächst als Informative und außerhalb des Scopes geschlossen
  • Mindgard focht diese Entscheidung an
  • Nachdem HackerOne das Problem reproduziert hatte, wurde der Bericht wieder geöffnet, und es wurde bestätigt, dass die Details an Cursor weitergeleitet wurden
• Danach blieben Update-Anfragen, Eskalationen über HackerOne sowie direkte Kontaktaufnahmen mit dem Cursor-CISO und der Geschäftsführung ohne sinnvolle Antwort
• Mindgard erhielt keinen Nachweis, dass eine Behebung begonnen hatte, das Engineering-Team ermittelte oder betroffene Nutzer über das Risiko informiert wurden

Zeitplan von der Meldung bis zur vollständigen Offenlegung

• 15. Dezember 2025

  • Mindgard entdeckt die Schwachstelle
  • Meldung an [e-mail]

• 18. Dezember 2025

  • Folgekontakt mit Bitte um Empfangsbestätigung

• 13. Januar 2026

  • Veröffentlichung eines LinkedIn-Posts, um eine Kontaktperson bei Cursor zu finden
  • In den Kommentaren verweist ein Nutzer auf den Cursor-CISO

• 15. Januar 2026

  • Der Cursor-CISO informiert über das Versagen der Automatisierung für die private HackerOne-Bounty-Einladung und lädt manuell ein
  • Mindgard reicht die Schwachstelle über HackerOne ein

• 16. Januar 2026

  • Der Bericht wird als Informative und außerhalb des Scopes geschlossen
  • Mindgard ficht die Entscheidung an
  • Nach erfolgreicher Reproduktion wird der Bericht wieder geöffnet

• 20. Januar 2026

  • HackerOne bestätigt, den Bericht an Cursor weitergeleitet zu haben

• 16. Februar, 3. März 2026

  • Mindgard bittet um Updates, erhält jedoch keine Antwort

• 17. März 2026

  • Direkte Bitte um ein Update an den Cursor-CISO

• 18. März 2026

  • HackerOne teilt mit, Cursor kontaktiert zu haben

• 1. April 2026

  • Mindgard bittet erneut um ein Update, erhält jedoch keine Antwort
  • HackerOne bestätigt ebenfalls, dass es von Cursor kein Update gibt

• 1. Juni 2026

  • Mindgard informiert HackerOne über die Absicht zur Veröffentlichung

• 3. Juni 2026

  • HackerOne stellt Veröffentlichungsrichtlinien bereit

• 14. Juli 2026

  • Veröffentlichung des Beitrags mit den Details zur Schwachstelle

Warum koordinierte Offenlegung hier nicht zum Schutz der Nutzer führte

• Übliche koordinierte Offenlegung verläuft über Meldung, Austausch, Diskussion der Schwere, Engineering-Untersuchung, Entwicklung eines Fixes, Schutz der Nutzer und Veröffentlichung
• Dieser Prozess funktioniert, wenn alle Beteiligten das Ziel der Risikoreduzierung teilen
• In diesem Fall gab es über 7 Monate hinweg keine sinnvolle Beteiligung des Anbieters, sodass der Prozess die Phase der Risikoreduzierung nicht erreichte
• Bei großen und sich schnell entwickelnden Plattformen können Fixes Zeit benötigen, doch ohne monatelange Kommunikation, Updates oder sichtbaren Fortschritt ist weiteres Warten schwer zu rechtfertigen
• Den Forschern blieben nur zwei Optionen
  • Schweigen und Nutzer unter der falschen Annahme weiterarbeiten lassen, sie seien sicher
  • Offenlegen, damit Organisationen das Risiko erkennen und über Gegenmaßnahmen entscheiden können
• Mindgard entschied sich für die vollständige Offenlegung, die genutzt wird, wenn alle anderen Wege gescheitert sind

Fragen, die Bug Bounty und AI-Sicherheitsreaktionen hinterlassen

• Zu den Ursachen der verzögerten Behebung werden folgende Möglichkeiten hinterfragt
  • Ob moderne Bug-Bounty-Programme überlastet sind
  • Ob leistungsfähigere Modelle wie Mythos das Meldeaufkommen schwer beherrschbar gemacht haben
  • Ob Cursor wegen der SpaceX-Übernahme den Fokus auf Nutzersicherheit verringert hat
  • Ob Nutzersicherheit tatsächlich ein Anliegen ist, wenn Milliarden von Dollar auf dem Spiel stehen
• Mit der Verbreitung von AI-Produkten steigt die Zahl der Sicherheitsfunde stark, und viele passen nicht sauber in bestehende Schwachstellenkategorien
• Die Klassifizierungs- und Intake-Prozesse, auf die sich die Branche seit etwa 20 Jahren stützt, scheitern im AI-Umfeld schnell, weil ihre Grundannahmen ins Wanken geraten
• Wenn die Offenlegungspipeline überlastet ist, sollte die Branche dies transparent machen, damit Forschende, Kunden und Nutzer die Lage einschätzen können
• Schnell wachsende Unternehmen müssen Sicherheitsversagen beheben und Nutzer zugleich als wertvolle Kunden behandeln, nicht als Kaufexperiment

Bedingungen, um AI-Entwicklungstools zu vertrauen

• AI-Unternehmen verlangen beispiellos weitreichenden Zugriff auf Code und Repositorys, Terminals, Geheimnisse und Workflows; zugleich verschwimmt die Grenze zwischen Vorschlag und Ausführung zunehmend
• Nutzer vertrauen Produktionssoftware Quellcode, Zugangsdaten, proprietäres geistiges Eigentum und immer autonomere Funktionen an
• Systeme sollten nicht allein deshalb vertrauenswürdig sein, weil sie die Produktivität erhöhen; Vertrauen muss durch Reaktion auf Sicherheitsmeldungen, Kommunikation mit betroffenen Nutzern und Priorisierung von Fixes verdient werden
• Vertrauen erfordert Verantwortung, und Verantwortung erfordert Kommunikation. Wenn Nutzer, Forschende und öffentliche Plattformen jedoch monatelang nicht einmal grundlegende Statusupdates erhalten, lässt sich diese Verantwortung schwer überprüfen
• Mindgard veröffentlichte alle Details, um Organisationen die Möglichkeit zu geben, ihre Exposition zu bewerten, kompensierende Kontrollen anzuwenden und ihren Sicherheitszustand einzuschätzen
• Wenn das weitere Zurückhalten von Informationen nicht mehr die Nutzer schützt, sondern nur noch das Schweigen, muss trotz aller Unbequemlichkeit die Nutzersicherheit Vorrang haben

[GN⁺]

Hacker-News-Kommentare

• Aus der Sicht von Teams, die Sicherheitsmeldungen entgegennehmen, kommt eine kaum noch zu bewältigende Flut von minderwertigen, von LLMs erzeugten Reports herein, die das Produktdesign oder den Security-Umfang meist nicht verstehen. Gelegentlich sind auch sehr gute Reports darunter, daher muss man alles selbst prüfen, aber noch mehr weitschweifige, von LLMs erzeugte „Begründungen“ zu schicken, ist keine Lösung, und auch dieser Text wirkt größtenteils so, als sei er mit einem LLM geschrieben worden.
  Auch in diesem Fall gilt: Wenn in einer Umgebung, in der Software beliebigen Code oder Binärdateien ausführen kann, eine bösartige Binärdatei platziert wurde, dann liegt die Verantwortung eher bei der Isolierung und Absicherung des Workspaces — es sei denn, Cursor will auch die Sicherheit der gesamten Benutzerumgebung übernehmen.
  Wer mit LLMs CVE-Reports erstellt, sollte sie entscheidend für den reproduzierbaren Nachweis nutzen und den eigentlichen Text selbst knapp schreiben, dabei unnötige Adjektive und Übertreibungen im typischen LLM-Stil entfernen.

  • Nur weil man ein frisch geklontes Repository in Cursor öffnet, dürfen darin enthaltene Binärdateien nicht automatisch ausgeführt werden.
  • Die PATH-Variable existiert genau, um solche Probleme zu kontrollieren. Wenn ich es richtig verstanden habe, fügt Cursor das Repository sofort zu PATH hinzu, ohne Zustimmung des Nutzers.
  • Es gibt keine einfache Lösung; wenn einem Sicherheit wichtig ist, muss man in einer veränderten Umgebung mehr Personal für die Prüfung einsetzen. Noch eine zusätzliche Schicht aus LLM-Checks löst das Problem nicht.

• Die Wurzel des Problems ist, dass Cursor das Klonen eines Repositorys und die Codeausführung nicht als getrennte Sicherheitsgrenzen betrachtet. Cursor deaktiviert Workspace Trust standardmäßig[0], und schon das Öffnen eines Repositorys mit "runOn": "folderOpen" in .vscode/tasks.json führt zur Ausführung beliebigen Codes[1].
  [0] https://cursor.com/docs/agent/security#workspace-trust
  [1] https://www.oasis.security/blog/cursor-security-flaw

• Mindgard habe die Schwachstelle erstmals am 15. Dezember 2025 entdeckt und noch am selben Tag sowie mehrfach danach gemeldet, doch auch nach 6 Monaten und mehr als 197 neuen Versionen sei sie noch immer in der aktuellen Cursor-Version vorhanden.
  Zunächst wurde der Report als rein informativ bzw. außerhalb des Geltungsbereichs geschlossen; nach einem Einspruch habe HackerOne ihn erneut geöffnet, reproduziert und an Cursor weitergeleitet, doch danach seien Update-Anfragen, Rückfragen, eine Eskalation über HackerOne und sogar Kontaktaufnahmen an die Cursor-Geschäftsführung unbeantwortet geblieben — es ist schwer nachzuvollziehen, warum Cursor so reagiert.

  • Der CVE-Prozess selbst ist kaputt. Durch den Fortschritt agentischer KI gibt es in Programmen zur koordinierten Offenlegung von Schwachstellen bei HackerOne und Unternehmen gleichzeitig einen starken Anstieg sowohl minderwertiger als auch tatsächlich hervorragender Reports, und da oft dieselbe KI beide schreibt, sind sie an der Oberfläche fast nicht zu unterscheiden.
    Daher reagieren Unternehmen nicht mehr wie früher, und auf der Cybersecurity-Konferenz im Juni habe stark die Stimmung überwogen, dass verantwortungsvolle Offenlegung tot oder im Sterben sei und man Schwachstellen besser öffentlich machen solle. Microsoft und der Fall Nightmare Eclipse wurden häufig zitiert.
  • Auch die Möglichkeit einer absichtlichen Backdoor drängt sich auf. Wenn NSA oder FBI in ein Ziel-Repository git.exe einfügen und das Ziel zum Klonen bringen würden, könnte der Payload ausgeführt werden.
    Da Cursor auf VS Code basiert, stellt sich die Frage, ob dasselbe auch in VS Code passiert.

• Es fällt mir schwer, voll zuzustimmen, dass dies eine gravierende Schwachstelle ist. Für eine tatsächliche Ausnutzung müsste ein Angreifer zunächst eine bösartige ausführbare Datei namens git.exe im Code-Ordner des Nutzers platzieren; das ist ähnlich, als würde man es eine Schwachstelle nennen, wenn man .bashrc so ändert, dass ls per Alias /tmp/mega-big-virus.sh ausführt.
  Es ist zwar ein möglicher Angriffsweg, aber wenn sich eine solche Datei bereits im Dateisystem befindet, kann man das auch als bereits erfolgte Vorab-Kompromittierung ansehen.

  • Man kann bereits infiziert werden, indem man ein GitHub-Repository klont und es mit Cursor als Standard-Editor öffnet. Das ist so, als würde beim Einlegen einer CD autorun.exe starten und Windows infizieren.
    Man könnte verlangen, dass Nutzer alle Repository-Dateien und verdächtigen Binärdateien wie git.exe selbst in einer isolierten Umgebung prüfen, aber in der Praxis wird so etwas nicht vom Nutzer kontrolliert, sondern durch Sicherheitsrichtlinien, die automatische Ausführung verhindern — und bei Cursor sollte das genauso deaktiviert sein.
  • Anders als .bashrc stammen Code-Ordner häufig aus nicht vertrauenswürdigen Quellen. Nur weil man ein GitHub-Projekt zur Prüfung öffnet, darf das nicht zugleich die Ausführung beliebigen Codes erlauben.
    Allerdings ist diese Grenze in großen IDEs schon lange aufgeweicht, und auch die SSH- und devcontainer-Remote-Funktionen von VS Code erlauben per Design die Ausführung von Remote-Code.
  • Schon im ersten Absatz der Seite steht in zwei Sätzen klar, dass Cursor nach dem Öffnen eines Projekts an mehreren Stellen, einschließlich des aktuellen Workspaces, nach Git-Binärdateien sucht und eine bösartige git.exe im Repository-Root ohne Benutzereingabe oder Bestätigung ausführt. Es ist also kein Text, der das Kernverhalten verschleiert.
  • Wer nur ein Repository klont und in einer IDE öffnet, erteilt dem Repository-Eigentümer damit faktisch Remote-Code-Execution-Rechte; schwer vorstellbar, dass das als impliziter Bestandteil des Vertrags beim Öffnen eines Ordners gelten soll.
  • Schon vor 30 Jahren gab es DLL-Search-Order-Angriffe, bei denen infizierte Ersatz-DLLs in MP3- oder Foto-Ordner gelegt wurden, damit Winamp oder die Windows-Fotoanzeige sie laden; das ist diesem Fall sehr ähnlich.

• Dass Cursor ohne Bestätigung beliebige ausführbare Dateien startet, ist seltsam, und ebenso besorgniserregend ist, dass die Forschenden monatelang keine ordentliche Antwort erhalten haben.
  Das Beispiel mit dem Starten des Taschenrechners könnte allerdings etwas irreführend sein. Die bösartige ausführbare Datei müsste bereits auf das System heruntergeladen worden sein, und wenn Cursor versucht, sie zu starten, würde nach meinem Verständnis die ACL greifen und nachfragen, ob diese neu signierte oder unsignierte App erstmals ausgeführt werden soll. Für eine reale Ausnutzung müsste die ACL möglicherweise vollständig deaktiviert sein.

  • Wenn im Dialog „git.exe ausführen?“ steht, ist die Wahrscheinlichkeit groß, dass man denkt, Cursor brauche Git und die Berechtigungen seien nur etwas durcheinander, und deshalb einfach bestätigt.
  • Dasselbe könnte auch passieren, wenn man ein PS1 verwendet, das den aktuellen Git-Branch anzeigt, und zugleich das aktuelle Verzeichnis in PATH enthält. Dann stellt sich die Frage, ob man auch für Bash ein hochgradiges CVE einreichen müsste.

• Es scheint weniger ein Cursor-spezifischer Bug zu sein als vielmehr mit der Windows-spezifischen Suchreihenfolge zusammenzuhängen, bei der Windows im aktuellen Arbeitsverzeichnis nach ausführbaren Dateien sucht, bevor PATH geprüft wird. Wahrscheinlich sind viele Windows-Programme ähnlichen Angriffen ausgesetzt.

  • Software, die Sicherheit ernst nimmt, hat dieses Problem bereits behoben.
    Wie unter https://go.dev/blog/path-security erklärt, suchen Command und LookPath Programme gemäß den Konventionen des Betriebssystems in den im aktuellen PATH aufgeführten Verzeichnissen, aber heutzutage ist das Einbeziehen des aktuellen Verzeichnisses meist unerwartet und führt zu Sicherheitsproblemen.
    https://pkg.go.dev/os/exec#hdr-Executables_in_the_current_di...
  • Das lässt sich leicht abmildern, indem man die echte Git-Executable in bekannten Systempfaden sucht oder den Nutzer den Pfad konfigurieren lässt; soweit ich weiß, macht VS Code es auf diese Weise.
  • Das ist eine alte und gut bekannte Sicherheitsfalle, gegen die man sich bei der Entwicklung von Windows-Software unbedingt absichern muss.
  • Dann klingt es letztlich doch so, als ob die Windows-Version von Cursor einen Bug und eine Schwachstelle hat.

• Dass Unternehmen Sicherheit nicht priorisieren, ist leider sehr häufig, wenn auch bis zu einem gewissen Grad nachvollziehbar. Auch dass ein Security-Startup nach langem Warten erschöpft aufgibt und die Offenlegung nutzt, um zumindest einen Teil der Kosten über PR-Effekt zurückzuholen, ist verständlich, und es gibt Fälle, in denen eine öffentliche Offenlegung von Schwachstellen nötig ist.
  Wenn man aber wirklich bei der Behebung hätte helfen wollen, hätte man wohl mehr tun können, als auf HackerOne zu drängen und dem CISO einmal über LinkedIn zu schreiben. Inzwischen wirkt es bittererweise so, als würde es niemanden mehr wirklich interessieren.

  • Es ist unklar, was genau hier als ernsthafte Hilfe bei der Behebung gelten soll und was mit den versunkenen Kosten konkret gemeint ist. Insgesamt klingt das zu vage.

• Ich frage mich, warum Cursor überhaupt ausführbare Dateien automatisch startet und welcher Entscheidungsablauf zu diesem Verhalten geführt hat. Auch Vim hatte Probleme, bei denen durch explizite Funktionen wie %{expr} beim Laden einer Datei unerwartet Code ausgeführt wurde, aber bei Cursor ist schwer nachvollziehbar, warum ausgerechnet nach git.exe gesucht wird und wem diese Funktion nützen soll.
  Selbst ohne Cursor je benutzt zu haben, frage ich mich, warum ein offenbar leicht zu behebender, redundanter CVE überhaupt existiert.

  • Ein üblicher Ablauf ist, Cursor zu bitten, ein bestehendes Repository zusammenzufassen und eine README zu schreiben; Cursor liest dann Repository und Code und führt Git-Befehle aus, um zusätzlich Metadaten wie Entwicklungs-Branches oder frühere Tags bereitzustellen.
    Das Problem ist, dass beim Auswerten eines Remote-Repositories nach dem Klonen im Arbeitsverzeichnis git ... ausgeführt wird und Windows dann die im Verzeichnis liegende Datei git als auszuführendes Ziel interpretieren kann. Auch beim Wechsel auf ein nicht vertrauenswürdiges Repository oder einen kompromittierten Branch kann dadurch sofort Code ausgeführt werden.
    Die übliche Lösung ist, den vollständigen Pfad des im System installierten Git zu verwenden; für Menschen mühsam einzugeben, für Cursor aber trivial.
  • Es wirkt so, als solle absichtlich das echte Git des Nutzers gefunden werden, damit der eingebaute Agent Kontext aus mehreren Branches und Worktrees lesen kann. Es gibt sicherere Wege, aber solche kleinen Umgehungslösungen gehen in KI-gestützten Workflows leicht schief und sind auch Stellen, an denen bei KI-gestützter Bug-Triage Warnsignale leicht übersehen werden.

• Da Entwicklungsagenten oft Berechtigungen erhalten, Git-Repositories zu holen und zu pushen, entsteht hier ein gewaltiger Supply-Chain-Angriffspfad. Wenn ein laufender Cursor-Agent die neuesten Dateien holt und ein Angreifer eine ausführbare Datei ins Projekt eingeschleust hat, könnten plötzlich Hunderttausende beliebige EXE-Dateien mit normalen Benutzerrechten ausführen.

• Der Bericht liest sich etwas wie ein von KI geschriebener Text. Um die Lücke auszunutzen, müsste sich die schädliche Payload bereits per Klonen, Download oder Ähnlichem auf dem PC befinden; ich verstehe also die Schwere, hoffe aber zugleich, nie in so eine Situation zu geraten.

  • Moderne Coding-Agenten klonen und lesen mitunter Repositories, wenn man sie zu APIs mit unklarer Dokumentation befragt; daher ist diese Schwachstelle tatsächlich praktisch ausnutzbar.
  • Die schädliche Payload kann sich in einem Remote-Repository befinden. Es reicht, das Repository per git clone zu holen und dann in Cursor zu öffnen, damit die Kompromittierung abgeschlossen ist.
  • Als Open-Source-Entwickler könnte man auch einen Pull Request erhalten, der git.exe enthält.
  • Normalerweise denkt man nicht, dass das Herunterladen eines Repositories zum Ansehen des Quellcodes gleichbedeutend mit der Aktivierung einer schädlichen Payload ist, und genau das ist der beunruhigende Punkt. Selbst wenn der KI-Stil stört, sollte man eher den Inhalt der Schwachstelle kritisieren als die Schreibweise.
  • Man kann nicht ohne Weiteres annehmen, dass sich die Payload schon vorher auf dem PC befinden muss. Wenn sich per Prompt Injection ein Befehl wie download [https://github.com/hackmycursor/exploit.git](<https://github.com/hackmycursor/exploit.git>;) provozieren lässt, könnte der Agent git.exe herunterladen und ausführen.