Luki w Cursor pozwalają na wykonanie poleceń i obejście sandboxa

Wprowadzenie do problemu / definicja

Cursor, nowoczesny edytor kodu rozwijany z myślą o współpracy z asystentami AI, znalazł się w centrum zainteresowania badaczy bezpieczeństwa. Opisane podatności pokazują, że błędy w mechanizmach uruchamiania poleceń oraz w modelu izolacji mogą prowadzić do wykonania kodu, uruchamiania nieautoryzowanych plików wykonywalnych oraz zapisu danych poza zakładanym obszarem roboczym.

To szczególnie niebezpieczne w środowiskach deweloperskich, gdzie edytor często ma dostęp do repozytoriów źródłowych, kluczy SSH, tokenów API, danych uwierzytelniających do chmury i narzędzi CI/CD. W praktyce oznacza to, że kompromitacja pozornie zwykłego narzędzia programistycznego może stać się punktem wejścia do szerszego incydentu bezpieczeństwa.

W skrócie

Badacze opisali kilka niezależnych problemów bezpieczeństwa dotyczących Cursor.
Jedna z publicznie ujawnionych luk została zarejestrowana jako CVE-2026-50548 i miała zostać naprawiona w Cursor 3.0.
Wśród scenariuszy ataku wskazano obejście sandboxa, zapis plików poza workspace oraz uruchomienie złośliwego pliku git.exe z katalogu projektu w systemie Windows.
Niektóre wektory ataku mogły zostać uruchomione już po samym otwarciu złośliwego repozytorium.

Kontekst / historia

Problemy bezpieczeństwa w Cursor nie wyglądają na odosobniony incydent, lecz wpisują się w szerszy trend obserwowany w narzędziach developerskich wzbogacanych o funkcje AI. Im większa automatyzacja pracy z terminalem, repozytoriami i lokalnym systemem operacyjnym, tym większa powierzchnia ataku.

W ostatnich miesiącach badacze wielokrotnie zwracali uwagę, że integracja modeli AI z lokalnymi poleceniami systemowymi tworzy nową klasę ryzyk. Dotyczy to szczególnie funkcji związanych z wykonywaniem komend, zarządzaniem workspace, obsługą Git oraz automatycznym korzystaniem z narzędzi dostępnych na stacji roboczej użytkownika.

W przypadku CVE-2026-50548 problem miał dotyczyć wersji wcześniejszych niż 3.0. Równolegle opisywano także odrębny scenariusz w systemie Windows, w którym aplikacja mogła uruchomić plik git.exe znajdujący się bezpośrednio w katalogu projektu. Taki mechanizm nadaje sprawie wymiar zagrożenia dla łańcucha dostaw oprogramowania, zwłaszcza jeśli deweloperzy pracują z niezweryfikowanymi repozytoriami.

Analiza techniczna

Kluczowy problem techniczny dotyczył sposobu, w jaki Cursor łączy funkcje agenta AI z lokalnym uruchamianiem poleceń terminalowych. W opisywanym scenariuszu związanym z CVE-2026-50548 istotną rolę odgrywał parametr working_directory, wykorzystywany przez narzędzie odpowiedzialne za wykonywanie komend.

Założenie sandboxa było proste: proces powinien móc zapisywać dane jedynie w obrębie katalogu roboczego powiązanego z projektem. Wadliwa walidacja ścieżki miała jednak umożliwiać wskazanie lokalizacji poza właściwym workspace. W efekcie złośliwy agent, odpowiednio spreparowany kontekst lub niebezpieczna sekwencja działań mogły doprowadzić do zapisu arbitralnych plików w innych miejscach dostępnych dla użytkownika.

To z kolei otwierało drogę do obejścia założeń izolacji. Jeśli możliwe było nadpisanie plików pomocniczych związanych z egzekwowaniem ograniczeń albo elementów startowych środowiska użytkownika, kolejne polecenia mogły być wykonywane już poza kontrolowanym kontekstem. Taki przebieg zdarzeń oznacza przejście od ograniczonego działania w projekcie do pełnego wykonania kodu z uprawnieniami zalogowanego użytkownika.

