CVE-2026-44244

GitPython to biblioteka Pythona służąca do interakcji z repozytoriami Git. Przed wersją 3.1.48 istniała podatność, która pozwalała atakującym na manipulację plikami poza katalogiem .git repozytorium poprzez niewystarczającą walidację ścieżek odniesienia.

GitPython to biblioteka Pythona służąca do interakcji z repozytoriami Git. W wersjach przed 3.1.47 funkcja _clone() nieprawidłowo waliduje opcje multi_options, co pozwala na wykonanie złośliwych hooków podczas klonowania repozytoriów.

GitPython to biblioteka Pythona służąca do interakcji z repozytoriami Git. W wersjach od 3.1.30 do przed 3.1.47, biblioteka blokuje niebezpieczne opcje Git, ale odpowiednie argumenty Pythona mogą je ominąć, co prowadzi do wykonania dowolnych poleceń.

GitPython przed wersją 3.1.59 niebezpiecznie przetwarza wieloliniowe wartości konfiguracji git podczas zapisu, co może przekształcić uśpione wartości w aktywne dyrektywy, takie jak core.hooksPath. Atakujący może spreparować plik konfiguracyjny z osadzonymi nowymi liniami, co po zapisie przez GitPython umożliwia wykonanie dowolnego kodu.

GitPython 3.1.50 nie rozpoznaje połączonych krótkich form opcji, takich jak -u<value> (krótka forma --upload-pack=<value>), podczas egzekwowania domyślnej bramy niebezpiecznych opcji. Gdy aplikacja przekazuje opcje klonowania pod wpływem atakującego do Repo.clone_from(..., multi_options=..., allow_unsafe_options=False), atakujący może dostarczyć -u<helper>, aby ominąć bramę blokującą --upload-pack/-u, powodując wykonanie przez Git określonego polecenia pomocniczego podczas klonowania. Naprawione w wersji 3.1.51.

GitPython w wersjach przed 3.1.32 nie blokuje niebezpiecznych opcji w clone i clone_from. Problem ten występuje z powodu niekompletnej poprawki dla CVE-2022-24439.

GitPython przed wersją 3.1.62 nie waliduje pola path odczytywanego z niezaufanego pliku .gitmodules podczas aktualizacji submodułów. Podczas gdy wcześniejsza poprawka (GHSA-hmq2-w58f-27jc) dodała Submodule._validated_name() ograniczające pole name, a wewnętrzny mechanizm ochrony Submodule._to_relative_path() jest stosowany w add() i move(), metoda Submodule.update() wyznacza bezwzględną lokalizację checkout z surowej wartości path bez tej ochrony. Wpis .gitmodules zawierający komponenty przejścia katalogowego (np. path = ../../../tmp/escaped) może spowodować tworzenie katalogów przez os.makedirs() poza drzewem roboczym repozytorium, wypełnienie ich z URL submodułu oraz usunięcie przez shutil.rmtree() przy użyciu force_remove. Luka naprawiona w GitPython 3.1.62.

GitPython przed wersją 3.1.60 zawiera podatność na odmowę usługi przez wyrażenie regularne w Actor.name_email_regex, które przetwarza pola autora i commitera commitów. Atakujący mogą stworzyć obiekt commita z nieprawidłowym polem autora zawierającym niezamknięty nawias ostry, co powoduje kwadratowe cofanie się i wyczerpanie zasobów CPU na ponad dwie minuty na każdy dostęp do commita.

GitPython 3.1.59 nie ogranicza opcji --no-index w wysokopoziomowym API diff, co pozwala atakującym czytać dowolne ścieżki systemu plików jako operandy repozytorium. Atakujący mogą połączyć --no-index z -I/--ignore-matching-lines, aby stworzyć zależny od treści wyrocznię boolowską, wielokrotnie odpytywać lokalne pliki i odzyskiwać jednoliniowe sekrety poprzez rozróżnialne odpowiedzi sukcesu lub błędu.

GitPython przed wersją 3.1.60 nieprawidłowo waliduje lokalizację katalogu git, co pozwala atakującym na podszywanie się pod katalog git przy użyciu śledzonych plików, takich jak gitdir, commondir i HEAD. Atakujący mogą wykonać dowolny kod, umieszczając złośliwy hak pre-commit w śledzonym katalogu hooks, który wykonuje się, gdy ofiara wywołuje index.commit() na sklonowanym lub otwartym repozytorium.