Git łata krytyczną lukę umożliwiającą wykonanie kodu podczas rekurencyjnego klonowania

Wprowadzenie do problemu / definicja

Git otrzymał poprawki bezpieczeństwa usuwające krytyczną podatność oznaczoną jako CVE-2026-111760. Problem dotyczy rekurencyjnego klonowania repozytoriów wraz z submodułami i w określonych warunkach może doprowadzić do wykonania kodu kontrolowanego przez atakującego na stacji roboczej programisty lub w środowisku automatyzacji.

To szczególnie istotna luka z perspektywy bezpieczeństwa łańcucha dostaw oprogramowania, ponieważ sam proces pobrania repozytorium może stać się punktem wejścia do dalszej kompromitacji środowiska deweloperskiego lub CI/CD.

W skrócie

Podatność CVE-2026-111760 została załatana w Git 2.56.1 oraz w wydaniach utrzymaniowych 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1 i 2.55.1. Mechanizm ataku wykorzystuje manipulację bardzo długimi ścieżkami w indeksie Git, co pozwala obejść część kontroli bezpieczeństwa i doprowadzić do zapisania danych pod nazwą wskazaną przez napastnika.

zagrożone są przede wszystkim operacje typu git clone --recurse-submodules,
atak może prowadzić do podmiany pliku .git w submodule,
efektem może być uruchomienie złośliwych hooków lub niebezpiecznej konfiguracji,
największe ryzyko dotyczy nieufnych repozytoriów i zautomatyzowanych pipeline’ów.

Kontekst / historia

Git od wielu lat stanowi podstawowe narzędzie kontroli wersji w projektach komercyjnych i open source. Każda podatność wpływająca na sposób klonowania, aktualizacji lub przetwarzania repozytoriów ma więc znaczenie wykraczające poza pojedynczy komputer użytkownika. W praktyce może uderzać w całe procesy wytwarzania oprogramowania, systemy buildowe oraz platformy testujące kod pochodzący z zewnętrznych źródeł.

Szczególnie wrażliwym obszarem pozostają submoduły, ponieważ automatyzują pobieranie dodatkowych zależności i rozszerzają powierzchnię ataku. W omawianym przypadku luka została ujawniona razem z pakietem kilku innych poprawek bezpieczeństwa, obejmujących również błędy związane z obsługą referencji, pamięci, łatek binarnych oraz funkcji importu danych.

Analiza techniczna

Rdzeniem CVE-2026-111760 jest błąd typu integer truncation w obsłudze indeksu Git. Atakujący może przygotować repozytorium zawierające ekstremalnie długą ścieżkę, która przechodzi walidację bezpieczeństwa, ale na późniejszym etapie zostaje zapisana na dysku pod skróconą nazwą. Ta niespójność pomiędzy nazwą sprawdzaną a nazwą faktycznie zapisywaną otwiera drogę do podstawienia krytycznego pliku lub odniesienia.

W scenariuszu z submodułami problem staje się szczególnie groźny. Git zwykle nie pozwala zastąpić katalogu .git dowiązaniem symbolicznym, jednak w świeżo sklonowanym submodule .git może występować jako plik. To umożliwia manipulację odniesieniem tak, aby wskazywało ono lokalizację kontrolowaną przez napastnika.

Jeżeli przygotowany katalog zawiera złośliwe hooki albo spreparowaną konfigurację, kolejne operacje Git mogą doprowadzić do wykonania obcego kodu. W praktyce jest to klasyczny przykład luki wynikającej z rozbieżności między walidacją danych wejściowych a ich późniejszą reprezentacją w warstwie zapisu.

Najbardziej narażone są środowiska, w których Git działa automatycznie lub z wysokim poziomem zaufania:

stacje robocze programistów,
runnery CI/CD,
systemy budowania artefaktów,
platformy analizujące pull requesty i merge requesty,
narzędzia desktopowe i serwerowe dostarczające własną, osadzoną wersję Git.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją luki jest możliwość wykonania kodu w kontekście użytkownika lub procesu uruchamiającego rekurencyjne klonowanie. Taki scenariusz może prowadzić do przejęcia sesji deweloperskiej, kradzieży tokenów dostępowych, manipulacji kodem źródłowym lub skażenia pipeline’u CI/CD.

W środowiskach organizacyjnych ryzyko należy oceniać jako wysokie zwłaszcza wtedy, gdy zespoły regularnie klonują publiczne repozytoria, automatycznie pobierają submoduły albo korzystają z narzędzi, które zawierają własne kopie Git. Problem może także utrzymywać się mimo aktualizacji centralnych platform, jeśli nie zostaną zaktualizowane obrazy bazowe, kontenery deweloperskie, agenci buildowi i starsze systemy serwerowe.

Rekomendacje

Podstawowym działaniem obronnym jest natychmiastowa aktualizacja Git do wersji naprawczej właściwej dla używanej gałęzi utrzymaniowej. Trzeba przy tym pamiętać, że aktualizacji wymagają również wszystkie aplikacje i platformy, które dostarczają własny egzemplarz tego narzędzia.

Z perspektywy operacyjnej warto wdrożyć następujące środki:

ograniczyć użycie rekurencyjnego klonowania wobec nieufnych źródeł,
traktować submoduły jako element podwyższonego ryzyka,
izolować procesy klonowania w kontenerach, sandboxach lub efemerycznych runnerach,
monitorować wykonanie hooków Git i nietypowe operacje na plikach .git,
przejrzeć obrazy CI/CD, środowiska developerskie i systemy automatyzacji pod kątem osadzonych wersji Git,
prowadzić inwentaryzację zależności narzędziowych w łańcuchu dostaw oprogramowania.

Jeżeli szybka aktualizacja nie jest możliwa, organizacje powinny tymczasowo unikać poleceń rekurencyjnego klonowania dla repozytoriów spoza zaufanego katalogu źródeł. To jednak jedynie działanie ograniczające ekspozycję, a nie pełna mitygacja problemu.

Podsumowanie

CVE-2026-111760 pokazuje, że narzędzia developerskie pozostają atrakcyjnym wektorem ataku na łańcuch dostaw oprogramowania. W tym przypadku pojedyncza operacja rekurencyjnego klonowania może otworzyć drogę do wykonania kodu i kompromitacji środowiska pracy.

Dla organizacji oznacza to konieczność szybkiej aktualizacji Git, przeglądu użycia submodułów oraz ograniczenia zaufania do zewnętrznych repozytoriów. Bezpieczeństwo procesu SCM powinno być traktowane równie poważnie jak bezpieczeństwo aplikacji produkcyjnych.