Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
W narzędziach deweloperskich wspieranych przez AI coraz większe znaczenie mają zagrożenia wynikające z lokalnego uruchamiania programów pomocniczych podczas pracy z repozytoriami kodu. Najnowszy przypadek dotyczy edytora Cursor na Windows, gdzie samo otwarcie sklonowanego projektu może doprowadzić do uruchomienia złośliwego pliku wykonywalnego umieszczonego w katalogu repozytorium.
Problem wpisuje się w klasę podatności znaną jako untrusted search path lub binary planting. W praktyce chodzi o sytuację, w której aplikacja nie korzysta z jawnie wskazanej, zaufanej ścieżki do programu pomocniczego, tylko pozwala systemowi rozstrzygać, który plik wykonywalny ma zostać uruchomiony.
W skrócie
Badacze pokazali scenariusz, w którym Cursor na Windows może uruchomić plik git.exe znajdujący się w katalogu otwartego projektu. Atak nie wymaga wcześniejszego przejęcia stacji roboczej ani dodatkowej interakcji poza sklonowaniem i otwarciem repozytorium.
- wektor ataku działa w standardowym workflow programisty,
- złośliwy kod uruchamia się z uprawnieniami zalogowanego użytkownika,
- zagrożone są klucze SSH, tokeny API, sekrety chmurowe i kod źródłowy,
- problem dotyczy klasycznego błędu rozwiązywania ścieżek do binariów w Windows.
Kontekst / historia
Podatność została zgłoszona producentowi w grudniu 2025 roku, a szczegóły techniczne ujawniono kilka miesięcy później. Z opisu wynika, że problem występował co najmniej w testowanych wersjach z pierwszej połowy 2026 roku.
Znaczenie sprawy wykracza poza pojedynczy produkt. To kolejny przykład ryzyka, które od lat jest znane w ekosystemie Windows, ale w nowoczesnych narzędziach developerskich zyskuje nowy wymiar. Aplikacje pracujące na repozytoriach coraz częściej automatyzują liczne operacje, przez co granica między otwarciem projektu a uruchomieniem kodu staje się mniej oczywista.
Historycznie podobne problemy wynikały z niebezpiecznego wyszukiwania programów pomocniczych w bieżącym katalogu roboczym lub innych lokalizacjach o wyższym priorytecie. To otwiera drogę do podsunięcia fałszywego pliku pod nazwą oczekiwaną przez aplikację, takiego jak git.exe.
Analiza techniczna
Mechanizm ataku jest stosunkowo prosty. Podczas otwierania projektu Cursor wykonuje operacje związane z obsługą repozytorium Git, między innymi próbując ustalić katalog główny projektu. Jeśli aplikacja wywołuje git w sposób pozwalający systemowi samodzielnie wyszukać plik wykonywalny, może dojść do uruchomienia binarki znajdującej się bezpośrednio w katalogu workspace.
W praktyce oznacza to, że napastnik może umieścić w repozytorium własny plik git.exe. Po otwarciu projektu przez ofiarę aplikacja uruchomi złośliwy plik zamiast zaufanego narzędzia systemowego. Taki payload może następnie wykraść sekrety, zmodyfikować pliki projektu, pobrać kolejne komponenty malware albo zapewnić trwałość na stacji roboczej.
Istotne jest również to, że opisany wektor nie wymaga makr, prompt injection, uruchamiania agenta AI ani dodatkowego kliknięcia. Wystarcza standardowy proces pracy z kodem, czyli sklonowanie zewnętrznego repozytorium i otwarcie go w edytorze.
Konsekwencje / ryzyko
Ryzyko dla organizacji rozwijających oprogramowanie należy ocenić jako wysokie, szczególnie jeśli zespoły regularnie pobierają obce repozytoria, testują przykładowe projekty lub korzystają z narzędzi AI do automatycznego pozyskiwania kodu.
- kradzież kluczy SSH, tokenów API i poświadczeń chmurowych,
- modyfikacja kodu źródłowego i możliwość wstrzyknięcia backdoora,
- dostęp do prywatnych repozytoriów oraz lokalnych sekretów dewelopera,
- uruchomienie kolejnych etapów malware w kontekście użytkownika,
- utrzymanie dostępu do środowiska roboczego i ruch lateralny.
Szczególnie niebezpieczne jest to, że atak może wyglądać jak zwykła praca z projektem. W wielu organizacjach samo pobranie repozytorium nie jest postrzegane jako uruchamianie nieufnego kodu, choć w tym przypadku taka granica praktycznie zanika.
Rekomendacje
Do czasu wdrożenia pełnej poprawki lub jednoznacznego mechanizmu ochronnego organizacje powinny potraktować sklonowane repozytoria na Windows jako potencjalnie niebezpieczne.
- otwierać nieufne repozytoria w środowiskach izolowanych, takich jak maszyny wirtualne lub sandbox,
- blokować uruchamianie plików EXE z katalogów roboczych użytkowników przy użyciu AppLocker lub WDAC,
- monitorować procesy potomne IDE i narzędzi AI pod kątem uruchamiania binariów z katalogów repozytoriów,
- skanować projekt przed otwarciem w poszukiwaniu nieoczekiwanych plików wykonywalnych i skryptów startowych,
- wymuszać korzystanie z zaufanych binariów z jawnie określonych lokalizacji,
- ograniczać liczbę aktywnych sekretów na stacjach deweloperskich i stosować zasadę najmniejszych uprawnień.
Podsumowanie
Luka w Cursor pokazuje, że nowoczesne narzędzia developerskie oparte na AI mogą dziedziczyć klasyczne problemy bezpieczeństwa systemu Windows, a automatyzacja pracy z kodem może dodatkowo zwiększać ich skutki. W tym przypadku samo otwarcie sklonowanego projektu może doprowadzić do wykonania złośliwego kodu z uprawnieniami zalogowanego użytkownika.
Dla zespołów developmentu oznacza to konieczność zmiany podejścia do zewnętrznych repozytoriów. Nieznany projekt powinien być traktowany jak obiekt wysokiego ryzyka, wymagający izolacji, kontroli wykonywania oraz dodatkowej inspekcji jeszcze przed otwarciem w środowisku pracy.