GitPython 3.1.54: trzy luki w opcjach Git prowadzą do RCE i nadpisania plików

13 sierpnia 2026 roku opublikowano trzy rekordy CVE dotyczące GitPython: CVE-2026-73623, CVE-2026-73624 i CVE-2026-73625. Wszystkie wersje do 3.1.53 włącznie są podatne, a GitPython 3.1.54 zawiera poprawki. Dwa błędy mogą prowadzić do wykonania poleceń systemowych, trzeci pozwala nadpisać plik dostępny dla procesu. Wspólną przyczyną nie jest błąd kryptograficzny ani parser repozytorium, lecz niepełne rozdzielenie wartości aplikacyjnych od opcji programu git.

To ważne dla systemów CI/CD, botów repozytoryjnych, platform analizujących kod, usług tworzących podglądy oraz agentów AI korzystających z bibliotek Git. Jeżeli aplikacja przekazuje do GitPython wartości kontrolowane przez użytkownika jako kwargs, ref, opcję clone albo parametr diff, potencjalnie niebezpieczny tekst może stać się flagą dla procesu Git. Domyślne allow_unsafe_options=False miało temu zapobiegać, ale trzy niezależne ścieżki pokazały ograniczenia denylisty i rekonstrukcji argumentów.

CVE-2026-73623: template uruchamia hook po clone

Advisory GHSA-6p8h-3wgx-97gf opisuje brak opcji --template na liście unsafe_git_clone_options. Git potrafi utworzyć nowe repozytorium na podstawie katalogu szablonu. Taki katalog może zawierać hooki, a post-checkout jest uruchamiany podczas klonowania. Jeśli atakujący kontroluje opcję template oraz może wskazać dostępny dla procesu katalog z przygotowanym hookiem, osiąga wykonanie kodu.

Ta luka ma 7,5 w CVSS 3.1 i wyższą złożoność, ponieważ wymaga drugiego warunku: przygotowanego, czytelnego katalogu z wykonywalnym hookiem. Może nim być współdzielony filesystem, katalog uploadu, przestrzeń tymczasowa albo zasób sieciowy. Sam URL złośliwego repozytorium nie zawsze wystarczy. Nie należy jednak zakładać, że brak lokalnego konta eliminuje warunek — aplikacje webowe często pozwalają zapisać plik w innym kroku workflow.

Poprawka dodaje --template do kontroli i testuje bezpośrednią oraz skróconą formę parametru. Długoterminową lekcją jest to, że bezpieczeństwo nie powinno zależeć od ręcznej listy kilku „znanych złych” opcji programu, którego semantyka jest szersza. Jeżeli aplikacja nie potrzebuje arbitralnych opcji clone, powinna udostępniać własny wąski model parametrów zamiast przekazywać słownik do Git.

CVE-2026-73624: diff zapisuje wynik w dowolnej ścieżce

GHSA-fjr4-x663-mwxc dotyczy Diffable.diff(), używanego przez Commit, Tree, IndexFile i Submodule. Metoda przekazywała kwargs bez kontroli niebezpiecznych opcji. Git obsługuje --output=<path>, więc napastnik wpływający na nazwę opcji mógł wskazać plik do otwarcia i nadpisania zawartością diffu.

Druga ścieżka była jeszcze mniej oczywista. Parametr other, traktowany przez aplikację jako ref, trafiał do argumentów przed separatorem --. Wartość wyglądająca jak opcja mogła zostać zinterpretowana przez Git jako --output, nawet bez kontroli nazwy kwarg. CVSS wynosi 8,1: napastnik wybiera ścieżkę, a proces może uszkodzić konfigurację, plik autoryzacji, lockfile lub element uruchamiany później.

Nie jest to dowolny zapis idealnie wybranych bajtów; treścią są dane diffu. Nadal może dojść do naruszenia integralności i dostępności, a w określonym kontekście do stworzenia dalszego łańcucha. Poprawka dodaje kontrolę opcji przed parsowaniem rewizji i wywołaniem Git oraz obejmuje testami diff commita i indeksu.

CVE-2026-73625: bezpieczny klucz, niebezpieczna wartość

Najwyżej oceniony z trzech błędów, GHSA-r9mr-m37c-5fr3, ma wynik 8,8. Kontrola check_unsafe_options tworzyła kandydatów na podstawie nazw kluczy. Dla jednoliterowego kwarg, na przykład n, widziała tylko krótką opcję -n. Późniejsza transformacja rozdzielała klucz i jego wartość na dwa argumenty. Jeśli wartość zaczynała się od niebezpiecznej długiej flagi, Git interpretował drugi token niezależnie.

W efekcie możliwe było przemycenie --upload-pack, które wpływa na program uruchamiany przez Git podczas operacji zdalnej. Błąd obejmował wiele metod: clone, fetch, pull, push, ls_remote, iter_commits, blame i archive. Bezpośrednia nazwa opcji była blokowana, ale ten sam skutek przechodził przez wartość pozornie bezpiecznej flagi.

