DuneSlide: Zwei kritische RCE-Sicherheitsschwachstellen durch Zero-Click-Prompt-Injection in der Cursor-IDE

Kurzfassung:

Cato AI Labs hat zwei kritische Remote Code Execution (RCE) Sicherheitsschwachstellen in Cursor IDE entdeckt, der beliebten Entwicklungsumgebung, die laut Cursor von über der Hälfte der Fortune 500 genutzt wird. Beide RCE-Schwachstellen, die wir als „DuneSlide“ bezeichnen, erreichten einen CVSS-Wert von 9,8, ermöglichen das Verlassen der Sandbox-Umgebung der IDE und wurden mit den CVE-IDs CVE-2026-50548 und CVE-2026-50549 versehen.

Zusammen zeigen diese Schwachstellen, wie Prompt-Injection über die LLM-Ebene hinausreicht und klassische Schwachstellen in Codepfaden offenlegen kann, die traditionell nicht als Teil der Angriffsfläche betrachtet wurden.

Die Ausnutzung einer dieser kritischen Schwachstellen erlaubt einem Angreifer, zentrale Systemdateien (wie die Cursorsandbox-Binärdatei) zu überschreiben, wodurch Sandbox-Befehle in nicht-sandbox RCE umgewandelt werden und eine vollständige Kompromittierung des Systems, sowohl auf dem Host-Rechner als auch in verbundenen SaaS-Arbeitsumgebungen, erfolgt.

Zusammenfassung

• Kritische Sicherheitslücken entdeckt: Cato AI Labs hat zwei unterschiedliche, kritische Schwachstellen in der Cursor IDE identifiziert, die zu nicht-sandboxed RCEs auf dem Rechner des Nutzers führen.
• Beliebiges Schreiben von Dateien durch Zero-Click-Prompt-Injection Diese voneinander unabhängigen Architekturschwachstellen eröffnen Angreifern die Möglichkeit, durch Zero-Click-Prompt-Injections beliebige Dateien auf dem lokalen System des Entwicklers zu schreiben.
• Sandbox-Ausbruch und RCE Durch die Nutzung dieser Primitiven kann ein Bedrohungsakteur aus der Terminal-Sandbox ausbrechen, vollständige RCE erreichen und einen kompletten Systemkompromiss erzielen.
• Zero-Click-Angriffsvektor: Der Exploit erfordert weder vorherige Benutzerrechte noch eine bestimmte Benutzeraktion. Der Angriff wird ausgelöst, wenn ein Opfer eine harmlose Eingabe vornimmt, durch die versehentlich eine von einem Angreifer kontrollierte Nutzlast aus einer nicht vertrauenswürdigen Quelle – beispielsweise einem MCP-Server oder einem Web-Suchergebnis – übernommen wird.

Technische Übersicht

Die Cursor-Sandbox und der Angriffsvektor

Cursor 2.x wurde standardmäßig mit einer automatischen Ausführung von Terminalbefehlen innerhalb einer Sandbox ausgeliefert, die ohne Prompt des Benutzers funktioniert. Dieses Feature wurde entwickelt, um Genehmigungsüberlastung zu verhindern und gleichzeitig Bedrohungsakteuren zu erschweren, eine einfache Prompt-Injection in ein RCE umzuwandeln.

Schwachstelle Nr. 1: Manipulation des Working Directory Parameters

Die erste Sicherheitslücke ergibt sich daraus, wie die Sandbox ihre Sicherheitsgrenzen auf der Grundlage von Tool-Parametern festlegt. Wenn ein Sandbox-Befehl ausgeführt wird, erstellt Cursor eine Seatbelt-Richtlinie, die Schreibzugriffe auf das aktuelle Arbeitsverzeichnis erlaubt.

• Während das Standardverhalten darin besteht, das Arbeitsverzeichnis der Befehlsausführung auf das Projektverzeichnis zu setzen, ist das working_directory ein optionaler Parameter des run_terminal_cmd-Tools.
• Der Fehler besteht darin, dass, wenn das LLM einen Nicht-Standardwert für diesen Parameter zuweist, dieser Pfad blind zur Liste der erlaubten Schreibpfade des Sandboxes hinzugefügt wird.
• Eine Prompt-Injection (bereitgestellt etwa über eine harmlos erscheinende Anfrage an einen MCP-Server oder ein manipuliertes Websuchergebnis) kann das LLM dazu veranlassen, working_directory auf einen von einem Angreifer kontrollierten Pfad außerhalb des Projektverzeichnisses zu setzen.
• Durch das Überschreiben der ausführbaren Datei cursorsandbox (/Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox) stellt der Angreifer sicher, dass nachfolgende Befehle ohne Sandbox-Beschränkungen ausgeführt werden. Dadurch führen weitere Anweisungen innerhalb derselben Prompt-Injection zu einer Remote Code Execution (RCE) außerhalb der Sandbox.
• Weitere anfällige Pfade sind ~/.zshrc, ~/.zshenv oder ~/Library/LaunchAgents.

Traditionell kann ein Remote-Angreifer das Arbeitsverzeichnis einer Sandbox-Operation nicht kontrollieren. Da Coding-Agents jedoch ein einzigartiges Softwarestück sind, dient in dieser Schwachstelle eine Prompt-Injection als Zugang zu diesem Teil des Codes.

