Katalog podatności CVE

W Gitea mechanizm obsługi załączników pomija sprawdzanie własności między repozytoriami dla załączników utworzonych przed 16 stycznia 2026 i sprawdza uprawnienia względem repozytorium z adresu URL żądania. Nieuwierzytelniony atakujący znający UUID prywatnego załącznika może pobrać jego zawartość przez ścieżkę publicznego repozytorium.

Gdy w Gitea włączone jest logowanie OpenID, aplikacja przetwarza nieuwierzytelnione parametry asercji i wysyła żądanie HTTP POST do wskazanego przez wywołującego punktu końcowego dostawcy OpenID podczas weryfikacji. Atakujący kontroluje cel i większość treści formularza, co umożliwia interakcję z wewnętrznymi usługami HTTP osiągalnymi z serwera Gitea.

W Gitea punkt końcowy trybu dostępu współpracy akceptuje tryb Owner od uwierzytelnionego współpracownika repozytorium z uprawnieniami Admin. Współpracownik może podnieść swoje uprawnienia z Admin do Owner i wykonywać operacje zastrzeżone dla właściciela, w tym przenieść repozytorium na własne konto.

W Gitea token z zakresem write:user może zarejestrować kontrolowany przez atakującego klucz publiczny SSH na koncie właściciela tokenu. Żądania API podpisane odpowiadającym kluczem prywatnym uwierzytelniają się jako to konto przez HTTP Signature bez informacji o zakresie tokenu API, co pomija sprawdzanie zakresu na poziomie trasy.

W Gitea Runner opcje kontenera kontrolowane przez workflow są przekazywane do konfiguracji kontenera zadań Docker, mimo że tryb uprzywilejowany jest wyłączony. Ustawienia przestrzeni nazw hosta, rozszerzone uprawnienia i nadpisania profilu bezpieczeństwa mogą pozostać aktywne, umożliwiając dostęp do przestrzeni nazw hosta i wykonanie poleceń jako root na hoście runnera.

W Gitea lokalne pliki wielokrotnego użytku workflow są rozwiązywane z commita head forka, gdy zaufany workflow gałęzi bazowej jest uruchamiany dla zdarzenia pull_request_target. Autor forka może zmodyfikować przywoływany workflow wielokrotnego użytku, aby wykonać kontrolowany przez atakującego kod z sekretami repozytorium i organizacji dostępnymi dla tego zdarzenia.

Gitea podstawia adres URL pochodzący z pola Context znaczników do szablonów poleceń zewnętrznego renderera bez escapowania ścieżki referencyjnej przed podziałem argumentów w stylu powłoki. Spreparowany Context może wstrzyknąć dodatkowe argumenty renderera, w tym opcje ładujące wykonywalne pliki filtrów. W środowiskach używających podatnego zewnętrznego renderera, takiego jak pandoc, użytkownik mogący umieścić plik filtra w dostępnej ścieżce może doprowadzić do jego wykonania jako konto usługi Gitea, a publiczny endpoint znaczników repozytorium może być osiągalny bez uwierzytelnienia.

Handler OpenID Connect w Gitea akceptuje hasło użytkownika bez wymuszenia weryfikacji zarejestrowanego TOTP lub WebAuthn przed zakończeniem logowania i powiązaniem identyfikatora OpenID. Gdy logowanie OpenID jest włączone, atakujący znający hasło ofiary może uzyskać sesję i powiązać kontrolowany przez siebie identyfikator. Atakujący może następnie logować się przez ten identyfikator bez hasła ofiary ani drugiego czynnika, a zmiana hasła nie usuwa powiązania.

Gitea w obsłudze przesyłania pakietów Maven wczytuje przesłane sumy kontrolne w całości do pamięci i kończy przetwarzanie przed egzekwowaniem limitów rozmiaru pakietów. Uwierzytelniony użytkownik z uprawnieniem do publikowania pakietów może przesłać zbyt duże ciało żądania do punktu końcowego sumy kontrolnej, omijając limit i wyczerpując pamięć serwera.

Gitea używa niespójnych predykatów widoczności repozytoriów, a warunek stosowany przez niektóre punkty końcowe listowania repozytoriów dopuszcza repozytoria, których właściciele są ukryci przed przeglądającym. Listowania ujawniają metadane repozytoriów, mimo że bezpośrednie trasy poprawnie odmawiają dostępu z odpowiedzią 404.

Gitea nie ogranicza długości pola gitignores przyjmowanego przez formularze tworzenia repozytoriów oraz API. Inicjalizacja repozytorium dzieli to pole na nazwy szablonów, wielokrotnie odczytuje wskazane szablony i buforuje ich zawartość w pamięci. Atakujący mogący tworzyć repozytoria może przesłać zbyt dużą wartość, aby wzmocnić odczyty szablonów i zużycie pamięci, pogarszając dostępność.

