Złośliwe konfiguracje .git zagrażają agentom AI: Claude, Codex i Cursor mogą uruchamiać kod atakującego

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa ujawnili nową klasę zagrożeń, która dotyczy agentów AI wykorzystywanych do pracy z kodem źródłowym. Problem nie wynika bezpośrednio z działania samego modelu językowego, lecz z tego, w jaki sposób narzędzia pomocnicze obsługują lokalne repozytoria Git. Jeśli projekt zostanie dostarczony wraz z katalogiem .git i zawiera złośliwą konfigurację, agent AI może nieświadomie uruchomić komendy kontrolowane przez atakującego.

W praktyce oznacza to ryzyko lokalnego wykonania kodu na stacji roboczej dewelopera. Taki scenariusz jest szczególnie groźny, ponieważ kod może zostać uruchomiony z uprawnieniami użytkownika, poza sandboxem narzędzia i bez oczekiwanego etapu zatwierdzania.

W skrócie

Ujawnione podatności obejmują kilka popularnych narzędzi z kategorii AI coding agents. Wspólny mechanizm polega na automatycznym wykonywaniu poleceń Git w tle w celu ustalenia stanu repozytorium, aktywnej gałęzi czy listy zmodyfikowanych plików. Jeżeli lokalna konfiguracja repozytorium zawiera niebezpieczne ustawienia, operacje te mogą doprowadzić do uruchomienia złośliwego kodu.

• atak wykorzystuje lokalną konfigurację repozytorium Git,
• nie wymaga prompt injection ani interakcji z modelem,
• może zostać aktywowany już przy otwarciu projektu,
• kod wykonuje się z uprawnieniami bieżącego użytkownika,
• zagrożenie dotyczy zarówno narzędzi CLI, jak i środowisk zintegrowanych z IDE.

Kontekst / historia

Sam mechanizm nie jest całkowicie nowy z perspektywy bezpieczeństwa ekosystemu programistycznego. Od lat wiadomo, że nadmierne zaufanie do lokalnych ustawień repozytorium i metadanych projektu może prowadzić do niepożądanych działań jeszcze przed pełnym zaufaniem użytkownika do kodu. Nowością jest jednak skala ryzyka wynikająca z automatyzacji wprowadzanej przez agentów AI.

Nowoczesne narzędzia wspierające programistów coraz częściej samodzielnie analizują strukturę projektu zaraz po otwarciu katalogu. Sprawdzają historię zmian, różnice między plikami i kontekst repozytorium, aby szybciej przygotować odpowiedzi lub wykonać zadania. To właśnie ten etap inicjalizacji staje się podatny na nadużycia, jeśli implementacja bezpiecznie nie filtruje lokalnej konfiguracji Git.

Analiza techniczna

Kluczowy element ataku stanowią ustawienia konfiguracyjne Git, które mogą wskazywać zewnętrzny program lub polecenie wywoływane podczas operacji na repozytorium. Jednym z najczęściej wskazywanych wektorów jest parametr core.fsmonitor, używany do optymalizacji wykrywania zmian w plikach. Jeśli jego wartość zostanie ustawiona na polecenie przygotowane przez atakującego, wykonanie typowych komend, takich jak git status czy git diff, może uruchomić nieautoryzowany kod.

Agenty AI regularnie wykonują właśnie takie operacje w tle, aby zebrać kontekst potrzebny do pracy. Jeżeli narzędzie przejmuje zaufanie do ustawień zapisanych w .git/config, lokalna konfiguracja dostarczona razem z projektem staje się nośnikiem ataku.

• wykonanie następuje lokalnie, na komputerze ofiary,
• atak może zostać uruchomiony jeszcze przed akceptacją zaufania do workspace,
• mechanizm nie wymaga skłaniania modelu do błędnego działania,
• wektor bazuje na integracji z Git i procesach podrzędnych,
• problem może dotyczyć wielu produktów korzystających z podobnego schematu automatyzacji.

