CVE-2025-24890
ŚrednieCVSS 6.8Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 5 - wyżej niż 5% wszystkich znanych CVE
Streszczenie
gitoxide to implementacja gita napisana w Rust. Przed wersją 0.13.3, crate gix-sec na Windowsie błędnie traktuje repozytoria kontrolowane przez innego użytkownika jako zaufane, gdy administrator uruchamia zależny program z nieprzefiltrowanym tokenem podniesionym. W gix-sec/src/identity.rs, gix_sec::identity::is_path_owned_by_current_user uzyskuje folder_owner i token_owner, ale jego specyficzne dla administratora sprawdzenia IsWellKnownSid i CheckTokenMembership badają bieżący token, a nie potwierdzają właściciela katalogu. To omija ochronę safe.directory dla repozytoriów należących i skonfigurowanych przez ograniczonego użytkownika, pozwalając konfiguracji repozytorium lub hakom na wykonanie poleceń z uprawnieniami administratora, gdy wykonywana jest dotknięta operacja. Eksploatacja wymaga systemu Windows, podniesionego administratora, programu polegającego na wynikach zaufania gix-sec oraz interakcji z repozytorium kontrolowanym przez innego użytkownika. Niepodniesiony proces UAC nie jest dotknięty, a klonowanie nie jest dotknięte, ponieważ konfiguracja repozytorium i haki nie są kopiowane. Problem naprawiono w wersji 0.13.3.
Ocena ryzyka
Administrator może nieświadomie wykonać złośliwe polecenia z repozytorium kontrolowanego przez innego użytkownika, co może prowadzić do przejęcia systemu lub naruszenia bezpieczeństwa.
Rekomendacja
Zaktualizuj gitoxide do wersji 0.13.3 lub nowszej.
Inne podatności w gitoxide
Zobacz wszystkie- CVE-2026-44471Wysokie
W wersjach przed 0.21.1 gitoxide, implementacja gita napisana w Rust, pozwala na stworzenie złośliwego drzewa, które umożliwia zapisanie symlinków kontrolowanych przez atakującego w dowolnym katalogu, do którego użytkownik ma dostęp do zapisu.
- CVE-2026-82255Średnie
gitoxide w wersjach od 0.25.4 zawiera podatność na wyciek poświadczeń HTTP w backendzie transportowym opartym na curl, gdzie poświadczenia są wysyłane do serwerów kontrolowanych przez atakującego po przekierowaniach HTTP. Podatność występuje, ponieważ walidacja poświadczeń sprawdza oryginalny URL zamiast efektywnego URL po przekierowaniu, co pozwala atakującym na kradzież tokenów uwierzytelniających przez przekierowania między domenami lub degradację HTTPS do HTTP.
- CVE-2026-82254Wysokie
gitoxide przed wersją 0.69.0 zawiera niesprawdzane indeksowanie tablicy podczas aplikowania delt oraz nieograniczoną alokację pamięci na podstawie rozmiarów kontrolowanych przez atakującego w nagłówkach w gix-pack. Atakujący mogą wysłać spreparowane dane pakietu podczas klonowania lub pobierania, aby wywołać panikę lub zabicie procesu z powodu braku pamięci.
- CVE-2026-82253Wysokie
gitoxide (crates Rusta gix <= 0.72.0 i gix-validate <= 0.10.0) zawiera podatność na przechodzenie po ścieżkach. Funkcja walidacji nazw podmodułów w gix-validate sprawdza tylko pierwsze wystąpienie '..' przez name.find(b".."), co pozwala na obejście walidacji przez spreparowane nazwy takie jak 'a..b/../../../.git/'. Dodatkowo ta walidacja nie jest wywoływana w ścieżkach produkcyjnych. W połączeniu z wadą dziedziczenia zaufania w Submodule::open(), gdzie git_dir_trust (Trust::Full) repozytorium nadrzędnego jest klonowane i pomijana jest weryfikacja własności, atakujący może stworzyć złośliwy plik .gitmodules, aby narzędzie ofiary zbudowane na gitoxide czytało dowolną konfigurację repozytorium git (w tym osadzone poświadczenia) z pełnym zaufaniem, omijając ochronę safe-directory. Naprawione w gix 0.82.0 i gix-validate 0.11.1.
- CVE-2026-82252Wysokie
gitoxide przed wersją 0.52.1 podąża za dowiązaniami symbolicznymi podczas odczytu pliku .gitmodules w katalogu roboczym, co pozwala atakującym na wstrzyknięcie bajtów spoza repozytorium do metadanych podmodułów. Atakujący mogą stworzyć złośliwe repozytorium z dowiązaniem symbolicznym .gitmodules wskazującym poza drzewo repozytorium, powodując, że gitoxide parsuje dowolne zewnętrzne pliki jako konfigurację podmodułów i ujawnia kontrolowane przez atakującego wartości name, path i url.
- CVE-2026-82251Wysokie
gitoxide przed wersją 0.52.1 nie waliduje nazw podmodułów z konfiguracji .gitmodules, co pozwala na przechodzenie po ścieżkach podczas wyznaczania katalogów git podmodułów. Atakujący mogą stworzyć złośliwe nazwy podmodułów z segmentami przechodzenia, aby przekierować funkcje state() i open() do repozytoriów poza .git/modules, powodując zamieszanie repozytoriów i inspekcję repozytoriów kontrolowanych przez atakującego.
- CVE-2026-82249Niskie
W gitoxide przed wersją 0.38.2 nie są poprawnie walidowane znaki powrotu karetki w wartościach URL przekazywanych do pomocników poświadczeń. Atakujący mogą dostarczyć URL zawierające gołe powroty karetki, aby wstrzyknąć dodatkowe pola protokołu pomocnika i spowodować, że pomocnicy zwrócą poświadczenia dla hostów wskazanych przez atakującego zamiast żądanego URL.
- CVE-2026-82248Średnie
Podatność w gix-worktree-state przed wersją 0.33.0 (część gitoxide) umożliwia zapisywanie plików poza katalogiem roboczym w systemie Windows. Funkcja checkout() podąża za istniejącym terminalnym dowiązaniem symbolicznym podczas przyrostowej materializacji, co pozwala nadpisać pliki poza katalogiem roboczym.
- CVE-2026-82247Wysokie
Crate gix-url w gitoxide (<= 0.32.0, naprawione w 0.37.1) używa ręcznie napisanego parsera URL, który nie traktuje '?' ani '#' jako końca komponentu authority, wbrew RFC 3986. W konsekwencji mechanizm ochrony tożsamości przekierowań HTTP w gix-transport (can_reuse_identity) porównuje niewłaściwy host i zawodzi w trybie otwartym. Atakujący kontrolujący odpowiedź przekierowania może stworzyć nagłówek Location w postaci <authority-atakującego>?@<oryginalne-authority>, aby gitoxide wysłał poświadczenia HTTP Basic Authorization wywołującego do niezamierzonego hosta. gix-transport jest dotknięty w wersjach <= 0.49.0 (naprawione w 0.58.1).
Oryginalny opis (angielski, źródło NVD)
gitoxide is an implementation of git written in Rust. Prior to 0.13.3, the gix-sec crate on Windows incorrectly treats repositories controlled by another user as trusted when an administrator runs a dependent program with an unfiltered elevated token. In gix-sec/src/identity.rs, gix_sec::identity::is_path_owned_by_current_user obtains folder_owner and token_owner, but its administrator-specific IsWellKnownSid and CheckTokenMembership checks examine the running token rather than confirming the directory owner. This bypasses safe.directory-style protection for repositories owned and configured by a limited user, allowing repository configuration or hooks to execute commands with the administrator's privileges when an affected operation is performed. Exploitation requires Windows, an elevated administrator, a program that relies on gix-sec trust results, and interaction with a repository controlled by another user. An unelevated UAC process is not affected, and cloning is not affected because repository configuration and hooks are not copied. This issue is fixed in version 0.13.3.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS