Krytyczna luka w Cursor umożliwia kradzież kluczy API przez złośliwe rozszerzenia - Security Bez Tabu

Krytyczna luka w Cursor umożliwia kradzież kluczy API przez złośliwe rozszerzenia

Cybersecurity news

Wprowadzenie do problemu / definicja

Wraz ze wzrostem popularności edytorów kodu wspieranych przez sztuczną inteligencję rośnie znaczenie ochrony lokalnie przechowywanych sekretów, takich jak klucze API, tokeny sesyjne i dane uwierzytelniające do usług zewnętrznych. Najnowsze doniesienia dotyczące Cursor wskazują na poważną podatność, która może pozwalać zainstalowanym rozszerzeniom na dostęp do wrażliwych danych bez dodatkowej zgody użytkownika.

Problem ten wpisuje się w szerszy trend zagrożeń związanych z rozszerzeniami IDE oraz nadmiernym zaufaniem do komponentów uruchamianych bezpośrednio w środowisku deweloperskim. W praktyce oznacza to, że pojedynczy dodatek może stać się furtką do przejęcia cennych sekretów i dalszej kompromitacji środowiska pracy programisty.

W skrócie

Badacze bezpieczeństwa opisali lukę o wysokiej wadze, która umożliwia dowolnemu rozszerzeniu działającemu w Cursor odczyt lokalnie przechowywanych kluczy API oraz tokenów sesyjnych. Źródłem problemu ma być przechowywanie poufnych danych w lokalnej bazie SQLite bez wystarczającej izolacji od kodu rozszerzeń.

  • atak nie wymaga interakcji użytkownika poza instalacją rozszerzenia,
  • zagrożone mogą być klucze API, tokeny sesyjne i inne dane uwierzytelniające,
  • skutkiem może być przejęcie kont, nadużycia finansowe i wyciek danych,
  • ryzyko dotyczy zarówno użytkowników indywidualnych, jak i organizacji.

Kontekst / historia

Cursor zdobył popularność jako edytor kodu zintegrowany z funkcjami AI, wykorzystywany do generowania, refaktoryzacji i analizy kodu. Narzędzia tego typu często przetwarzają duże ilości danych projektowych oraz łączą się z zewnętrznymi dostawcami modeli i API, dlatego ochrona sekretów ma w ich przypadku szczególne znaczenie.

Publiczne nagłośnienie problemu nastąpiło pod koniec kwietnia 2026 roku. Z dostępnych informacji wynika, że podatność została wcześniej zgłoszona producentowi, jednak w chwili publikacji doniesień problem miał nadal stanowić realne zagrożenie. To ważny sygnał ostrzegawczy dla firm rozwijających oprogramowanie z użyciem narzędzi AI, ponieważ kompromitacja stacji roboczej programisty może prowadzić do incydentów obejmujących cały łańcuch dostaw.

Analiza techniczna

Istota luki sprowadza się do sposobu przechowywania poświadczeń. Zamiast polegać wyłącznie na systemowych mechanizmach bezpiecznego magazynowania sekretów, dane miały być przechowywane w lokalnej bazie SQLite. Jeśli rozszerzenie uruchamiane w środowisku Cursor może odczytać taki magazyn bez skutecznych ograniczeń, granica bezpieczeństwa pomiędzy samą aplikacją a dodatkami przestaje istnieć.

Scenariusz ataku jest prosty i nie wymaga zaawansowanych technik. Napastnik przygotowuje pozornie użyteczne rozszerzenie, na przykład motyw, narzędzie wspierające produktywność albo dodatek dla pracy z kodem. Po instalacji rozszerzenie może wykonać kod w środowisku edytora, odczytać plik bazy danych z sekretami, wyodrębnić interesujące rekordy i przesłać je do infrastruktury atakującego.

Z perspektywy bezpieczeństwa jest to klasyczny przykład niewłaściwego modelu zaufania i braku izolacji komponentów lokalnych. W przypadku narzędzi AI ryzyko staje się jeszcze większe, ponieważ przechowywane klucze często dają dostęp nie tylko do samego edytora, ale również do usług modelowych, platform chmurowych oraz integracji firmowych.