To przesuwa punkt ciężkości z klasycznych zagrożeń związanych z prompt injection na bezpieczeństwo lokalnego łańcucha narzędzi deweloperskich. W tym przypadku podatna okazuje się warstwa integracyjna, a nie sam model AI.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją jest możliwość lokalnego wykonania kodu na stacji roboczej dewelopera. Taki kod może posłużyć do odczytu lub modyfikacji plików, przejęcia tokenów dostępowych, kluczy SSH, danych sesyjnych czy konfiguracji usług chmurowych.

Ryzyko wzrasta szczególnie wtedy, gdy organizacja dopuszcza wymianę repozytoriów poza standardowym procesem git clone, korzysta z archiwów ZIP, współdzielonych folderów lub nośników przenośnych, a jednocześnie uruchamia narzędzia AI z szerokimi uprawnieniami lokalnymi. W takim środowisku pojedynczy projekt może stać się punktem wyjścia do dalszej kompromitacji.

• kradzież poświadczeń i sekretów deweloperskich,
• ruch boczny do systemów CI/CD lub chmury,
• manipulacja kodem źródłowym i artefaktami budowania,
• utrata integralności środowiska pracy,
• eskalacja incydentu z pojedynczej stacji na infrastrukturę organizacji.

Rekomendacje

Podstawowym krokiem powinno być zaktualizowanie wszystkich agentów AI, klientów desktopowych i komponentów CLI do wersji zawierających poprawki bezpieczeństwa. Organizacje powinny również zweryfikować, które narzędzia w ich środowisku automatycznie wykonują polecenia Git podczas otwierania projektu lub inicjalizacji sesji.

• nie otwierać niezweryfikowanych repozytoriów dostarczonych jako katalog lub archiwum z zachowanym .git,
• sprawdzać zawartość pliku .git/config przed użyciem projektu,
• zwracać uwagę na ustawienia takie jak core.fsmonitor, core.hooksPath oraz niestandardowe filtry,
• wymuszać bezpieczne wywołania Git i ignorowanie ryzykownych kluczy konfiguracyjnych,
• ograniczać uprawnienia kont deweloperskich i separować środowiska testowe od zasobów wrażliwych,
• monitorować procesy potomne uruchamiane przez IDE i narzędzia AI,
• stosować kontrolę aplikacji, EDR oraz polityki allowlist dla interpreterów i skryptów.

Z perspektywy producentów oprogramowania dobrą praktyką jest uruchamianie wszystkich automatycznych operacji Git w trybie bezpiecznym, z wyłączonym zaufaniem do lokalnych ustawień zdolnych do uruchamiania poleceń. Równie ważne jest, aby komunikat o zaufaniu do workspace pojawiał się zanim narzędzie wykona jakąkolwiek akcję mogącą aktywować kod z repozytorium.

Podsumowanie

Opisany przypadek pokazuje, że rozwój agentów AI dla programistów tworzy nową powierzchnię ataku na styku automatyzacji i tradycyjnych narzędzi developerskich. Z pozoru niewinna operacja, taka jak sprawdzenie statusu repozytorium, może zostać przekształcona w lokalne wykonanie kodu poza sandboxem i bez pełnej wiedzy użytkownika.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że ocena ryzyka związanego z AI coding agents nie może ograniczać się wyłącznie do modeli, promptów i dostępu do API. Równie istotne są mechanizmy inicjalizacji projektu, wywołania procesów podrzędnych oraz sposób obsługi lokalnej konfiguracji Git. W najbliższym czasie można spodziewać się kolejnych badań ujawniających podobne wzorce w innych narzędziach wspierających rozwój oprogramowania.

Źródła

1. The Hacker News — https://thehackernews.com/2026/09/malicious-git-configs-can-make-claude.html
2. Manifold Security — GitSpawn — https://www.manifold.security/blog/gitspawn
3. OpenAI Security Advisory / CVE-2026-19592 — https://openai.com/security/advisories/cve-2026-19592
4. GitHub Advisory Database — CVE-2026-72718 — https://github.com/advisories/GHSA-7j4c-m5x2-7qgh
5. SonarSource Research — https://www.sonarsource.com/blog/