Drugi szeroko komentowany scenariusz dotyczył sposobu wyszukiwania binariów Git w systemie Windows. Z opublikowanych analiz wynika, że aplikacja mogła uruchomić git.exe odnaleziony bezpośrednio w katalogu repozytorium. Jeśli atakujący umieścił tam złośliwy plik o tej samej nazwie, samo otwarcie projektu mogło wystarczyć do wykonania kodu. Mechanizm ten przypomina klasyczny binary planting, czyli niebezpieczne zaufanie do lokalizacji plików wykonywalnych.

Najbardziej niepokojące jest jednak łączenie wielu elementów w jeden łańcuch ataku. Złośliwe repozytorium, funkcje automatyzacji agenta AI, integracja z terminalem oraz lokalnie przechowywane sekrety mogą wspólnie stworzyć warunki do pełnej kompromitacji stacji roboczej dewelopera.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją opisanych luk jest możliwość wykonania kodu z uprawnieniami użytkownika pracującego w Cursor. W praktyce oznacza to ryzyko przejęcia kodu źródłowego, kradzieży tokenów dostępowych, kluczy SSH, sekretów zapisanych lokalnie oraz poświadczeń używanych do pracy z chmurą lub systemami automatyzacji.

Z perspektywy organizacji problem ma również znaczenie operacyjne i strategiczne. Kompromitacja stacji roboczej dewelopera może otworzyć drogę do dalszych etapów ataku, takich jak przejęcie kont uprzywilejowanych, modyfikacja pipeline’ów CI/CD, wstrzyknięcie złośliwego kodu do projektów lub rozprzestrzenienie incydentu wewnątrz infrastruktury.

Ryzyko rośnie szczególnie w zespołach, które regularnie klonują publiczne repozytoria, testują proof-of-concepty lub korzystają z agentów AI do automatycznego wykonywania działań w terminalu. W takim modelu pracy błędy w walidacji ścieżek, wyszukiwaniu binariów i egzekwowaniu ograniczeń sandboxa stają się krytyczne.

Rekomendacje

Organizacje korzystające z Cursor powinny w pierwszej kolejności przeprowadzić przegląd używanych wersji i potwierdzić wdrożenie poprawek dla znanych podatności, w tym aktualizację do wersji 3.0 lub nowszej tam, gdzie ma to zastosowanie.

Ograniczyć otwieranie niezweryfikowanych repozytoriów na produkcyjnych stacjach roboczych.
Analizować obce projekty w środowiskach izolowanych, takich jak maszyny wirtualne lub dodatkowe sandboxy systemowe.
Blokować uruchamianie plików wykonywalnych z katalogów roboczych projektów, szczególnie w systemie Windows.
Monitorować nietypowe procesy potomne uruchamiane przez edytory kodu i narzędzia AI.
Ograniczyć lokalną ekspozycję sekretów i wymuszać ich rotację po wykryciu podejrzanej aktywności.
Stosować zasadę najmniejszych uprawnień dla kont deweloperskich i dostępów do usług chmurowych.
Włączyć reguły EDR/XDR wykrywające binary planting, nadpisywanie plików startowych oraz anomalie w katalogach repozytoriów.
Audytować ustawienia zaufania do workspace, integracje terminalowe i automatyczne akcje wykonywane przez agenta AI.

W praktyce warto traktować edytory wspierane przez AI jako uprzywilejowane komponenty wykonawcze, a nie jedynie narzędzia interfejsowe. Oznacza to potrzebę objęcia ich podobnym poziomem nadzoru jak systemów CI, agentów automatyzacji i skryptów administracyjnych.

Podsumowanie

Przypadek Cursor pokazuje, że bezpieczeństwo narzędzi programistycznych z funkcjami AI zależy nie tylko od jakości modelu językowego, ale przede wszystkim od sposobu integracji z lokalnym systemem operacyjnym, terminalem i repozytoriami. Błędy w obsłudze working_directory, wykonywaniu poleceń oraz wyszukiwaniu binariów mogą przełożyć się na realne przejęcie środowiska deweloperskiego.

Dla organizacji najważniejsze wnioski są trzy: szybko aktualizować narzędzia, nie ufać automatycznie zawartości workspace i izolować analizę nieznanego kodu. W środowiskach, gdzie AI może inicjować operacje systemowe, klasyczne błędy w walidacji ścieżek i uruchamianiu poleceń stają się problemem o wysokim priorytecie bezpieczeństwa.