Głośna wersja brzmi: „0-day w edytorze AI sam uruchamia kod”. Przydatniejsza jest spokojna wersja. Mindgard twierdzi, że Cursor na Windows może uruchomić git.exe z katalogu głównego otwartego repozytorium podczas szukania Git. Cursor odpowiada, że ryzyko jest wąskie i należy do shared responsibility za niezaufane wejścia workspace. Praktyczny wniosek: otwarcie nieznanego repozytorium w narzędziu AI dla programistów nie jest już całkiem pasywne.

Stacja robocza programisty z podejrzanym plikiem repozytorium odizolowanym od sekretów

W proof of concept Mindgard Windows Calculator został nazwany git.exe, umieszczony w root repozytorium i uruchomiony przy otwarciu projektu w Cursor. To nie prompt injection, nie dowód kompromitacji wszystkich użytkowników i nie potwierdzenie dla macOS/Linux. Warunki są konkretne: Windows, Cursor, malicious executable nazwany dokładnie git.exe i zachowanie ładowania projektu, które wywołuje Git discovery.

Co wiadomo

Mindgard mówi, że Cursor sprawdza kilka lokalizacji dla Git i może wykonać binary z workspace. Cyber Security News cytował logi Process Monitor, gdzie Cursor.exe uruchamia plik poleceniem git rev-parse --show-toplevel. The Hacker News dodał zastrzeżenie: publiczny opis nie przesądza, czy Cursor sam szuka w workspace, czy przekazuje Windows gołe git, a system stosuje swoją kolejność wyszukiwania.

Dla obrony skutek jest podobny: plik z projektu przechodzi z „czytany” do „wykonany” przed jasną decyzją zaufania. To stara klasa — untrusted search path / current-directory executable resolution — w nowym kontekście AI IDE.

Ważne ograniczenie: The Hacker News podał, że ostatnia datowana weryfikacja Mindgard dotyczyła Cursor 3.2.16 z 30 kwietnia, a aktualna wtedy wersja to 3.11 z 10 lipca. Nie znaleziono oficjalnego advisory Cursor ani CVE konkretnie dla tego git.exe. Zespoły powinny sprawdzić własną wersję, changelog i ustawienia.

Stanowisko Cursor

Cursor uznał report za poza zakresem bug bounty. Firma mówi o shared responsibility: klienci wybierają repozytoria, prompty, MCP servers, rules and tools, a Cursor daje controls for trust boundary. Warunki mają być wąskie: Windows i folder z malicious git.exe w root. Cursor wskazuje Workspace Trust / restricted mode i przyznaje, że komunikacja z badaczem była spóźniona.

Shared responsibility ma sens, ale nie usuwa product responsibility. „Otworzyłem folder, żeby czytać kod” to nie „zgodziłem się uruchomić binary z tego folderu”. Im więcej IDE automatyzuje, tym wyraźniejsza musi być granica między reading and running.

Dlaczego to ważne bez paniki

Dyskusja na Hacker News była przewidywalna. Jedni mówią, że malicious executable w repo to znane ryzyko Windows. Drudzy odpowiadają, że klonowanie i otwieranie repozytoriów to normalna praca maintainerów, reviewerów i security teams. Różnica między ręcznym uruchomieniem polecenia a startem przy otwieraniu projektu to właśnie trust boundary.

W sprawdzonych źródłach nie ma potwierdzonego exploitation in the wild. To obniża alarm, ale nie zastępuje kontroli.

Nie mylić z DuneSlide

DuneSlide, CVE-2026-50548 i CVE-2026-50549, to inny przypadek Cursor: prompt injection i sandbox escape, według The Hacker News naprawione w Cursor 3.0. Sprawa Mindgard git.exe dotyczy local executable resolution podczas ładowania projektu.

Co zrobić

Zaktualizuj Cursor i śledź oficjalne notatki. Włącz Workspace Trust lub restricted mode dla nieznanych folderów. Nie otwieraj obcych repozytoriów na głównym hoście: użyj Windows Sandbox, VM, devcontainer albo disposable cloud environment. Sprawdź root projektu pod kątem executables, .cmd, .ps1, hooks, tasks and wrappers.

Zespoły powinny mieć praktyczną politykę: unknown repos w izolacji, production secrets poza zwykłymi sesjami dev, agenci bez szerokich cloud-admin privileges. Na Windows można testować AppLocker lub Windows Defender Application Control dla ścieżek workspace. EDR może alarmować, gdy Cursor.exe uruchamia binary z katalogu repo.

Lekcja

To nie powód do paniki wokół Cursor. To powód, by traktować developer workstation jako attack surface. Nieznane repozytoria są executable content until proven otherwise. Narzędzia AI potrzebują bezpieczniejszych defaultów i widocznych granic zaufania.