Sześć luk w Git: zaktualizuj nie tylko wiersz poleceń

Jeśli zaktualizowano Git w terminalu, praca jeszcze się nie skończyła: osobne aplikacje i środowiska kompilacji mogą uruchamiać własną kopię. 10 listopada 2026 roku projekt Git opublikował poprawki sześciu luk — od wykonania kodu podczas rekurencyjnego klonowania po uszkodzenie pamięci przy scalaniu. Dlatego trzeba sprawdzić każde środowisko, które obsługuje repozytoria lub ich zawartość, a nie tylko wynik polecenia git --version w powłoce.

Co zmieniło się w aktualizacji

Poprawki znalazły się w Git 2.56.1 i zostały przeniesione do obsługiwanych gałęzi: 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 i 2.50.2. Aktualizacja usuwa sześć problemów w różnych częściach Git — związanych ze ścieżkami, dowiązaniami, podpisami, łatami binarnymi, scalaniem i strumieniami importu. GitHub opublikował omówienie luk i zalecenie aktualizacji 10 listopada; informacje o wydaniu Git 2.56.1 zawierają listę CVE naprawionych w tej serii.

W praktyce trzeba zaktualizować Git w trzech miejscach: na komputerach roboczych, w automatyzacji oraz wewnątrz aplikacji, które zawierają własną kompilację Git. Ten ostatni punkt łatwo przeoczyć: aktualizacja pakietu systemowego nie zmienia automatycznie wersji w każdym kliencie ani obrazie środowiska kompilacji.

Dlaczego warto zwrócić uwagę na rekurencyjne klonowanie

Najbardziej czytelny scenariusz zaczyna się od rekurencyjnego klonowania niezaufanego repozytorium. W wyniku obcięcia długości ścieżki bardzo długi wpis mógł przejść kontrolę pod jedną nazwą, a następnie zostać zapisany na dysku pod skróconą. W opisanym scenariuszu Git umożliwiało to zastąpienie pliku .git podmodułu dowiązaniem symbolicznym do katalogu zawierającego złośliwą konfigurację lub hooki. Przy kolejnym użyciu Git mógł wykonać kod określony przez atakującego.

W praktyce chodzi o specjalnie przygotowane repozytorium i konkretną operację. Zespoły, które regularnie klonują projekty z zewnętrznych źródeł z parametrem --recurse-submodules, powinny w pierwszej kolejności zaktualizować środowiska klienckie i automatyzację. Poprawka odrzuca nadmiernie długie ścieżki, zanim ich długość zostanie obcięta.

Inne miejsca, w których Git przetwarza niezaufane dane

Inny problem pojawia się podczas klonowania pustego repozytorium przez Git protocol v2. Serwer mógł przekazać odwołanie HEAD z nazwą gałęzi zawierającą komponenty służące do przechodzenia do katalogów nadrzędnych; późniejsza operacja aktualizacji gałęzi mogła zapisać plik poza oczekiwanym katalogiem odwołań. W poprawionych wersjach Git sprawdza taki cel oraz inne nazwy odwołań otrzymane przez protokół.

Osobne luki dotyczyły operacji scalania i łat. Podczas przetwarzania podpisów stała tablica zakładała maksymalnie dwa podpisy; specjalnie spreparowany komunikat z większą ich liczbą mógł spowodować zapis poza granicami tablicy i uszkodzenie pamięci. Przy stosowaniu łaty binarnej kontrola rozmiaru uwzględniała pierwotną reprezentację, chociaż skompresowane dane mogą po rozpakowaniu zajmować znacznie więcej miejsca. Teraz Git sprawdza deklarowany rozmiar nieskompresowanych danych przed ich przetworzeniem.

Duże scalenia również mogły doprowadzić do przepełnienia przy obliczaniu wymaganej wielkości bufora, a następnie do zapisu poza jego granicami. Dotyczy to między innymi usług hostingowych i aplikacji scalających niezaufaną zawartość. Wreszcie trzy funkcje git fast-import zostały ograniczone w przypadku poleceń pochodzących ze strumienia wejściowego: rewrite-submodules-from i rewrite-submodules-to mogły odczytywać dowolne pliki, a export-pack-edges — tworzyć pliki lub dopisywać dane do istniejących. Teraz te funkcje są blokowane, o ile jawnie nie podano flagi --allow-unsafe-features; należy jej używać wyłącznie w przypadku zaufanego generatora strumienia.

Gdzie szukać osobnych kopii Git

Programista może zacząć od zinwentaryzowania miejsc uruchamiania Git. Sprawdź wersję w terminalu i skorzystaj ze standardowej funkcji sprawdzania aktualizacji w IDE oraz desktopowych klientach Git. Następnie sprawdź obrazy CI, kontenery, runner-y i zadania serwerowe, które klonują lub scalają repozytoria, stosują łaty binarne albo uruchamiają fast-import. Sama obecność aktualnego Git na hoście nie gwarantuje, że aplikacja korzysta właśnie z niego.

W organizacjach warto sprawdzić nie tylko obrazy źródłowe, ale też już wdrożone środowiska: trwały runner lub wewnętrzna usługa mogły zachować stary plik binarny po aktualizacji obrazu bazowego. W przypadku GitHub Enterprise Server GitHub wskazuje poprawione wersje 3.19.15, 3.20.11, 3.21.9 i 3.22.4. Firma poinformowała, że wdrożyła już poprawki na github.com i GitHub Enterprise Cloud, w tym w wariantach z lokalizacją danych. Wydania GitHub Desktop i aplikacji GitHub Copilot z poprawionym Git są koordynowane; poprawione wersje dla Codespaces i GitHub Actions mają się jeszcze pojawić.

Jak ograniczyć ryzyko przed aktualizacją

Jeśli nie można od razu zainstalować poprawki, tymczasowo ogranicz operacje na niezaufanych danych: klonuj repozytoria wyłącznie z zaufanych serwerów, unikaj rekurencyjnego klonowania niesprawdzonych projektów, nie scalaj ich zawartości ani nie stosuj otrzymanych od nich łat binarnych lub strumieni fast-import. Te działania ograniczają kontakt z konkretnymi podatnymi scenariuszami, ale nie zastępują aktualizacji.

Główny praktyczny wniosek jest prosty: poprawki Git trzeba szukać tam, gdzie program rzeczywiście uruchamia Git. Polecenie w terminalu to tylko jedno z takich miejsc; klienci programistyczni, CI i usługi obsługujące repozytoria wymagają osobnej kontroli.