CVE-2026-71301

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.

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.

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.