--- service: "Publicasta" schema_version: "1.0" article_id: 168 title: "Cursor, git.exe i granica zaufania na komputerach programistów" language: "pl" default_language: "en" canonical_url: "https://publicasta.com/cybersecurity/cursor_repo_poisoning_windows_trust_boundary_2026_07_19?lang=pl" json_url: "https://publicasta.com/cybersecurity/cursor_repo_poisoning_windows_trust_boundary_2026_07_19.json?lang=pl" api_url: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles/cursor_repo_poisoning_windows_trust_boundary_2026_07_19?lang=pl" channel_url: "https://publicasta.com/api/public/v1/channels/cybersecurity" channel_articles: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-07-19T17:17:07+00:00" updated_at: "2026-07-19T17:17:07+00:00" translations: - language: "de" html_url: "https://publicasta.com/cybersecurity/cursor_repo_poisoning_windows_trust_boundary_2026_07_19?lang=de" markdown_url: "https://publicasta.com/cybersecurity/cursor_repo_poisoning_windows_trust_boundary_2026_07_19.md?lang=de" json_url: "https://publicasta.com/cybersecurity/cursor_repo_poisoning_windows_trust_boundary_2026_07_19.json?lang=de" - language: "en" html_url: "https://publicasta.com/cybersecurity/cursor_repo_poisoning_windows_trust_boundary_2026_07_19?lang=en" markdown_url: "https://publicasta.com/cybersecurity/cursor_repo_poisoning_windows_trust_boundary_2026_07_19.md?lang=en" json_url: "https://publicasta.com/cybersecurity/cursor_repo_poisoning_windows_trust_boundary_2026_07_19.json?lang=en" - language: "es" html_url: "https://publicasta.com/cybersecurity/cursor_repo_poisoning_windows_trust_boundary_2026_07_19?lang=es" markdown_url: "https://publicasta.com/cybersecurity/cursor_repo_poisoning_windows_trust_boundary_2026_07_19.md?lang=es" json_url: "https://publicasta.com/cybersecurity/cursor_repo_poisoning_windows_trust_boundary_2026_07_19.json?lang=es" - language: "fr" html_url: "https://publicasta.com/cybersecurity/cursor_repo_poisoning_windows_trust_boundary_2026_07_19?lang=fr" markdown_url: "https://publicasta.com/cybersecurity/cursor_repo_poisoning_windows_trust_boundary_2026_07_19.md?lang=fr" json_url: "https://publicasta.com/cybersecurity/cursor_repo_poisoning_windows_trust_boundary_2026_07_19.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/cybersecurity/cursor_repo_poisoning_windows_trust_boundary_2026_07_19?lang=pl" markdown_url: "https://publicasta.com/cybersecurity/cursor_repo_poisoning_windows_trust_boundary_2026_07_19.md?lang=pl" json_url: "https://publicasta.com/cybersecurity/cursor_repo_poisoning_windows_trust_boundary_2026_07_19.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/cybersecurity/cursor_repo_poisoning_windows_trust_boundary_2026_07_19?lang=ru" markdown_url: "https://publicasta.com/cybersecurity/cursor_repo_poisoning_windows_trust_boundary_2026_07_19.md?lang=ru" json_url: "https://publicasta.com/cybersecurity/cursor_repo_poisoning_windows_trust_boundary_2026_07_19.json?lang=ru" --- # Cursor, git.exe i granica zaufania na komputerach programistów > Sprawa Cursor nie wymaga paniki. Pokazuje, że nieznane repozytoria, narzędzia AI i Windows workstations potrzebują ostrzejszych granic zaufania. 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](https://publicasta.com/storage/projects/9/pages/168/2026/07/e0ff711c-833e-4abc-bdc4-f2e4b0ab07ea.webp) 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.