Ing. Calogero Bono
Il progetto Git ha rilasciato la wersja 2.56.1, żeby poprawić sześć luk bezpieczeństwa. Jedna z nich pozwala uruchomić cudzy kod, gdy klonujesz rekurencyjnie złośliwe repozytorium. Pozostałe dotyczą zapisu do nieprzewidzianych plików oraz uszkodzeń pamięci podczas scalania i w binarnych łatach. Ma to znaczenie, bo Git jest zaszyty w edytorach, narzędziach automatyzacji i serwerach wielu firm, więc trzeba go zaktualizować wszędzie.
Kilka pojęć, zanim przejdziemy do faktów. Klon rekurencyjny to kopia repozytorium razem z jego submodułami. Submoduł to repozytorium osadzone w innym repozytorium. Hooki to programy, które Git uruchamia w określonych momentach. Path traversal to użycie ścieżek ze specjalnymi komponentami, by wyjść poza dozwolony katalog. CVE to kod identyfikujący publicznie znaną lukę.
Co wydał projekt Git?
Według bloga GitHuba poprawki znajdują się w wersji 2.56.1. Istnieją też backporty dla serii 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 i 2.50.2.
GitHub zaleca przejście na 2.56.1 lub poprawną wersję swojej serii oraz aktualizację aplikacji, które zawierają kopię Gita. Kto czytał nasz poradnik o Gicie dla programistów, wie, jak szeroko to narzędzie jest używane w codziennej pracy.
Jak dochodzi do uruchomienia kodu podczas klonu rekurencyjnego?
Błąd jest oznaczony jako CVE-2026-111760. To obcięcie liczby całkowitej w obsłudze indeksu. Bardzo długa ścieżka przechodzi kontrolę Gita, ale potem zapisywana jest na dysku pod krótszą nazwą, którą atakujący może zamienić w .git.
W ten sposób plik .git submodułu zostaje zastąpiony dowiązaniem symbolicznym do katalogu z wrogimi hookami lub konfiguracją. Jak wyjaśnia The Hacker News, Git odmawia zastąpienia katalogu .git dowiązaniem symbolicznym, ale w świeżo sklonowanym submodule .git jest plikiem. Gdy Git użyje tego katalogu, kod atakującego może ruszyć.
Poprawka odrzuca zbyt długie ścieżki, zanim ich długość zostanie obcięta.
Jakie są pozostałe pięć luk?
- CVE-2026-113408. Klonując puste repozytorium protokołem v2, złośliwy serwer może podać nazwę z path traversal. Przy backendzie referencji opartym na plikach późniejsza aktualizacja może zapisać dane poza przewidzianym katalogiem.
- CVE-2026-114467. Tag z więcej niż dwoma podpisami GPG, scalany przez merge, uszkadza stos i może spowodować zawieszenie usługi.
- CVE-2026-114469. Mała binarna łata, która znacznie się rozwija, omija limit około 1 GiB i powoduje awarię Gita.
- CVE-2026-105437. Bardzo duże scalanie z wieloma konfliktami i wysoką wartością atrybutu conflict-marker-size uszkadza pamięć sterty.
- CVE-2026-114466. Trzy funkcje fast-import mogą odczytywać dowolne pliki albo je tworzyć i dopisywać do nich dane.
W ostatnim przypadku Git odrzuca teraz te funkcje w strumieniach wejściowych, chyba że użyjesz opcji --allow-unsafe-features, którą warto włączać tylko wtedy, gdy ufasz programowi generującemu strumień.
Kto jest najbardziej narażony i co już zaktualizował GitHub?
Najbardziej narażone są serwery, które scalają dane w imieniu użytkowników. GitLab, który przypisał CVE-2026-105437, wskazuje git merge-tree jako prawdopodobny cel, bo serwer może go użyć do sprawdzenia, czy merge request da się scalić. Atrybut ustawia się w pliku .gitattributes repozytorium, więc każdy, kto może otworzyć żądanie, potencjalnie uruchomi błąd.
GitHub deklaruje, że poprawił github.com i GitHub Enterprise Cloud. Dla Enterprise Server potrzebne są wersje 3.19.15, 3.20.11, 3.21.9 lub 3.22.4. GitHub Desktop, aplikacja Copilot, Codespaces i Actions otrzymają poprawionego Gita.
Ograniczenia, które warto znać
Źródła nie podają aktywnych exploitów ani poziomu dotkliwości dla każdego CVE. Nie wiemy, czy ktoś już wykorzystał te błędy. Według The Hacker News we wtorek o 19:09 UTC Git for Windows nie miał jeszcze wersji opartej na 2.56.1, więc terminy dla tej platformy mogą się zmienić. Brak też dat dla GitHub Desktop, Copilota, Codespaces i Actions.
Co się zmienia dla osób pracujących z technologią cyfrową
Pierwszym krokiem jest sprawdzenie, gdzie działa Git. Nie tylko na twoim komputerze, ale także w programach, które zawierają jego kopię, w systemach ciągłej integracji i w usługach przetwarzających cudze repozytoria. Kto prowadzi serwery z repozytoriami osób trzecich, musi zaktualizować również automatyzacje. Jeśli nie możesz tego zrobić od razu, obejściem podanym przez GitLab jest dodanie conflict-marker-size=7 do pliku info/attributes każdego repozytorium albo wyłączenie tych kontroli dla niezaufanych repozytoriów. Kto korzysta z hostingu z zarządzanymi aktualizacjami bezpieczeństwa, przerzuca część tej pracy na dostawcę.
Nasza opinia
Luk jest sześć, ale przekaz jest jeden. Git trzeba traktować jak oprogramowanie przetwarzające niezaufane dane, a nie jak zwykłe lokalne narzędzie. Klonujemy, scalamy i nakładamy łaty z zewnętrznych źródeł bez zastanowienia, a automatyzacje robią to za nas. Najbardziej konkretne ryzyko tkwi w kopiach Gita ukrytych w innych programach, których nikt nie aktualizuje, dopóki sobie o nich nie przypomni. Zalecenia GitHuba są dobrym rozwiązaniem tymczasowym, ale tylko tymczasowym. Skoro mowa o narzędziach intensywnie korzystających z Gita, pisaliśmy o GitHub Rubicon, gdzie temat niezaufanych danych waży jeszcze bardziej.
Często zadawane pytania
Jaką wersję Gita mam zainstalować?
Zainstaluj 2.56.1 albo poprawną wersję swojej serii, czyli 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 lub 2.50.2. Zaktualizuj też aplikacje, które zawierają własną kopię Gita.
Wystarczy nie klonować nieznanych repozytoriów?
To pomaga, ale nie wystarcza. GitHub zaleca klonowanie wyłącznie z zaufanych serwerów, unikanie klonów rekurencyjnych oraz scalania i binarnych łat z niezaufanych źródeł, zaznaczając, że te środki nie zastępują aktualizacji.
Która luka jest najpoważniejsza?
Źródła nie podają rankingu. Luka pozwalająca uruchomić kod podczas klonowania rekurencyjnego to CVE-2026-111760 i na niej skupia się większość relacji.
Czy Git for Windows jest już zaktualizowany?
Jeszcze nie, według ostatniego sprawdzenia The Hacker News. We wtorek o 19:09 UTC wśród tagów wydań nie było wersji opartej na 2.56.1.
Czy użytkownicy GitHuba muszą coś zrobić?
To zależy. GitHub już poprawił github.com i wersje Enterprise Cloud. Użytkownicy Enterprise Server muszą przejść na jedną z podanych wersji, a osoby korzystające z lokalnych narzędzi powinny zaktualizować Git.
Aktualizacje Gita, które warto śledzić w najbliższych dniach
Poprawka istnieje, ale jej dystrybucja jest rozproszona. Warto obserwować tych, którzy jeszcze nie wydali swojej wersji.
- Sprawdzaj, kiedy Git for Windows opublikuje build oparty na 2.56.1, i zaktualizuj od razu.
- Śledź, kiedy pojawią się poprawione wersje GitHub Desktop, aplikacji Copilot, Codespaces i Actions.
- Jeśli prowadzisz serwer code hostingu, rozważ obejście GitLaba, dopóki nie będziesz mógł zaktualizować.
