CursorJacking – rozszerzenia mają dostęp do bazy SQLite z kluczami API użytkowników

Gdy myślimy o bezpieczeństwie AI, często przychodzą nam do głowy hasła takie jak “jailbreaking”, “prompt injection” i zabezpieczenia po stronie samych modeli językowych. Warto jednak pamiętać, że “narzędzia AI” mają również problemy niezwiązane wcale z AI.

Znany wielu programistom, wspierany przez LLM edytor kodu Cursor przechowuje klucze API w bazie dostępnej dla zainstalowanych rozszerzeń, co oznacza, że każde z nich może potencjalnie je odczytać.

TLDR

• Badacze z LayerX odkryli, że Cursor przechowuje poświadczenia w bazie SQLite dostępnej dla zainstalowanych rozszerzeń.
• Potencjalny atak polega na odczycie lokalnej bazy i eksfiltracji danych przez rozszerzenie, które nie potrzebuje specjalnych uprawnień. W praktyce umożliwia to kradzież tokenów sesji oraz kluczy do usług takich jak OpenAI czy Anthropic.
• Do ataku wystarczy zainstalowanie złośliwej wtyczki przez użytkownika
• Podatność została zgłoszona do producenta, ale nie została uznana za problem wymagający naprawy.

Badacze bezpieczeństwa z LayerX odkryli, że Cursor pozwala każdemu rozszerzeniu uzyskać dostęp do kluczy API i tokenów sesji użytkownika, co może prowadzić do przejęcia jego poświadczeń bez bezpośredniej interakcji (wystarczy zainstalowanie złośliwego rozszerzenia).

Cursor bazuje na otwartym kodzie Visual Studio Code (sam nie jest otwartoźródłowy), jednak wprowadza kluczową funkcję – integrację z AI. Część użytkowników korzysta w tym celu z konta Cursor i pracuje z modelami hostowanymi przez twórców narzędzia. Można także korzystać z usług zewnętrznych dostawców (np. OpenAI, Anthropic czy Google) przez własny klucz API.

W obu wariantach oznacza to, że poświadczenia użytkownika uwierzytelniające go w danej usłudze są zapisywane lokalnie przez aplikację. Nie trafiają one jednak do systemowego menadżera sekretów (np. macOS Keychain, Windows Credential Manager czy GNOME Keyring). Zamiast tego Cursor przechowuje je poświadczenia w lokalnej bazie danych SQLite, dostępnej pod ścieżką:

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

W rezultacie każde rozszerzenie Cursor może bezpośrednio z bazy odczytywać poświadczenia użytkownika. A ten scenariusz brzmi wystarczająco źle, gdy wiemy jak niebezpieczne potrafią być (lub stać się) różnorodne wtyczki.

Atakujący może stworzyć pozornie nieszkodliwe rozszerzenie do Cursor, które nie żądając żadnych “podejrzanych” uprawnień będzie wykradać poświadczenia użytkownika. Może również wdrożyć złośliwą aktualizację do istniejącej wtyczki, np. atakując jej twórcę bądź wykupując od niego projekt.

Z perspektywy użytkownika nic nie wygląda nietypowo. Instaluje “niewinne” rozszerzenie z marketplace lub repozytorium na GitHub. Oprócz samej instalacji nie wykonuje żadnej innej interakcji z wtyczką.

Rozszerzenie otwiera plik z bazą Cursor i wykonuje zapytanie SQL. Nie są do tego wymagane żadne specjalne uprawnienia. W ten sposób pozyskać można klucze API, tokeny sesji i potencjalnie także inne metadane/konfiguracje użytkownika.

Na koniec wystarczy, że rozszerzenie wyśle wykradzione w ten sposób dane do atakującego. Badacze w ramach Proof of Concept stworzyli własną wtyczkę, która bez żądania jakichkolwiek dodatkowych uprawnień wydobywa poświadczenia użytkownika z bazy.

Podatność została zgłoszona do Cursor w styczniu 2026. 5 lutego badacze otrzymali odpowiedź, że nie została ona uznana za problem, bo dotyczy odpowiedzialności użytkownika (musi sam zainstalować wtyczkę). Do dnia publikacji nie wdrożono zmian naprawiających ten problem.

Użytkownikom polecamy nie ufać wtyczkom i minimalizować ich liczbę. W organizacjach można rozważyć wdrożenie whitelist lub zatwierdzanie rozszerzeń przed instalacją (np. przez własny “sklep” z pluginami) – złośliwe dodatki pojawiają się bowiem nie tylko w przeglądarkach, o czym pisaliśmy m.in. tutaj.

Źródło: layerxsecurity.com

~Tymoteusz Jóźwiak