DuneSlide – Was hat Cursor mit Dune zu tun?

Anfang Juli hat Cato AI Labs zwei kritische Schwachstellen in der weit verbreiteten Cursor-IDE entdeckt. Die Schwachstellen wurden auf den Namen DuneSlide getauft und erreichen auf der CVSS Skala einen Wert von 9.8/10, damit zählen sie als kritische Sicherheitslücken mit umgehendem Handlungsbedarf. 🚨

Dadurch war es dem KI-Agenten möglich, per Remote Code Execution (RCE) aus seiner internen Cursor Sandbox auszubrechen. Cursor 2.x wird mit einer internen Sandbox ausgeliefert, damit der KI-Agent automatisch Konsolenbefehle ausführen kann, ohne dass der Nutzer permanent auf Akzeptieren/Weiter klicken muss. Damit wollen die Entwickler Approval-Fatigue verhindern und gleichzeitig unterbinden, dass Außenstehende durch Prompt-Injection und RCE einfach Schaden anrichten bzw. Zugriff auf interne Systeme erhalten.

Die erste Schwachstelle kommt durch die Art der Sicherheitsvorkehrungen der Sandbox zustande: Wenn Cursor Befehle ausführt, beschränkt das System deren Schreibrechte auf den aktuellen Projektordner, damit Dateien außerhalb des Projekts nicht verändert werden können.

Das Problem dabei: Der Befehl zum Ausführen von Terminal-Aktionen besitzt eine Einstellung für das aktuelle Working-Directory. Legt die KI diese Einstellung auf einen anderen Ordner fest, erlaubt das Schutzsystem blind auch den Schreibzugriff auf diesen neuen Pfad.

Das kann in erster Linie dazu führen, dass der KI-Agent Dateien an Stellen bearbeitet, an denen er das gar nicht darf. Das allein kann beim Entwickeln schon zu Problemen führen – etwa wenn plötzlich Dateien oder auch Regeln für die KI selbst von dieser geändert werden können.

Im schlimmsten Fall hat ein Angreifer von außen dadurch leichtes Spiel, Schreibzugriff auf Dateien außerhalb des Projekts zu bekommen. Über manipulierte MCP-Server oder versteckte Prompt-Injections in Websuchen kann er Befehle einschleusen, die diese Schwachstelle ausnutzen. Dadurch kann Schadcode an beliebigen, kontrollierbaren Stellen im System eingeschleust und ausgeführt werden –> RCE.

Die zweite Schwachstelle nutzt Verknüpfungen 🔗, etwas, das man normalerweise aus der Ferne nicht erstellen kann. Hier dient die KI als Brückenkopf.

Ein Angreifer bringt die KI über eine Prompt-Injection (MCP, Websuche) dazu, eine Verknüpfung (Symlink) innerhalb des Projektordners anzulegen. Diese zeigt jedoch auf eine Datei außerhalb des Projektordners. Cursor prüft solche Verknüpfungen immer, z.B. etwa darauf, wohin sie zeigen, um sicherzustellen, dass nichts außerhalb des Projektordners geschrieben wird. Wenn diese Überprüfung fehlschlägt, weil z. B. Leserechte fehlen oder das Ziel noch nicht existiert, fällt Cursor auf den Pfad der Verknüpfung selbst zurück. Wenn eine von einem Angreifer erstellte Verknüpfung nur für Schreibzugriffe gedacht ist, kann Cursor sie nicht überprüfen und nimmt fälschlicherweise an, dass die Zieldatei sicher im Projektordner liegt.

Wenn die KI anschließend die Datei über die Verknüpfung schreibt, wird der Schreibzugriff auf die externe Datei umgeleitet – und wir haben das gleiche Problem wie oben: Das Sicherheitssystem von Cursor ist ausgeschaltet, und Dateien können an beliebigen Stellen geschrieben und ausgeführt werden –> RCE. ⚠️