CVE-2026-104636

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