Podatności GitPython

GitPython to biblioteka Pythona służąca do interakcji z repozytoriami Git. W wersjach przed 3.1.49 metoda GitConfigParser.set_value() nie weryfikowała wartości pod kątem nowych linii, co pozwalało na wstrzykiwanie złośliwych ścieżek do konfiguracji Git.

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ń.

W bibliotece GitPython metoda Remote.pull() przekazuje pozycyjny argument refspec bezpośrednio do procesu potomnego git pull, podczas gdy zabezpieczenie przed niebezpiecznymi opcjami sprawdza tylko argumenty nazwane. Aplikacja przekazująca dane kontrolowane przez atakującego jako refspec (np. nazwę gałęzi podaną przez użytkownika) może umożliwić wstrzyknięcie niebezpiecznych opcji.

To pozostałość po GHSA-g5vv-9gxw-82hx / CVE-2026-87819. Poprawka w wersji 3.1.60 uczyniła Actor._from_string wolnym od wyrażeń regularnych, ale parse_actor_and_date nadal uruchamia _re_actor_epoch na tej samej linii autora/zatwierdzającego/taggera o krok wcześniej. Wzorzec ten wykazuje kwadratowe cofanie przy końcowym epo...

Obsługa separate_git_dir w Repo._clone() w GitPython nigdy nie wyłącza rozwijania zmiennych środowiskowych w Git.polish_url(), w przeciwieństwie do innych wywołań tego helpera obsługujących dane pochodzące od atakującego. separate_git_dir może pochodzić z kontrolowanego przez atakującego pliku .gitmodules submodułu.

GitPython w wersji 3.1.61 (oraz gałąź main) ma lukę w git/objects/submodule/base.py — poprawka dla GHSA-hmq2-w58f-27jc dodała Submodule._validated_name(), ale opis nie precyzuje pełnego zakresu problemu. Kod w tym obszarze jest identyczny w 3.1.61 i main.

Walidator nazw konfiguracji w GitPython neutralizuje tylko znaki CR/LF/NUL dla etykiety "option"; nie odrzuca znaków =, #, ;, [, ] ani białych znaków w nazwie opcji. Funkcja write_section zapisuje nazwę opcji dosłownie do pliku konfiguracyjnego, więc nazwa taka jak sshCommand = touch <cmd> może wstrzyknąć konfigurację.

Publiczne API GitPython Submodule.move() weryfikuje, że cel znajduje się leksykalnie wewnątrz repozytorium nadrzędnego, ale nie odrzuca dowiązań symbolicznych w pośrednich komponentach ścieżki docelowej przed operacjami na systemie plików. W systemach, które pobierają symlinki Git, niezaufane repozytorium może to wykorzystać.

GitPython od 2022 do 2026 roku wdrażał metodycznie dwa zabezpieczenia: Git.check_unsafe_protocols(url) (zgłasza UnsafeProtocolError dla URL-i typu <transport>::) oraz Git.check_unsafe_options(...) (zgłasza UnsafeOptionError dla opcji z listy zabronionych). Opis wskazuje, że wdrożenie tych zabezpieczeń nie objęło wszystkich ścieżek kodu.

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 to biblioteka Pythona do interakcji z repozytoriami Git. Przed wersją 3.2.1 funkcja create_submodule() w git/objects/submodule/base.py akceptuje ścieżkę podmodułu kontrolowaną przez atakującego, taką jak .git/hooks, i wywołuje _clone_repo() przed bezpiecznym odrzuceniem celu. W wersji 3.1.x _validate_repo_path() nie istnieje i wywołanie kończy się po cichu, a w 3.2.0 i późniejszych sprawdzenie w git/index/base.py zgłasza ValueError dopiero po zapisaniu klonu na dysk i nie usuwa umieszczonego pliku. Atakujący może umieścić wykonywalny hook post-checkout, który zostanie uruchomiony przez późniejszą operację Git.

GitPython od wersji 3.1.62 do 3.2.0 zawiera błąd podążania za dowiązaniami symbolicznymi w Submodule.move(), który sprawdza cel tylko leksykalnie i nie odrzuca dowiązań symbolicznych w pośrednich komponentach ścieżki. Niezaufane repozytorium może zatwierdzić dowiązanie symboliczne wskazujące poza drzewo robocze, przez co aplikacja przenosząca zainicjowany podmoduł pod nim przenosi checkout na zewnątrz i uszkadza indeks oraz .gitmodules.

