CVE-2026-78433

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