Asystenci programowania AI, tacy jak Claude Code, Cursor i Grok Build, mogą wykonywać dowolne polecenia w momencie, gdy programista otworzy niezaufane repozytorium, bez żadnego kliknięcia czy zapytania. Wada wynika ze sposobu, w jaki te narzędzia wywołują funkcję core.fsmonitor systemu Git w celu skanowania plików projektu.

Dlaczego to ma teraz znaczenie

Programiści coraz częściej polegają na agentach AI w celu sugerowania kodu, refaktoryzacji funkcji, a nawet pisania całych modułów. Agenci ci potrzebują szybkiego podglądu obszaru roboczego, więc w tle uruchamiają git status. Gdy Git odczytuje plik .git/config repozytorium, każda wartość przypisana do core.fsmonitor jest traktowana jako polecenie powłoki (shell command), które Git wykona. Złośliwy aktor może umieścić przygotowane polecenie w tym wpisie konfiguracyjnym, a działanie Gita w tle, wywołane przez AI, uruchomi je, zanim użytkownik wpisze choćby jedną linię kodu.

Kod działa z uprawnieniami samego programisty, omijając piaskownicę (sandbox), w której zazwyczaj operuje agent AI. W praktyce zainfekowane repozytorium może zainstalować złośliwe oprogramowanie, wyeksfiltrować dane uwierzytelniające lub zmodyfikować pliki źródłowe – a wszystko to podczas gdy programista wierzy, że asystent jedynie oferuje sugestie.

Jak przebiega atak

  1. Przygotowanie – Atakujący tworzy repozytorium, którego .git/config zawiera linię typu core.fsmonitor = /path/to/malicious/script.
  2. Dostarczenie – Repozytorium jest przekazywane jako plik zip, kopiowane z pendrive'a, synchronizowane przez wspólny dysk lub w inny sposób umieszczane na maszynie ofiary wraz z już istniejącym folderem .git.
  3. Wyzwalacz – Programista otwiera folder w IDE wspieranym przez AI. Asystent uruchamia git status, aby zebrać kontekst. Git odczytuje lokalną konfigurację, wykonuje polecenie core.fsmonitor, a złośliwy skrypt uruchamia się natychmiast.

Zwykłe git clone nie naraża na to ryzyko, ponieważ klonowanie tworzy nowy katalog .git, który nie posiada zmodyfikowanej konfiguracji. Atak działa tylko wtedy, gdy atakujący może dostarczyć już istniejący folder .git.

Co jest zagrożone

  • Indywidualni programiści mogą mieć zainfekowane maszyny bez własnej wiedzy, tracąc wszelkie dane, do których może uzyskać dostęp agent AI.
  • Zespoły, które udostępniają kod przez wewnętrzne dyski lub pliki zip od kontrahentów, mogą rozprzestrzenić ładunek (payload) na wiele stacji roboczych.
  • Dostawcy narzędzi ryzykują utratę reputacji, jeśli użytkownicy przypiszą naruszenie bezpieczeństwa asystentowi AI, a nie samej interakcji z systemem Git.

Ponieważ złośliwe polecenie dziedziczy uprawnienia użytkownika, może ono zmodyfikować każdy plik, do którego dostęp ma programista, w tym klucze SSH, skrypty budowania czy dane uwierzytelniające do wdrożeń.

Kroki łagodzące, które programiści mogą podjąć już dziś

  • Nie ufaj lokalnym ustawieniom Git. Konfiguracja repozytorium nadpisuje wartości globalne za każdym razem, gdy asystent AI odpytuje projekt.

  • Sprawdź wpis core.fsmonitor przed otwarciem folderu z asystentem:

    git config --get core.fsmonitor
    

    Jeśli pojawi się jakakolwiek wartość, potraktuj ją jako podejrzaną.

  • Usuń wpis za pomocą:

    git config --local --unset core.fsmonitor
    
  • Sprawdź inne ryzykowne klucze, które Git może wykonać: hooksPath, sshCommand, pager, editor, filter. Użyj tego samego wzorca git config --get, aby upewnić się, że są puste.

  • Wybieraj czyste klony dla każdego kodu, który zamierzasz przekazać narzędziu AI. Jeśli musisz pracować z plikiem zip lub przeniesionym folderem, usuń jego katalog .git i zainicjuj repozytorium ponownie lub najpierw przeprowadź powyższe kontrole.

Gdzie leży odpowiedzialność

Podatność ta nie jest błędem w modelach językowych zasilających Claude Code, Cursor czy Grok Build; jest ona konsekwencją sposobu, w jaki te narzędzia zbierają informacje o plikach. Niektórzy dostawcy zaczęli ściślej izolować (sandbox) wywołania Gita, ale domyślne zachowanie wciąż polega na ufaniu lokalnym ustawieniom repozytorium. Dopóki branża nie przyjmie standardu, który usuwa lub ignoruje potencjalnie niebezpieczne wpisy konfiguracyjne podczas skanowania obszaru roboczego przez agenta AI, programiści muszą pozostać ostatnią linią obrony.

Na co zwracać uwagę w przyszłości

  • Aktualizacje narzędzi, które