Cursor na Windows uruchamia podrzucony git.exe. Twórcy: to poza bug bounty

Firma badawcza Mindgard opublikowała 14 lipca pełny opis podatności w edytorze Cursor AI na Windows. Mechanizm jest prosty: jeśli otwarte repozytorium zawiera w katalogu głównym plik o nazwie git.exe, Cursor uruchamia go automatycznie. Badacze piszą wprost, że nie pojawia się przy tym żadne kliknięcie, pytanie o zgodę ani ostrzeżenie. Dzień później Cursor odpowiedział, że zgłoszenie wykracza poza zakres jego programu bug bounty.

Na czym polega problem

Windows szuka programów w katalogach z listy, a katalog bieżący potrafi wejść do tej listy przed katalogami systemowymi. Cursor w trakcie pracy wywołuje git, żeby sprawdzić stan repozytorium. Na Windows nazwa git rozwija się do git.exe, więc jeśli taki plik leży w projekcie, uruchamia się on zamiast prawdziwego Gita.

W demonstracji Mindgard użył systemowego kalkulatora Windows przemianowanego na git.exe, co jest standardowym, nieszkodliwym sposobem pokazania, że w ten sposób można uruchomić dowolny program. Podatność dotyczy wyłącznie Windows. Na macOS i Linuksie mechanizm rozwijania nazw działa inaczej.

Praktyczny scenariusz ataku wygląda tak: klonujesz cudze repozytorium, żeby coś sprawdzić albo użyć jako punktu wyjścia, i otwierasz je w edytorze. Nie uruchamiasz niczego świadomie. Wystarczy samo otwarcie projektu.

Pół roku i spór o zasady

Oś czasu, którą podaje Mindgard, jest niewygodna dla obu stron. Zgłoszenie poszło 15 grudnia 2025, ponaglenie trzy dni później. W styczniu 2026 badacze dostali zaproszenie do programu na HackerOne, zreprodukowali problem i 20 stycznia otrzymali potwierdzenie, że raport dotarł. Pierwszego czerwca zapowiedzieli publiczne ujawnienie, a opublikowali 14 lipca.

Ich podsumowanie brzmi: minęło ponad pół roku i ponad 197 nowych wersji, a problem nadal występuje w ostatniej testowanej wersji. Tu potrzebne jest ważne zastrzeżenie, które zmienia wagę całej sprawy: ostatni test przeprowadzono 30 kwietnia 2026 na Cursorze 3.2.16. Aktualna linia to 3.11, a nikt publicznie nie sprawdził, czy zachowanie utrzymuje się w niej dalej.

Odpowiedź Cursora pojawiła się 15 lipca na oficjalnym forum, w wątku poświęconym raportowi. Stanowisko jest jednoznaczne: po przeanalizowaniu zgłoszenia uznano je za wykraczające poza zakres programu bug bounty. Uzasadnienie odwołuje się do współdzielonej odpowiedzialności. Problemy, które zależą od tego, że w kontekście pracy agenta znalazły się już złośliwe dane, zdaniem firmy zwykle nie mieszczą się w programie. Jako istniejące zabezpieczenie Cursor wskazuje Workspace Trust, czyli pytanie o zaufanie do folderu przy jego otwieraniu.

Firma przyznaje jednocześnie, że nie domknęła sprawy z badaczem w rozsądnym czasie i bierze za to odpowiedzialność.

W komunikacie nie pada numer wersji z poprawką ani zdanie o naprawie. Część serwisów napisała, że Cursor po cichu załatał problem 13 lipca, dzień przed publikacją Mindgard, ale nie potwierdza tego ani changelog, ani wpis na forum. Do czasu, aż zrobi to sam producent, traktujemy to jako niepotwierdzoną pogłoskę.

Kto ma rację

Argument Cursora nie jest bezsensowny. Otwarcie cudzego repozytorium w jakimkolwiek edytorze zawsze niesie ryzyko, a mechanizmy w rodzaju hooków Gita czy zadań w konfiguracji projektu potrafią wykonać kod od lat. Traktowanie zawartości projektu jako danych zaufanych to założenie całej branży, nie wymysł Cursora.

Argument drugiej strony jest jednak mocniejszy w jednym punkcie: skoro istnieje Workspace Trust, czyli mechanizm, który ma dokładnie temu zapobiegać, to fakt, że plik uruchamia się mimo wszystko i bez ostrzeżenia, jest trudny do obrony. Spór dotyczy przy tym nie tyle istnienia problemu, ile tego, czy firma powinna była za niego zapłacić i wpisać go do programu.

Co z tego wynika dla Ciebie

Jeśli pracujesz na macOS albo Linuksie, sprawa Cię nie dotyczy.

Jeśli używasz Cursora na Windows, trzy rzeczy warto zrobić już teraz. Po pierwsze, aktualizuj edytor, bo testowana wersja jest z końca kwietnia i realny stan w 3.11 pozostaje nieznany. Po drugie, przed otwarciem cudzego repozytorium zajrzyj do jego katalogu głównego w zwykłym menedżerze plików. Plik wykonywalny o nazwie git.exe w projekcie nie ma prawa tam być, i to jedyny sygnał, jakiego potrzebujesz. Po trzecie, nie klonuj projektów z przypadkowych linków ze społeczności i z komentarzy, zwłaszcza gdy kusi obietnicą gotowego szablonu.

Szerszy wniosek jest taki, że narzędzia do vibe codingu odziedziczyły model zaufania z klasycznych edytorów, w którym zawartość otwieranego projektu jest z założenia bezpieczna. Przy agentach, które same wywołują polecenia w tle, to założenie robi się coraz mniej wygodne. Podobny wątek opisywaliśmy przy wycieku danych z Grok Build i przy łataniu prompt injection w Claude Code.