Cursor speichert API-Schlüssel nicht in einem geschützten Speicher, wodurch jede Erweiterung darauf zugreifen kann. Cursor war sich dieser Sicherheitslücke bewusst, hat sie aber nicht behoben.

Executive Summary

Die Sicherheitsforscher von LayerX haben herausgefunden, dass jede Erweiterung des beliebten KI-Entwicklungstools Cursor auf die API-Schlüssel und Sitzungstoken des Entwicklers zugreifen kann, was zu einer vollständigen Kompromittierung der Anmeldeinformationen führt, ohne dass dafür eine Interaktion oder Aktivität des Benutzers erforderlich ist. 

LayerX stellte fest, dass Cursor die Schlüssel nicht in einem geschützten Speicher ablegt, für Die Cursor-Erweiterung kann diesen Zugriff ausführen. Daher ist jeder Cursor-Benutzer anfällig für den Diebstahl von API-Schlüsseln durch manipulierte Cursor-Erweiterungen.

Die Ausnutzung dieser Sicherheitslücke kann zur Offenlegung von Sitzungstoken und API-Schlüsseln, zum unbefugten Zugriff auf Cursor-Backend-Dienste und zum Datendiebstahl durch Benutzeridentitätsdiebstahl führen.

LayerX meldete diese Sicherheitslücke an Cursor. Cursor bestätigte das Problem, wies aber darauf hin, dass die Definition der Vertrauensgrenzen in der Verantwortung des Nutzers liege. Bislang wurde das Problem von Cursor nicht behoben.

 

Cursor-API-Schlüssel werden in einer offenen, lokalen Datenbank gespeichert.

Cursor, eine beliebte KI-gestützte Entwicklungsumgebung, weist eine schwerwiegende Sicherheitslücke in der Zugriffskontrolle auf (CVSS 8.2) wodurch jede installierte Erweiterung auf sensible, lokal gespeicherte Anmeldeinformationen zugreifen kann.

Anders als bei herkömmlichen Sicherheitspraktiken, bei denen Geheimnisse wie API-Schlüssel und Sitzungstoken in geschützten Speichern (z. B. im Schlüsselbund des Betriebssystems) abgelegt werden, speichert Cursor diese Anmeldeinformationen in einer lokalen SQLite-Datenbank:

` ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb `

Cursor erzwingt keine Zugriffskontrollen zwischen Erweiterungen und dieser Datenbank. Daher kann jede Erweiterung – unabhängig von ihren deklarierten Berechtigungen – direkt darauf zugreifen und sensible Daten extrahieren.

Dadurch entsteht ein mächtiges Angriffswerkzeug: Eine bösartige oder kompromittierte Cursor-Erweiterung kann unbemerkt API-Schlüssel und Sitzungstoken exfiltrieren und so die Übernahme von Konten, den Zugriff auf Daten und finanziellen Missbrauch ermöglichen.

 

Auswirkungen

Diese Sicherheitslücke ermöglicht die vollständige Kompromittierung von Anmeldeinformationen ohne jegliche Benutzerinteraktion (abgesehen von der Installation einer Erweiterung), was zu Folgendem führt:

  • Offenlegung von Sitzungstoken und API-Schlüsseln
  • Unbefugter Zugriff auf Cursor-Backend-Dienste
  • Kompromisse bei der Integration von Drittanbietern (z. B. OpenAI, Anthropic, Google)
  • Benutzeridentitätsdiebstahl und Datenzugriff

Nachgelagerte Risiken (Beispiel: Diebstahl des OpenAI-API-Schlüssels)

Wenn ein Angreifer den OpenAI-API-Schlüssel eines Opfers erlangt, kann er Folgendes tun:

  • Ausführung von API-Aufrufen, die dem Opfer in Rechnung gestellt werden → finanzieller Verlust
  • Zugriffsaufforderungen, Vervollständigungen und Metadaten → Datenoffenlegung
  • Missbrauchen Sie die API für weitere Angriffe oder Automatisierung.
  • Möglicherweise lassen sich sensible Informationen aus früheren Interaktionen ableiten

Da diese Schlüssel oft einen umfassenden Zugriff ermöglichen, reichen die Auswirkungen über Cursor selbst hinaus und erstrecken sich auf das gesamte KI- und Entwicklungsökosystem des Benutzers.

 

