Mindgard beschreibt den technischen Kern der Schwachstelle als ungewöhnlich simpel. Beim Öffnen eines Projekts versuche Cursor, Git-Binärdateien an mehreren Speicherorten zu finden. Einer dieser Orte sei der Arbeitsbereich des Projekts selbst. Wird dort im Repository-Stamm eine schädliche git.exe platziert, führe der Cursor-Client diese Datei laut dem Blogbeitrag automatisch im Zuge seiner Logik zur Pfadauflösung aus — ohne Warnung und ohne Zustimmung des Nutzers.
Praktisch läuft der Angriff laut Mindgard auf ein vergiftetes Repository hinaus, das weniger Zwischenschritte erfordert als ähnliche Angriffe sonst. Ein Angreifer müsse lediglich ein präpariertes Repository veröffentlichen, das die manipulierte git.exe enthält. Öffnet ein Entwickler dieses Projekt in Cursor, könne der enthaltene Code mit dessen Benutzerrechten ausgeführt werden.
Für einen Machbarkeitsnachweis ersetzte Mindgard die Datei durch die Windows-Rechner-Anwendung, benannte sie in git.exe um und legte sie im Wurzelverzeichnis des Repositories ab. Schon das bloße Starten von Cursor mit diesem Repository habe genügt, um die Datei auszuführen, schreibt das Unternehmen.
Breiten Raum widmet Mindgard auch dem Ablauf der Offenlegung. Nach Angaben der Firma wurde die Schwachstelle am 15. Dezember des vergangenen Jahres an Cursor gemeldet und in den folgenden sechs Monaten mehrfach erneut angesprochen. Mindgard erklärt, man habe die Details per E-Mail, über LinkedIn und über das Bug-Bounty-Programm HackerOne übermittelt. Cursor habe den Bericht jedoch weder akzeptiert noch das Problem behoben oder irgendeine Form der Lösung bereitgestellt, so das Unternehmen.
Sieben Monate nach der ersten Meldung gebe es keinen Hinweis darauf, dass Nutzer geschützt würden, dass eine Behebung laufe oder dass betroffene Organisationen informiert worden seien, zitiert der Bericht die eigene Begründung für die vollständige Veröffentlichung. Deshalb habe sich Mindgard entschieden, alle Details offenzulegen, damit Organisationen ihre Gefährdung bewerten und Gegenmaßnahmen treffen könnten.
Gegenüber Dark Reading bestätigte ein Sprecher von Cursor am 13. Juli: „Ich kann bestätigen, dass wir daran arbeiten und uns entsprechend bei Mindgard zurückmelden werden.“ Weitere technische Details von Cursor selbst enthält der Bericht nicht.
Für Unternehmen mit verwalteten Windows-Systemen empfiehlt Mindgard, per AppLocker oder Windows App Control die Ausführung von git.exe aus Entwickler-Arbeitsverzeichnissen zu blockieren. Für nicht verwaltete Systeme formuliert das Unternehmen die Empfehlung deutlich schärfer: Bis ein Patch vorliegt, sollten nicht vertrauenswürdige Repositories nur in einer isolierten virtuellen Maschine, in Windows Sandbox oder einer anderen wegwerfbaren Umgebung geöffnet werden. Von Sperrlisten auf Basis von Dateihashes rät Mindgard für diesen Fall ausdrücklich ab.
Aaron Portnoy, Chief Product Officer bei Mindgard, sagte Dark Reading, die Schwachstelle sei leicht auszunutzen und ebenso leicht zu beheben. Portnoy, der nach Angaben des Berichts die ersten sechs Pwn2Own-Wettbewerbe bei der Zero Day Initiative entworfen und geleitet hat, hält es für sehr wahrscheinlich, dass ein Bedrohungsakteur die Lücke praktisch einsetzen würde, wenn er ein konkretes Ziel ins Visier nehmen wolle. Nach seiner Darstellung würde jede beliebige Schadsoftware, sofern sie einfach in git.exe umbenannt wird, beim Öffnen des Repositories auf dem Rechner des Entwicklers ohne Einschränkung und ohne Benachrichtigung starten. Selbst ohne Zugriff auf den Quellcode lasse sich die notwendige Änderung seiner Einschätzung nach in etwa fünf Minuten per Reverse Engineering finden.