Klucze API w edytorze Cursor dostępne dla każdego rozszerzenia. Jak się chronić?
Badacze z LayerX odkryli, że edytor kodu Cursor przechowuje klucze API w lokalnej bazie SQLite, do której dostęp ma każde zainstalowane rozszerzenie. Producent nie uznał tego za błąd. Podpowiadamy, jak zabezpieczyć swoje poświadczenia.
Gdy myślimy o bezpieczeństwie narzędzi AI, często skupiamy się na jailbreakingu czy prompt injection. Tymczasem realne zagrożenie może czaić się w zwykłym rozszerzeniu do edytora kodu. Badacze z firmy LayerX odkryli, że popularny edytor Cursor – wspierany przez LLM – przechowuje klucze API użytkowników w lokalnej bazie SQLite, do której dostęp ma każde zainstalowane rozszerzenie. Producent nie uznał tego za błąd, ale dla programistów i firm oznacza to konieczność zmiany nawyków.
Jak działa podatność CursorJacking?
Cursor bazuje na otwartym kodzie Visual Studio Code, ale wprowadza kluczową funkcję – integrację z modelami AI. Użytkownicy mogą korzystać z konta Cursor i modeli hostowanych przez twórców narzędzia albo podłączyć własne klucze API do usług takich jak OpenAI, Anthropic czy Google. W obu przypadkach poświadczenia są zapisywane lokalnie przez aplikację. Problem w tym, że Cursor nie korzysta z systemowego menedżera sekretów (np. macOS Keychain, Windows Credential Manager czy GNOME Keyring). Zamiast tego przechowuje je w pliku bazy SQLite pod ścieżką: ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb.
Jak wyjaśniają badacze z LayerX, każde rozszerzenie Cursor może bezpośrednio odczytać tę bazę, wykonując zwykłe zapytanie SQL. Nie są do tego wymagane żadne specjalne uprawnienia – wtyczka działa w kontekście edytora i ma dostęp do jego plików. W praktyce oznacza to, że złośliwe rozszerzenie może wykraść klucze API i tokeny sesji bez wiedzy użytkownika.
Scenariusz ataku – od instalacji do eksfiltracji
Atakujący może stworzyć pozornie nieszkodliwe rozszerzenie do Cursor, które nie żąda żadnych podejrzanych uprawnień. Może też przejąć istniejącą wtyczkę (np. przez atak na jej twórcę lub wykupienie projektu) i wdrożyć złośliwą aktualizację. Z perspektywy użytkownika nic nie wygląda nietypowo – instaluje „niewinne” rozszerzenie z marketplace’u lub repozytorium na GitHubie.
Po instalacji wtyczka otwiera plik bazy Cursor i wykonuje zapytanie SQL. Nie wymaga to żadnej dodatkowej interakcji. W ten sposób można pozyskać:
- klucze API do usług AI (OpenAI, Anthropic, Google),
- tokeny sesji umożliwiające podszycie się pod użytkownika,
- inne metadane i konfiguracje.
Następnie rozszerzenie wysyła wykradzione dane do atakującego. Badacze z LayerX w ramach Proof of Concept stworzyli własną wtyczkę, która bez żądania dodatkowych uprawnień wydobywała poświadczenia z bazy.
Reakcja producenta – brak uznania problemu
Podatność została zgłoszona do Cursor w styczniu 2026 roku. 5 lutego badacze otrzymali odpowiedź, że nie została uznana za problem, ponieważ wymaga zainstalowania złośliwej wtyczki przez użytkownika. Do dnia publikacji artykułu nie wdrożono żadnych zmian naprawczych. Taka postawa producenta oznacza, że odpowiedzialność za bezpieczeństwo spoczywa wyłącznie na użytkownikach.
Jak chronić swoje klucze API?
W obliczu braku łatki ze strony Cursor, użytkownicy i organizacje muszą sami zadbać o ochronę. Oto praktyczne zalecenia:
- Minimalizuj liczbę instalowanych rozszerzeń. Każda dodatkowa wtyczka to potencjalne ryzyko. Instaluj tylko te, które są niezbędne i pochodzą od zaufanych autorów.
- Nie ufaj wtyczkom bez weryfikacji. Sprawdzaj opinie, liczbę pobrań, datę ostatniej aktualizacji i kod źródłowy (jeśli jest dostępny).
- W organizacjach wdróż whitelisting rozszerzeń. Można rozważyć zatwierdzanie wtyczek przed instalacją, np. przez własny „sklep” z pluginami lub politykę grupową.
- Używaj osobnych kluczy API o ograniczonych uprawnieniach. Jeśli to możliwe, generuj tokeny tylko do konkretnych repozytoriów lub usług, a nie z pełnym dostępem do konta.
- Regularnie monitoruj wykorzystanie kluczy API. W przypadku wykrycia nieautoryzowanego dostępu natychmiast je unieważnij.
Warto też pamiętać, że podobne problemy mogą dotyczyć innych narzędzi AI dla programistów. Zawsze sprawdzaj, gdzie i jak przechowywane są twoje poświadczenia – najlepiej, gdy trafiają do systemowego menedżera sekretów, a nie do zwykłego pliku bazy danych.
Podatność CursorJacking pokazuje, że bezpieczeństwo narzędzi AI to nie tylko ochrona modeli przed prompt injection, ale także fundamentalne kwestie architektury aplikacji. Dopóki producenci nie zaczną traktować poważnie lokalnego przechowywania sekretów, użytkownicy muszą zachować czujność i stosować zasadę ograniczonego zaufania wobec każdego rozszerzenia.