Poprawka buduje kontrolę z rzeczywiście transformowanych tokenów, w tym wartości zaczynających się od myślnika. To wzorzec ważny dla każdej biblioteki wrapperującej CLI: walidacja musi oceniać ostateczne argv, które otrzyma proces, a nie wcześniejszą strukturę obiektu. Bezpieczny klucz nie czyni bezpieczną wartości, jeśli późniejsza warstwa zmienia granice argumentów.

Kto jest faktycznie narażony

Sama obecność GitPython w obrazie nie oznacza zdalnego RCE. Trzeba ustalić osiągalność: czy użytkownik kontroluje opcje, refy, konfigurację klonowania lub obiekt przekazywany do diff; czy proces wykonuje operację na takim wejściu; oraz jakie ma uprawnienia. Platforma przyjmująca tylko zatwierdzony URL i stały katalog z kodu ma mniejsze ryzyko niż system „Git-as-a-service”, który mapuje pola API na **kwargs.

Szczególnie uważnie trzeba przejrzeć agentów AI. Model może generować branch, ref albo opcje dla narzędzia Git na podstawie nieufnego issue. Typowany schema narzędzia nie jest wystarczający, jeśli dopuszcza dowolny słownik argumentów. Prompt injection nie wywołuje CVE samodzielnie, ale może dostarczyć wartość do podatnego sinka bez świadomego działania człowieka.

W CI runner zwykle ma token repozytorium, klucze do rejestru, możliwość zapisu artefaktu i czasem credentiale chmurowe. Wykonanie kodu w procesie analizującym pull request może zatem zmienić wynik buildu albo wykraść sekret. Self-hosted runner o trwałym filesystemie zwiększa ryzyko utrzymania dostępu między jobami.

Co zrobić teraz

1. Znajdź GitPython w aplikacjach, obrazach, notebookach i narzędziach wewnętrznych; potwierdź efektywną wersję przez środowisko wykonawcze.
2. Zaktualizuj do 3.1.54 lub nowszego i przebuduj obrazy bez cache zawierającego 3.1.53.
3. Wyszukaj wywołania clone_from, operacji remote, iter_commits, blame, archive i diff, szczególnie z **kwargs lub refem pochodzącym z zewnątrz.
4. Usuń publiczną możliwość przesyłania arbitralnych opcji. Mapuj do zatwierdzonych parametrów i odrzucaj wartości zaczynające się od -, gdy pole ma być nazwą refa.
5. Uruchamiaj operacje Git w efemerycznym workerze, bez sekretów i z minimalnym zapisem; blokuj hooki oraz niepotrzebny egress warstwą systemową.
6. Przejrzyj logi procesów, modyfikacje plików i aktywność tokenów z okresu podatności, jeżeli zewnętrzne dane dochodziły do wskazanych metod.
7. Dodaj testy regresji udowadniające, że zakazana zdolność jest blokowana w nazwie, wartości i refie po transformacji argumentów.

Aktualizacja zależności musi dotrzeć do wszystkich środowisk. W Pythonie lockfile może wskazywać nową wersję, lecz stary wheel pozostać w warstwie obrazu lub wirtualnym środowisku długowiecznego workera. Dowodem jest wynik odczytany w uruchomionym procesie oraz digest przebudowanego obrazu.

Detekcja i bezpieczniejszy projekt

W telemetrii warto szukać procesów potomnych wywołanych przez git, nietypowych argumentów takich jak template, upload-pack i output, hooków pojawiających się w świeżo sklonowanych repozytoriach oraz zapisów poza katalogiem roboczym. Nie zapisuj całych URL z poświadczeniami do logu. Lepiej rejestrować metodę, zatwierdzony host, skrócone argv po redakcji i identyfikator joba.

Najsilniejsza granica to osobny proces lub kontener z read-only root filesystem, pustym katalogiem domowym i pojedynczym wolumenem roboczym. Repozytorium powinno być traktowane jak nieufny artefakt. Jeśli Git uruchomi hook albo zapisze plik poza workspace, kontrola systemowa powinna zatrzymać skutek nawet przy kolejnym błędzie walidacji.

Nie należy budować własnej rosnącej denylisty wszystkich flag Git w kontrolerze webowym. Zdefiniuj allowlistę funkcji biznesowych: konkretny URL, zatwierdzony ref, depth w małym zakresie i docelowy katalog utworzony przez serwer. Wszystko inne powinno wymagać osobnej ścieżki administracyjnej.

Fakty o trzech ścieżkach, ocenach i wersji 3.1.54 pochodzą z advisory GitPython oraz zmian wydania. Nie ma w tych źródłach potwierdzenia masowej kampanii. Ocena ryzyka CI, izolacja i hunting są rekomendacjami Breachroad. Przypadek dobrze pokazuje granicę między danymi a argumentami podczas szkoleń cyberbezpieczeństwa dla organizacji. Pipeline’y i narzędzia obsługujące repozytoria można dodatkowo zweryfikować przez audyt bezpieczeństwa chmury i DevSecOps.