Dodatkowym problemem jest niski próg wejścia dla cyberprzestępcy. Po zainstalowaniu rozszerzenia użytkownik może nie zauważyć niczego podejrzanego, a eksfiltracja danych może odbywać się całkowicie w tle. To znacząco utrudnia wykrycie incydentu zarówno użytkownikowi końcowemu, jak i zespołom monitorującym typowe objawy złośliwego oprogramowania.

Konsekwencje / ryzyko

Najbardziej bezpośrednią konsekwencją podatności jest kradzież kluczy API i tokenów sesyjnych. W zależności od sposobu wykorzystania Cursor oraz powiązanych integracji skutki mogą być znacznie szersze niż sam dostęp do edytora.

  • nieautoryzowane korzystanie z płatnych usług API na koszt ofiary,
  • przejęcie sesji użytkownika i podszywanie się pod niego,
  • dostęp do promptów, odpowiedzi modeli i metadanych przetwarzanych przez narzędzia AI,
  • kompromitacja integracji z usługami zewnętrznymi,
  • wyciek kodu źródłowego, konfiguracji i danych projektowych.

W organizacjach ryzyko wykracza poza pojedynczą stację roboczą. Klucze znalezione w środowisku deweloperskim mogą umożliwić dalszy dostęp do repozytoriów, systemów CI/CD, usług chmurowych, platform AI czy narzędzi współpracy. W praktyce może to prowadzić do strat finansowych, zakłóceń operacyjnych, naruszenia poufności własności intelektualnej oraz problemów zgodności.

Incydent pokazuje również, że rozszerzenia IDE powinny być traktowane jak oprogramowanie uprzywilejowane. Jeśli organizacja nie kontroluje ich instalacji i pochodzenia, tworzy kanał do uruchamiania niezweryfikowanego kodu na stacjach roboczych o wysokiej wartości biznesowej.

Rekomendacje

Do czasu pełnego wyeliminowania problemu użytkownicy i organizacje korzystające z Cursor powinny wdrożyć środki ograniczające ekspozycję na ryzyko. Kluczowe jest założenie, że każde rozszerzenie może stanowić potencjalny wektor ataku.

  • ograniczyć instalację rozszerzeń wyłącznie do niezbędnych i sprawdzonych dodatków,
  • przeprowadzić audyt już zainstalowanych rozszerzeń pod kątem pochodzenia i reputacji,
  • rotować klucze API używane w Cursor, szczególnie jeśli instalowano dodatki z niepewnych źródeł,
  • monitorować wykorzystanie API pod kątem anomalii kosztowych i nietypowych żądań,
  • stosować zasadę najmniejszych uprawnień dla kluczy i tokenów,
  • rozdzielać sekrety per projekt, użytkownik i środowisko,
  • tam, gdzie to możliwe, używać krótkotrwałych tokenów zamiast długowiecznych sekretów,
  • wdrożyć EDR oraz monitoring połączeń wychodzących z narzędzi deweloperskich,
  • blokować samowolną instalację rozszerzeń za pomocą polityk zarządzania stacjami roboczymi.

Z perspektywy producentów oprogramowania bezpieczny model powinien obejmować przechowywanie sekretów w systemowych magazynach poświadczeń, silną izolację rozszerzeń, kontrolę dostępu do zasobów wrażliwych oraz bardziej restrykcyjny model uprawnień. Narzędzia AI dla programistów należy dziś traktować jak aplikacje przetwarzające dane uprzywilejowane, a nie zwykłe edytory tekstu.

Podsumowanie

Luka ujawniona w Cursor pokazuje, że bezpieczeństwo narzędzi AI dla deweloperów staje się krytycznym elementem ochrony łańcucha dostaw oprogramowania. Jeśli rozszerzenie może bez przeszkód odczytać lokalnie zapisane klucze API i tokeny sesyjne, pojedyncza instalacja dodatku może doprowadzić do pełnej kompromitacji środowiska pracy.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że polityki dotyczące IDE, rozszerzeń i zarządzania sekretami muszą zostać zaostrzone. Organizacje powinny objąć narzędzia AI tym samym poziomem kontroli, jaki stosują wobec systemów uprzywilejowanych i krytycznych komponentów infrastruktury deweloperskiej.

Źródła

  1. https://www.infosecurity-magazine.com/news/cursor-extension-flaw-exposes-api/
  2. https://layerxsecurity.com/blog/cursorjacking-every-cursor-user-is-vulnerable-to-api-key-theft-by-rogue-extensions/