GitPython przed wersją 3.2.0 zawiera podatność wstrzyknięcia argumentów w metodzie Head.checkout() pozwalającą zdalnym atakującym odczytać dowolne pliki poprzez podanie nazwy gałęzi interpretowanej jako opcja git. Atakujący może hostować repozytorium, którego domyślna gałąź nazywa się --pathspec-from-file=<path>, powodując wyciek zawartości plików przez komunikaty GitCommandError w aplikacjach klonujących i przełączających się na aktywną gałąź.

GitPython w wersjach od 3.1.30 do 3.2.0 zawiera podatność zdalnego wykonania kodu w metodzie Remote.pull(), której zabezpieczenie przed niebezpiecznymi opcjami sprawdza tylko argumenty nazwane, a nie pozycyjny refspec. Atakujący kontrolujący refspec może podać --upload-pack=<command>, aby wykonać polecenia systemowe jako proces wywołujący przez transport lokalny lub SSH.

GitPython w wersjach przed 3.2.0 zawiera podatność umożliwiającą zdalne wykonanie kodu, ponieważ Git.ls_remote przekazuje adresy URL bez walidacji check_unsafe_protocols. Atakujący mogą podać adresy URL typu ext:: remote-helper, aby wykonać polecenia, gdy git zezwala na transport ext; podobny problem dotyczy merge_base i IndexFile.move, które akceptują wstrzyknięcie opcji.

GitPython w wersjach przed 3.2.0 zawiera podatność typu regular expression denial of service we wzorcu _re_actor_epoch używanym przez parse_actor_and_date dla linii author, committer i tagger. Atakujący może udostępnić repozytorium z obiektami commit lub tag zawierającymi długie linie wypełnione spacjami bez prawidłowej epoki lub strefy czasowej, powodując kwadratowe cofanie i wyczerpanie CPU.

GitPython przed wersją 3.2.0 zawiera podatność ujawnienia informacji, która pozwala złośliwym repozytoriom na rozwijanie zmiennych środowiskowych przez separate_git_dir w Repo._clone(), gdzie pominięto expand_vars=False przy wywołaniu Git.polish_url(). Atakujący mogą utworzyć nazwę podmodułu w .gitmodules zawierającą składnię zmiennych, tak że clone i submodule_update ujawniają sekrety w nazwach katalogów .git/modules i logach DEBUG.

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.

GitPython przed wersją 3.1.59 zawiera podatność na odczyt dowolnych plików w metodzie TagReference.create(), gdzie parametr referencji może ominąć zabezpieczenie unsafe. Atakujący może podać wartość referencji taką jak --file=<ścieżka>, aby odczytać dowolne pliki, a ich zawartość jest zwracana w wiadomości tagu.

GitPython przed wersją 3.1.59 zawiera niekompletną listę zabronionych opcji w zabezpieczeniu unsafe_git_revision_options, która pomija opcje --contents i -S. Atakujący może przekazać wartości rewizji takie jak --contents=/etc/passwd, aby odczytać zawartość dowolnych plików poprzez wynik funkcji Repo.blame().

GitPython przed wersją 3.1.59 pomija opcję --separate-git-dir w unsafe_git_clone_options, co pozwala atakującym na tworzenie dowolnych katalogów git poza zamierzonym miejscem klonowania. Atakujący mogą przekazać parametr separate_git_dir do Repo.clone_from() lub Repo.clone(), aby przekierować metadane repozytorium do ścieżki kontrolowanej przez atakującego, umożliwiając tworzenie dowolnych katalogów i potencjalne wykonanie hooków.

GitPython przed wersją 3.1.59 nie wyłącza opcji merge_includes podczas parsowania pliku .gitmodules, co pozwala atakującym na ujawnienie zawartości lokalnych plików przez dołączanie dowolnych ścieżek plików za pomocą dyrektyw [include]. Atakujący mogą stworzyć złośliwy plik .gitmodules z dyrektywami include wskazującymi na wrażliwe pliki; gdy dostęp do repo.submodules jest wykonywany, GitConfigParser zgłasza wyjątek MissingSectionHeaderError zawierający pierwszą linię docelowego pliku w treści komunikatu.

GitPython przed wersją 3.1.58 nie waliduje nazw podmodułów z plików .gitmodules, co pozwala atakującym tworzyć repozytoria Git w dowolnych ścieżkach systemu plików poza zamierzonym katalogiem klonowania. Atakujący mogą stworzyć złośliwe repozytoria z sekwencjami przejść w nazwach podmodułów, które GitPython przetwarza podczas inicjalizacji podmodułów, tworząc kontrolowane przez atakującego repozytoria Git w uciekających lokalizacjach.