Schwachstelle Nr. 2: Symlink-Kanonisierungsfehler

Die zweite Schwachstelle ist völlig unabhängig von der ersten und liegt in den Randfällen der Dateipfadauflösung von Cursor. Sie ermöglicht Angreifern den Schreibschutz für Bereiche außerhalb des zulässigen Bereichs mithilfe symbolischer Links umgehen.

• Eine Prompt-Injection (etwa über eine harmlos erscheinende Anfrage an einen MCP-Server oder ein manipuliertes Websuchergebnis) kann den Cursor Agent anweisen, innerhalb des Projektverzeichnisses einen symbolischen Link (Symlink) zu erstellen, der auf eine Datei außerhalb des Projektverzeichnisses verweist.
• Standardmäßig versucht der Cursor-Agent, Pfade zu kanonisieren (Symlinks aufzulösen), um ihren tatsächlichen Standort zu bestimmen und zu überprüfen, ob sie sich im Projektverzeichnis befinden.
• Die Sicherheitslücke entsteht, weil die Kanonisierung-Logik einen gefährlichen Fallback enthält: Wenn die Kanonisierung fehlschlägt (beispielsweise wenn der Pfad nicht existiert oder wenn für eines der Verzeichnisse in diesem Pfad keine Leserechte vorhanden sind), greift Cursor auf den ursprünglichen Symlink-Pfad innerhalb des Projektverzeichnisses zurück.
• Ein Angreifer kann dann einen schreibgeschützten Symlink erstellen, wodurch Cursor gezwungen wird anzunehmen, dass der aufgelöste Pfad der Symlink-Pfad ist, anstatt der Zielpfad. Dabei versagt die Erkennung, dass das endgültige Ziel außerhalb der zulässigen Grenzen liegt, wodurch der Angreifer erneut auf die ausführbare Datei cursorsandbox verlinken kann (/Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox).
• Mit dem Write-Tool überschreibt der Angreifer anschließend über den symbolischen Link die externe Datei, wodurch die Sandbox für nachfolgende Befehle innerhalb derselben Prompt-Injection außer Kraft gesetzt wird und es zu einer Remote Code Execution (RCE) kommt.

In den meisten klassischen Softwareanwendungen kann ein externer Angreifer keine Symlinks auf dem Computer eines Opfers aus der Ferne erstellen. In diesem Fall verwandelte eine Prompt-Injection den Cursor-Agenten in einen Brückenkopf für nicht triviale Operationen, die zu einem vollständigen Systemkompromiss führen.

Verantwortungsvolle Offenlegung

Cato AI Labs setzt sich für die Sicherheit des KI-Ökosystems ein und hat sich bei DuneSlide an die üblichen Richtlinien für verantwortungsvolle Offenlegung gehalten:

• 19. Februar: Schwachstellen wurden dem Cursor-Team gemeldet.
• 23. Februar: Die Schwachstellen wurden abgelehnt. Die Begründung: Das Bedrohungsmodell von Cursor berücksichtigt keinen Missbrauch des MCP-Servers, selbst in Fällen, in denen der MCP-Server eine standardmäßige, harmlose Integration ist, wie der offizielle Linear.app-Arbeitsbereich.
• 26. Februar: Eskalation beider Probleme direkt an das Sicherheitsteam von Cursor aufgrund der Schwere der Probleme eingereicht. Das Sicherheitsteam hat sie wieder geöffnet und mit der Priorisierung der gemeldeten Schwachstellen begonnen.
• 1. April: Das Cursor-Team bestätigte, dass die Behebung der Schwachstelle im Arbeitsverzeichnis mit dem Cursor 3.0-Client (veröffentlicht am 2. April) ausgeliefert wird.
• 1. Juni: Das Cursor-Team bestätigte, dass die Behebung der Schwachstelle im Linkziel ebenfalls mit Cursor 3.0 ausgeliefert wurde.
• 5. Juni: IDs CVE-2026-50548 und CVE-2026-50549 wurden zugewiesen, was die kritische Schwere der Schwachstellen bestätigt.

Fazit

DuneSlide verdeutlicht die spezifischen architektonischen Gefahren, die mit der Bereitstellung autonomer Umgebungen zur Befehlsausführung für große Sprachmodelle (LLMs) verbunden sind. Während Sandboxing eine notwendige Verteidigung ist, beweisen unterschiedliche Mängel in der Parametervalidierung und in Randfällen der Pfadauflösung, dass Zero-Click-Prompt-Injections geschickt isolierte Logikfehler ausnutzen können, um eine vollständige Systemübernahme durchzuführen. Hätten diese Probleme singuläre Fälle von Kompromittierungen durch Prompt-Injections gewesen, hätten wir sie möglicherweise spezifischen Schwachstellen zugeschrieben. Cato AI Labs ist jedoch dabei, Schwachstellen in allen gängigen Codierungsagenten verantwortungsbewusst offenzulegen und hebt hervor, dass ein systematischerer Ansatz zum Schutz erforderlich ist. Bleiben Sie dran.