Endpoint Gitea odpowiedzialny za odznakę statusu workflow Actions nie egzekwuje zakresu odczytu repozytorium ani ograniczenia wyłącznie do publicznych repozytoriów dla tokenu uwierzytelniającego żądanie. Token bez uprawnienia read:repository lub ograniczony do repozytoriów publicznych może pobrać najnowszy status workflow prywatnego repozytorium dostępnego dla jego właściciela. Ujawnia to prywatny status workflow poza zamierzonymi uprawnieniami delegowanymi tokenu.

Endpoint Gitea do renderowania znaczników repozytorium rozwiązuje odwołania do pull requestów w tym samym repozytorium bez egzekwowania uprawnienia Pull Requests przeglądającego. Członek z dostępem tylko do Wiki w prywatnym repozytorium może wysłać żądanie podglądu znaczników i pobrać tytuł oraz ikonę stanu prywatnego pull requesta, mimo braku dostępu do Issues i Pull Requests. Ujawnia to metadane pull requestów w poprzek uprawnień jednostek repozytorium.

W Gitea, notyfikator przeglądu pull request nie dołącza pull requesta do powiadomienia Actions, przez co bramka zatwierdzania dla forków nie rozpoznaje uruchomienia jako pochodzącego z forka. Zdarzenia komentarzy i zatwierdzeń/odrzuceń przeglądu mogą załadować kod workflow z forka i uruchomić go na runnerach bazowego repozytorium bez wymaganego zatwierdzenia przez opiekuna.

API listy organizacji w Gitea nie egzekwuje zakresu tokenu read:organization. Token ograniczony do innej kategorii, np. read:misc, może pobrać metadane organizacji widoczne dla jego właściciela. W przypadku tokenu administratora serwisu odpowiedź może zawierać organizacje Limited i prywatne, omijając zamierzone ograniczenie delegowanego dostępu tokenu.

Współdzielony helper porównywania w Gitea pomija sprawdzenie dostępu tokenu do repozytorium stosowane przy aktualizacji pull requestów. Token public-only z zakresem read:repository może przeprowadzić porównanie lub utworzenie pull requesta przez publiczne repozytorium bazowe i pobrać historię commitów oraz różnice z prywatnego repozytorium head dostępnego dla właściciela tokenu. Omija to ograniczenie public-only tokenu; nie usuwa to podstawowych sprawdzeń uprawnień repozytorium konta.

Gitea tworzy katalogi i skrypty hooków Git po stronie serwera z uprawnieniami 0777 i polega na umask procesu w celu ograniczenia dostępu. Przy permisywnym umask, takim jak 0000 lub 0002, inny lokalny użytkownik mogący dotrzeć do magazynu repozytorium może zmodyfikować hook lub dodać plik wykonywalny do zapisywalnego katalogu hooków. Późniejsza operacja Git może wykonać ten plik jako konto usługi Gitea.

API migracji repozytoriów w Gitea akceptuje token public-only, gdy żądanie określa utworzenie prywatnego repozytorium. Delegowany token przeznaczony do działania tylko na zasobach publicznych może utworzyć prywatne repozytorium i zadanie migracji na koncie autoryzującym lub w organizacji, w której ten użytkownik ma niezbędne uprawnienia. Zwykła ścieżka tworzenia prywatnego repozytorium odrzuca ten sam token, ale ścieżka migracji pomija to ograniczenie.

API tworzenia repozytoriów organizacji w Gitea wymaga zakresu write:organization, ale pomija zakres tokenu write:repository wymuszany przez inne trasy tworzenia repozytoriów. Token osobistego dostępu lub token aplikacji OAuth bez zakresu zapisu do repozytoriów może zatem tworzyć repozytoria należące do organizacji, jeśli autoryzujący użytkownik ma do tego uprawnienia. Omija to granicę delegowanego zakresu tokenu, pozostając jednocześnie ograniczonym uprawnieniami organizacyjnymi użytkownika.

Endpointy API Gitea do listy kluczy SSH i GPG użytkownika pomijają sprawdzenie widoczności profilu stosowane przez ich odpowiedniki webowe. Konto o ograniczonym dostępie może pobrać klucze publiczne, tytuły kluczy, odciski palców oraz adresy e-mail osadzone w GPG należące do użytkowników o widoczności Limited. Ujawnienie dotyczy materiału kluczy publicznych i powiązanych metadanych, a nie prywatnych kluczy kryptograficznych.