Cursor nie przechowuje kluczy API w chronionym magazynie, co oznacza, że ​​każde rozszerzenie ma do nich dostęp. Cursor wiedział o tej luce, ale jej nie naprawił.

Streszczenie

Badacze ds. bezpieczeństwa firmy LayerX odkryli, że każde rozszerzenie popularnego narzędzia do tworzenia sztucznej inteligencji Cursor może uzyskać dostęp do kluczy API i tokenów sesji programisty, co może doprowadzić do całkowitego naruszenia poświadczeń bez konieczności jakiejkolwiek interakcji lub działania ze strony użytkownika. 

Firma LayerX odkryła, że ​​ponieważ Cursor nie przechowuje kluczy w chronionym magazynie, każdy Rozszerzenie Cursor może wykonać ten dostęp. W rezultacie każdy użytkownik Cursor jest narażony na kradzież klucza API przez nieuczciwe rozszerzenia Cursor.

Wykorzystanie tej luki może doprowadzić do ujawnienia tokenów sesji i kluczy API, nieautoryzowanego dostępu do usług zaplecza Cursor oraz kradzieży danych poprzez podszywanie się pod użytkownika.

Firma LayerX zgłosiła tę lukę w zabezpieczeniach firmie Cursor. Cursor odpowiedział, że dostrzega problem, ale to użytkownik jest odpowiedzialny za zdefiniowanie granicy zaufania. Do tej pory Cursor nie rozwiązał tego problemu.

 

Klucze API kursora są przechowywane w otwartej, lokalnej bazie danych

Cursor, popularne środowisko programistyczne oparte na sztucznej inteligencji, zawiera lukę w zabezpieczeniach kontroli dostępu o wysokim stopniu zagrożenia (CVSS 8.2) umożliwiający każdemu zainstalowanemu rozszerzeniu dostęp do poufnych danych uwierzytelniających przechowywanych lokalnie.

W przeciwieństwie do standardowych praktyk bezpieczeństwa, w których poufne informacje, takie jak klucze API i tokeny sesji, są przechowywane w chronionym magazynie (np. w pękach kluczy systemu operacyjnego), Cursor przechowuje te dane uwierzytelniające w lokalnej bazie danych SQLite:

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

Co istotne, Cursor nie wymusza granic kontroli dostępu między rozszerzeniami a tą bazą danych. W rezultacie każde rozszerzenie – niezależnie od zadeklarowanych uprawnień – może bezpośrednio odczytywać dane i wyodrębniać poufne dane.

Tworzy to potężny, pierwotny atak: złośliwe lub zainfekowane rozszerzenie Cursor może po cichu wykraść klucze API i tokeny sesji, umożliwiając przejęcie konta, dostęp do danych i nadużycia finansowe.

 

Wpływ

Ta luka w zabezpieczeniach umożliwia całkowite przejęcie uprawnień bez żadnej interakcji ze strony użytkownika (poza zainstalowaniem rozszerzenia), co może skutkować:

  • Ujawnienie tokenów sesji i kluczy API
  • Nieautoryzowany dostęp do usług zaplecza Cursor
  • Naruszenie integracji stron trzecich (np. OpenAI, Anthropic, Google)
  • Podszywanie się pod użytkownika i dostęp do danych

Ryzyko downstream (przykład: kradzież klucza API OpenAI)

Jeśli atakujący uzyska klucz API OpenAI ofiary, może:

  • Wykonaj wywołania API, za które zostanie obciążona ofiara → strata finansowa
  • Dostęp do monitów, uzupełnień i metadanych → udostępnianie danych
  • Nadużywanie interfejsu API w celu dalszych ataków lub automatyzacji
  • Potencjalnie wywnioskuj wrażliwe informacje z poprzednich interakcji

Ponieważ klucze te często zapewniają szeroki dostęp, ich wpływ wykracza poza sam Cursor i rozciąga się na cały ekosystem sztucznej inteligencji i rozwoju użytkownika.

 

Przegląd techniczny