GitPython przed wersją 3.1.58 zawiera podatność wstrzykiwania nazw konfiguracji w walidatorze nazw opcji, która pozwala atakującym na fałszowanie dowolnych dyrektyw git-config poprzez wstrzykiwanie znaków równości, hashy i białych znaków do nazw opcji. Atakujący mogą wstrzyknąć złośliwe nazwy opcji, takie jak 'sshCommand = touch /tmp/RCE #', aby wykonać dowolne polecenia przez core.sshCommand lub core.hooksPath podczas następnej operacji git.

GitPython przed wersją 3.1.58 zawiera podatność wykonania poleceń w zabezpieczeniu check_unsafe_options, które można obejść, łącząc jednoznakowy argument kwargs z split_single_char_options=False. Atakujący mogą dostarczyć spreparowany słownik kwargs do chronionych metod, takich jak clone_from, aby wyemitować połączony token parsowany jako --upload-pack, umożliwiając wykonanie dowolnych poleceń systemu operacyjnego przy domyślnym allow_unsafe_options=False.

GitPython przed wersją 3.1.58 zawiera podatność dowolnego nadpisywania plików w metodach IndexFile.from_tree, IndexFile.reset i IndexFile.merge_tree, które dołączają ciągi treeish kontrolowane przez wywołującego do git read-tree bez walidacji opcji lub separacji argumentów. Atakujący mogą wstrzyknąć opcję --index-output, aby nadpisać dowolne pliki prawidłowym blobem indeksu git, niszcząc istniejącą zawartość plików w ścieżkach zapisywalnych kontrolowanych przez atakującego.

GitPython przed wersją 3.1.58 zawiera podatność zdalnego wykonania kodu w funkcji Repo.init, która przekazuje niebezpieczne opcje git bez walidacji. Atakujący może dostarczyć parametr template wskazujący na katalog ze złośliwymi hakami git, które wykonują dowolny kod podczas operacji git na zainicjalizowanym repozytorium.

GitPython w wersjach przed 3.1.58 nie waliduje opcji przekazywanych do poleceń git rm i git checkout w metodach IndexFile.remove() i Head.checkout(). Atakujący mogą dostarczyć parametry --pathspec-from-file i --pathspec-file-nul, aby odczytać dowolne pliki dostępne dla procesu, a pełna zawartość plików jest zwracana w GitCommandError.stderr.

GitPython przed wersją 3.1.54 zawiera podatność na zdalne wykonanie kodu w zabezpieczeniu check_unsafe_options, które można obejść, przemycając opcje git wewnątrz wartości argumentów o pojedynczym znaku. Atakujący mogą dostarczyć spreparowane słowniki opcji do metod clone_from, fetch, pull, push, ls_remote, iter_commits, blame lub archive, aby wykonać dowolne polecenia systemu operacyjnego za pomocą parametru --upload-pack.

GitPython przed wersją 3.1.54 zawiera podatność na nadpisanie dowolnych plików w metodzie Diffable.diff, która nie waliduje opcji git przekazywanych przez kwargs. Atakujący mogą podać argument --output przez parametr other lub kwarg output, aby zapisać treść patchy do wybranych przez atakującego ścieżek plików z uprawnieniami procesu.

GitPython przed wersją 3.1.54 zawiera niekompletną listę blokowanych opcji w unsafe_git_clone_options, która pomija --template, umożliwiając atakującym wykonanie dowolnych poleceń podczas operacji klonowania. Atakujący mogą podać --template wskazujący na katalog zawierający złośliwe hooki post-checkout, które wykonują się podczas klonowania repozytorium.

GitPython przed wersją 3.1.55 nie wyłącza rozwijania zmiennych środowiskowych w obsłudze URL w metodach Remote.create() i Submodule.add(), co pozwala atakującym na eksfiltrację sekretów poprzez podanie URL zawierających odwołania do zmiennych. Atakujący mogą tworzyć URL z tokenami zmiennych środowiskowych, które są rozwijane do .git/config i .gitmodules, a następnie przesyłane do kontrolowanych przez atakującego hostów podczas operacji fetch lub pull.

