Narzędzie do edycji kodu Cursor wciąż uruchamia złośliwy plik git.exe umieszczony w folderze projektu – to krytyczna podatność typu zero-day, która pozostaje niezałatana od siedmiu miesięcy. Błąd ten pozwala na automatyczne uruchomienie dowolnego pliku wykonywalnego podszywającego się pod Git z uprawnieniami użytkownika, co naraża programistów na zdalne wykonanie kodu bez konieczności klikania czegokolwiek czy otrzymania ostrzeżenia.

Luka została odkryta przez badacza bezpieczeństwa Mindgard 15 grudnia 2025 r., zgłoszona tego samego dnia i nadal występuje w wydaniu z lipca 2026 r., mimo ponad 197 aktualizacji i wyceny firmy na poziomie 60 miliardów dolarów.

Jak działa ten błąd

Cursor skanuje katalog projektu w poszukiwaniu binariów Git w kilku lokalizacjach, w tym w głównym folderze repozytorium. Gdy znajdzie plik o nazwie git.exe, uruchamia go, aby zapewnić funkcje kontroli wersji. Uruchomienie następuje po cichu, bez żadnego komunikatu w interfejsie użytkownika, i dziedziczy uprawnienia bieżącego użytkownika.

Atakujący, który może dodać plik do repozytorium, może zastąpić oczekiwany plik binarny Git dowolnym plikiem wykonywalnym. Mindgard zademonstrował ten efekt, zmieniając nazwę kalkulatora Windows na git.exe, umieszczając go w repozytorium i otwierając folder w Cursor. Okna kalkulatora wyskakiwały wielokrotnie, dopóki projekt był otwarty – to ilustracja tego, w jaki sposób prawdziwe złośliwe oprogramowanie mogłoby działać w ten sam sposób.

Oś czasu ujawnienia

  • 15 gru 2025 r. – Mindgard wysyła pełny raport na adres bezpieczeństwa Cursor.
  • 15 sty 2026 r. – Miesiąc później odpowiada dyrektor ds. bezpieczeństwa informacji (CISO) firmy Cursor.
  • 16 sty 2026 r. – HackerOne, platforma bug bounty używana przez Cursor, klasyfikuje raport jako spoza zakresu (out of scope).
  • 16 sty 2026 r. – Mindgard dostarcza dowód koncepcji (proof-of-concept), co skłania HackerOne do ponownego otwarcia zgłoszenia.
  • 20 sty 2026 r. – HackerOne potwierdza, że Cursor formalnie otrzymał raport.

Po 20 stycznia kolejne wiadomości od Mindgard nie doczekały się odpowiedzi. Cursor nadal wprowadzał nowe funkcje i pozyskiwał dodatkowe fundusze, ale podatność pozostała w kodzie źródłowym.

Dlaczego to opóźnienie jest niepokojące

Problem stanowi klasyczne ryzyko związane z łańcuchem dostaw: każdy współtwórca, który może przesłać plik do współdzielonego repozytorium, może wstrzyknąć złośliwy kod, który uruchomi się na maszynie każdego programisty.

Kroki łagodzące, które możesz podjąć już teraz

Środowiska korporacyjne Windows

  • Wdróż polityki AppLocker lub Windows App Control, które blokują uruchamianie jakiegokolwiek pliku wykonywalnego o nazwie git.exe wewnątrz katalogów obszaru roboczego.
  • Zrezygnuj z list dopuszczonych (allowlists) opartych na skrótach (hash); atakujący mogą po prostu zmienić skrót pliku, zachowując jego nazwę.

Programiści indywidualni

  • Otwieraj repozytoria z niepewnych źródeł wyłącznie wewnątrz maszyny wirtualnej lub Windows Sandbox.
  • Nie polegaj na listach blokowanych (blocklists) opartych na skrótach plików; dają one złudne poczucie bezpieczeństwa.

Ogólne dobre praktyki

  • Traktuj każde nowe repozytorium jako potencjalny wektor ataku na łańcuch dostaw. Weryfikuj pochodzenie wszystkich binariów przed ich uruchomieniem.

Ten incydent podkreśla szerszą lekcję: narzędzia programistyczne oparte na AI wymagają głębokiego dostępu do systemu, a dostęp ten musi być chroniony z taką samą rygorystycznością jak każde inne oprogramowanie z uprawnieniami. Gdy podatność o wysokim wpływie utrzymuje się przez miesiące w firmie wartej miliardy dolarów, programiści otrzymują jasny sygnał, aby ponownie ocenić zaufanie, jakim darzą daną platformę.