Przyjrzyjmy się realistycznemu scenariuszowi ataku z perspektywy atakującego.

Rysunek 1. Przepływ eksploatacji

Krok 1: Przygotowanie złośliwego rozszerzenia

Atakujący tworzy pozornie nieszkodliwe rozszerzenie Cursor – być może narzędzie do pracy, motyw lub narzędzie pomocnicze. Nie wymaga ono żadnych podejrzanych uprawnień i wydaje się bezpieczne do zainstalowania.

Z punktu widzenia użytkownika nic nie wygląda dziwnie.

Krok 2: Użytkownik instaluje rozszerzenie

Programista instaluje rozszerzenie ze sklepu lub repozytorium GitHub.

Jest:

  • Bez ostrzeżenia
  • Brak monitu o pozwolenie związanego z dostępem do danych uwierzytelniających
  • Brak oznak ryzyka

W tym momencie atakujący wykonuje kod w środowisku rozszerzenia Cursor.

Krok 3: Dostęp do poufnych danych

Kursor przechowuje poufne dane w lokalnej bazie danych SQLite, o której mowa powyżej. Baza ta zawiera:

  • Tokeny sesji
  • Klucze API (np. OpenAI)
  • Inne artefakty uwierzytelniania

Ze względu na brak kontroli dostępu rozszerzenie może bezpośrednio otwierać i przeszukiwać tę bazę danych. Nie są wymagane żadne specjalne uprawnienia.

Krok 4: Ekstrakcja danych uwierzytelniających

Rozszerzenie analizuje bazę danych i wyodrębnia:

  • Klucze API
  • Tokeny sesji
  • Możliwe, że buforowana konfiguracja lub metadane

Rysunek 2. Przykład zapytania do bazy danych z rozszerzenia PoC

Ponieważ dane są przechowywane w postaci jawnego tekstu (lub nie są wystarczająco zabezpieczone), ich ekstrakcja jest prosta.

Krok 5: Cicha eksfiltracja

Rozszerzenie wysyła skradzione dane uwierzytelniające na serwer kontrolowany przez atakującego, co można zrobić za pomocą prostego pobrania. Dzieje się to w sposób dyskretny:

  • Nie jest wymagana żadna interakcja użytkownika
  • Brak widocznych zmian w interfejsie użytkownika
  • Brak alertów

Krok 6: Po eksploatacji

Teraz atakujący posiada ważne dane uwierzytelniające.

Dlaczego jest to tak poważne

Ta luka jest szczególnie niebezpieczna, ponieważ:

  • Nie są wymagane żadne uprawnienia
  • Po instalacji nie jest wymagana żadna interakcja użytkownika 
  • Niska złożoność ataku
  • Wysoki wpływ na poufność

Aby pokazać, jak łatwo można to wykorzystać, stworzyliśmy Rozszerzenie PoC i film demonstracyjny:

 

Harmonogram ujawnienia:

Chociaż raport pokazuje, że rozszerzenia mogą uzyskać dostęp do lokalnej bazy danych SQLite zawierającej dane uwierzytelniające, dostęp ten jest ograniczony do komputera lokalnego, na którym użytkownik zainstalował rozszerzenie i udzielił mu uprawnień. Stanowi to tę samą granicę zaufania, co w przypadku każdej innej aplikacji lokalnej – złośliwe rozszerzenia z dostępem do lokalnego systemu plików mogłyby potencjalnie uzyskać dostęp do różnych magazynów danych aplikacji.

  • Napraw status: Nie naprawiono. Wt., 28 kwietnia 2026 r. 

Zalecane środki zaradcze

Aby właściwie rozwiązać ten problem, Cursor musi:

  • Wyegzekwuj ścisłą izolację rozszerzeń i poufnych danych uwierzytelniających.
  • Poufne dane uwierzytelniające powinny być obsługiwane za pośrednictwem bezpiecznej, szyfrowanej warstwy pamięci masowej lub pęku kluczy na poziomie systemu (np. pęku kluczy macOS, menedżera poświadczeń systemu Windows).