GitPython przed wersją 3.1.56 zawiera podatność na wstrzyknięcie argumentów w metodzie Commit.count(), która przekazuje argumenty słownikowe do 'git rev-list' bez zabezpieczenia check_unsafe_options obecnego w pokrewnej metodzie iter_items. Atakujący, który może kontrolować opcje przekazywane do Commit.count (np. przez aplikację przekazującą słownik opcji dostarczony przez użytkownika), może podać output=<path>, powodując, że 'git rev-list --output=<path>' otworzy i skróci docelowy plik do zera bajtów przed parsowaniem rewizji. Umożliwia to zniszczenie/wyzerowanie dowolnego pliku na poziomie uprawnień procesu (bez kontroli zawartości, skrócenie do 0 bajtów).

GitPython przed wersją 3.1.57 nie zabezpiecza przekazywania opcji git w metodach IndexFile.checkout() i TagReference.create(), co pozwala atakującym na przekazanie niebezpiecznych opcji przez kwargs. Atakujący mogą użyć --prefix do nadpisania dowolnych plików zawartością repozytorium lub -F do odczytu dowolnych plików zwracanych w odpowiedzi.

GitPython przed wersją 3.1.57 zawiera niekompletną listę zabronionych opcji w zabezpieczeniu unsafe_git_archive_options, która pomija opcje --add-file i --add-virtual-file. Atakujący mogą podać te opcje do metody Repo.archive(), aby odczytać dowolne pliki z systemu plików i dołączyć je do zwracanego archiwum.

W bibliotece GitPython przed wersją 3.1.53 wykryto podatność polegającą na nieprawidłowym escapowaniu nazw sekcji w plikach konfiguracyjnych gita. Atakujący może wstrzyknąć złośliwe dyrektywy konfiguracyjne (np. core.sshCommand) poprzez nazwy submodułów, co prowadzi do zdalnego wykonania kodu podczas operacji ssh.

GitPython przed wersją 3.1.50 nie waliduje znaków nowej linii w parametrze section funkcji config_writer(), umożliwiając atakującym wstrzyknięcie dowolnych nagłówków sekcji do pliku .git/config. Atakujący mogą wstrzyknąć znaki nowej linii, aby utworzyć sfałszowaną sekcję [core] z hooksPath wskazującym na kontrolowane przez atakującego katalogi, co prowadzi do zdalnego wykonania kodu po uruchomieniu hooków gita.

GitPython przed wersją 3.1.51 zawiera niekompletną blokadę wstrzykiwania komend, która nie uwzględnia funkcji skracania długich opcji gita. Atakujący mogą ominąć zabezpieczenie przed niebezpiecznymi opcjami, używając skróconych nazw opcji, takich jak upload_p zamiast upload_pack, które git rozpoznaje jako niebezpieczne opcje i wykonuje dowolne komendy.

GitPython przed wersją 3.1.51 nie zabezpiecza przed niebezpiecznymi opcjami Git przekazywanymi jako argumenty słownikowe w metodach Repo.archive() i git.ls_remote(), co umożliwia wstrzyknięcie poleceń przez opcje takie jak --exec/--upload-pack. Dodatkowo, Repo.iter_commits() i Repo.blame() nie sprawdzają argumentów rewizji zaczynających się od myślnika, co pozwala na otwarcie i obcięcie dowolnego pliku poprzez rewizję --output=<path>. Wymagana jest aplikacja przekazująca kontrolowane przez atakującego argumenty do tych metod.

GitPython przed wersją 3.1.52 jest podatny na wyciek zmiennych środowiskowych w metodzie Repo.clone_from(). Adres URL zdalnego repozytorium jest przetwarzany przez Git.polish_url(), który na platformach innych niż Cygwin wywołuje os.path.expandvars() na URL-u przed wykonaniem git clone. Atakujący kontrolujący URL klonowania może osadzić tokeny $NAME lub ${NAME}, które są rozwijane do wartości zmiennych środowiskowych procesu (np. AWS_SECRET_ACCESS_KEY lub GITHUB_TOKEN). Powstały URL, zawierający teraz sekret, jest przesyłany przez sieć do hosta kontrolowanego przez atakującego podczas próby klonowania.

GitPython to biblioteka Pythona służąca do interakcji z repozytoriami Git. W wyniku braku weryfikacji lokalizacji plików, GitPython może odczytać dowolny plik z systemu, co stwarza ryzyko ataku.

CVE-2023-40590 dotyczy biblioteki GitPython, która może uruchomić złośliwy program `git` z lokalnego repozytorium, jeśli użytkownik uruchomi GitPython z tego katalogu. Problem ten występuje głównie na systemach Windows, gdzie Python nieprawidłowo rozwiązuje ścieżki do wykonywalnych plików.