Technische Übersicht

Lassen Sie uns ein realistisches Angriffsszenario aus der Perspektive des Angreifers durchgehen.

Abbildung 1. Ausnutzungsablauf

Schritt 1: Vorbereitung der schädlichen Erweiterung

Ein Angreifer erstellt eine scheinbar harmlose Cursor-Erweiterung – beispielsweise ein Produktivitätstool, ein Design oder ein Hilfsprogramm. Sie fordert keine verdächtigen Berechtigungen an und scheint sicher zu installieren zu sein.

Aus der Sicht des Nutzers sieht nichts ungewöhnlich aus.

Schritt 2: Der Benutzer installiert die Erweiterung

Ein Entwickler installiert die Erweiterung von einem Marktplatz oder einem GitHub-Repository.

Es gibt:

  • Keine Warnung
  • Keine Berechtigungsabfrage bezüglich des Zugriffs auf Anmeldeinformationen
  • Kein Hinweis auf ein Risiko

An diesem Punkt verfügt der Angreifer über die Möglichkeit zur Codeausführung innerhalb der Cursor-Erweiterungsumgebung.

Schritt 3: Zugriff auf sensible Daten

Cursor speichert sensible Daten in einer oben erwähnten lokalen SQLite-Datenbank. Diese Datenbank enthält:

  • Sitzungstoken
  • API-Schlüssel (z. B. OpenAI)
  • Andere Authentifizierungsartefakte

Da die Zugriffskontrolle nicht durchgesetzt wird, kann die Erweiterung diese Datenbank direkt öffnen und abfragen. Es sind keine besonderen Berechtigungen erforderlich.

Schritt 4: Extraktion der Anmeldeinformationen

Die Erweiterung analysiert die Datenbank und extrahiert:

  • API-Schlüssel
  • Sitzungstoken
  • Möglicherweise zwischengespeicherte Konfiguration oder Metadaten

Abbildung 2. Beispiel einer Datenbankabfrage aus der PoC-Erweiterung

Da die Daten im Klartext gespeichert (oder unzureichend geschützt) sind, ist die Extraktion unkompliziert.

Schritt 5: Stille Exfiltration

Die Erweiterung sendet die gestohlenen Zugangsdaten an einen vom Angreifer kontrollierten Server, was mit einem einfachen Fetch-Befehl erfolgen kann. Dies geschieht unbemerkt:

  • Keine Benutzerinteraktion erforderlich
  • Keine sichtbaren Änderungen an der Benutzeroberfläche
  • Keine Benachrichtigungen

Schritt 6: Nach der Ausbeutung

Der Angreifer besitzt nun gültige Zugangsdaten.

Warum dies einen hohen Schweregrad hat

Diese Sicherheitslücke ist besonders gefährlich, weil:

  • Keine Berechtigungen erforderlich
  • Nach der Installation ist keine Benutzerinteraktion erforderlich. 
  • Geringe Angriffskomplexität
  • Hohe Vertraulichkeitsauswirkungen

Um zu verdeutlichen, wie leicht dies ausgenutzt werden kann, haben wir Folgendes erstellt: PoC-Erweiterung und ein Demovideo:

 

Offenlegungszeitplan:

Der Bericht zeigt zwar, dass Erweiterungen auf die lokale SQLite-Datenbank mit den Anmeldeinformationen zugreifen können, dieser Zugriff ist jedoch auf den lokalen Rechner beschränkt, auf dem der Benutzer die Erweiterung bereits installiert und ihr Berechtigungen erteilt hat. Dies entspricht der Vertrauensgrenze jeder anderen lokalen Anwendung – bösartige Erweiterungen mit Zugriff auf das lokale Dateisystem könnten potenziell auf verschiedene Anwendungsdatenspeicher zugreifen.

  • Fix-StatusNicht behoben. Di., 28. Apr. 2026 

Empfohlene Sanierungsmaßnahmen

Um dieses Problem angemessen zu beheben, muss Cursor Folgendes tun:

  • Gewährleisten Sie eine strikte Trennung zwischen Erweiterungen und der Speicherung sensibler Anmeldeinformationen.
  • Sensible Anmeldeinformationen sollten über eine sichere, verschlüsselte Speicherschicht oder einen systemweiten Schlüsselbund (z. B. macOS Keychain, Windows Credential Manager) verwaltet werden.