Asystenci kodu AI mogą zostać przejęci przez złośliwy wpis w .git/config, który wykorzystuje funkcję Gita core.fsmonitor, umożliwiając niezaufanemu repozytorium uruchamianie komend na maszynie programisty w momencie, gdy asystent skanuje pliki.

Luka ta ujawniła się w kilku popularnych agentach — Claude Code, Cursor, OpenAI Codex, Goose, Qwen Code, Grok Build i Hermes. W poprawionych agentach exploit nie działa już; pozostałe pozostają podatne. Nie są wymagane żadne dodatkowe kliknięcia ani potwierdzenia, a złośliwy kod uruchamia się z uprawnieniami samego użytkownika, poza jakimkolwiek sandboxem, który może zapewniać agent AI.

Jak atak dociera do programisty

  • Kontrahent pakuje projekt do archiwum ZIP i wysyła go e-mailem.
  • Współpracownik udostępnia folder na dysku sieciowym.
  • Przekazywany jest pendrive z kodem źródłowym.

W każdym z tych przypadków repozytorium przychodzi jako katalog, który już zawiera folder .git. Gdy asystent AI otwiera folder, zazwyczaj uruchamia w tle git status, aby zbudować widok kodu. Git przyspiesza tę operację za pomocą ustawienia core.fsmonitor, które instruuje Gita, aby wywołał zewnętrzny program monitorujący zmiany w systemie plików. Jeśli plik .git/config repozytorium definiuje złośliwą komendę dla core.fsmonitor, Git wykona ją automatycznie, bez pytania użytkownika o zgodę.

Ponieważ komenda jest uruchamiana przez samego Gita, dziedziczy ona uprawnienia użytkownika i omija wszelki sandbox, który mógł zostać ustawiony przez narzędzie AI. Exploit nie aktywuje się podczas standardowych operacji git clone, git fetch czy git pull; uruchamia się dopiero wtedy, gdy repozytorium zostanie rozpakowane wraz z już obecnymi metadanymi .git.

Dlaczego ten problem jest istotny

Programiści coraz częściej polegają na asystentach AI w celu sugerowania uzupełnień, refaktoryzacji kodu czy generowania całych modułów. Narzędzia te potrzebują szybkiego podglądu drzewa plików projektu, więc po cichu wywołują komendy Gita. Jeśli złośliwe repozytorium może w tym momencie wykonać kod, napastnik uzyskuje przyczółek na stacji roboczej programisty bez żadnego widocznego ostrzeżenia. Potencjalny ładunek może obejmować wszystko — od kradzieży poświadczeń po instalację trwałych backdoorów — a wszystko to dzieje się, podczas gdy użytkownik wierzy, że jedynie „sprawdza” kod z pomocą asystenta AI.

Wykrywanie zatrutego repozytorium

Zanim przekażesz repozytorium asystentowi, uruchom:

git config --get core.fsmonitor

Niepusty wynik oznacza, że program został ustawiony do automatycznego uruchamiania. Aby przeprowadzić szerszy przegląd, wypisz wszelkie podejrzane ustawienia Gita:

git config --local --list | grep -Ei 'fsmonitor|hooksPath|sshCommand|pager|editor|filter\.'

Jeśli zauważysz wpisy, których nie dodałeś, wyczyść je za pomocą:

git config --local --unset core.fsmonitor

Pamiętaj, że ustawienie git config --global core.fsmonitor false nie zapewnia ochrony. Lokalna konfiguracja repozytorium zawsze nadpisuje ustawienia globalne, więc złośliwe repozytorium może po prostu zignorować globalną regułę.

Obecny stan poprawek

  • Claude Code – poprawiony (fsmonitor)
  • Cursor – poprawiony
  • OpenAI Codex – poprawiony
  • Goose – poprawiony
  • Qwen Code – niepoprawiony
  • Grok Build – niepoprawiony
  • Hermes – niepoprawiony

Programiści korzystający z niepoprawionych agentów powinni traktować każde przychodzące repozytorium jako potencjalnie niebezpieczne, dopóki nie zmienią narzędzi lub nie wprowadzą surowszych lokalnych polityk Gita.

Kontrargument ze strony społeczności Git

core.fsmonitor w Gicie to legalna funkcja wydajnościowa, a nie błąd. Utrzymujący argumentują, że odpowiedzialność spoczywa na wywołujących, którzy powinni walidować zawartość repozytorium przed wywołaniem komend Gita. Globalne wyłączenie tej funkcji jest prostą metodą łagodzenia skutków, ale jak zauważono, lokalne nadpisania mogą tę ochronę obejść. Szersza dyskusja koncentruje się obecnie na tym, czy asystenci AI powinni izolować (sandbox) wszystkie zewnętrzne wywołania Gita, czy też odmawiać przetwarzania repozytoriów zawierających niestandardowe hooki fsmonitor.

Na co zwrócić uwagę w przyszłości

  • Aktualizacje od niepoprawionych agentów AI — zwłaszcza wszelkie oświadczenia dotyczące izolowania (sandboxing) wywołań Gita.
  • Potencjalne zmiany w domyślnym sposobie obsługi core.fsmonitor przez Gita dla niezaufanych katalogów.
  • Narzędzia firm trzecich, które mogą oczyścić plik .git/config repozytorium, zanim trafi ono do asystenta.

Podsumowanie

Pojedyncza linia w ukrytym pliku konfiguracyjnym może zmienić wygodę oferowaną przez AI w wektor zdalnego wykonywania kodu. Dopóki podatne agenty nie zostaną naprawione, najbezpieczniejszą praktyką jest audyt każdego repozytorium, które przychodzi poza standardowym procesem git clone, oraz usunięcie wszelkich hooków core.fsmonitor lub podobnych, zanim pozwoli się asystentowi AI dotknąć kodu.