Podatności Gitea

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.

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.

Ścieżki wyszukiwania zgłoszeń w API i interfejsie webowym Gitea nie traktują kont o ograniczonym dostępie jako anonimowych przeglądających przy ocenie właścicieli repozytoriów o widoczności Limited. Użytkownik o ograniczonym dostępie może wyszukiwać i pobierać tytuły oraz treści zgłoszeń, które powinny być ukryte przez politykę widoczności właściciela. Dopasowanie słów kluczowych może również ujawnić, że ukryta treść zgłoszenia lub komentarze zawierają podany termin.

Handlery API Gitea do kanału aktywności i mapy cieplnej wkładu nie stosują sprawdzenia widoczności profilu dla kont o ograniczonym dostępie przeglądających użytkowników o widoczności Limited. Użytkownik o ograniczonym dostępie może pobrać zapisy aktywności i znaczniki czasu wkładu, których odmawiają odpowiadające ścieżki profilu. Ujawniona aktywność może obejmować nazwy repozytoriów, wiadomości commitów oraz zdarzenia zgłoszeń lub pull requestów powiązane z kwalifikującą się aktywnością w publicznych repozytoriach.

W Gitea przy zdarzeniach pull request workflow jest odczytywany z gałęzi źródłowej PR, a gdy filtry gałęzi lub ścieżek wykluczają wykonanie, publikowany jest syntetyczny status "skipped". Autor forka może dostarczyć workflow pasujący do wymaganego kontekstu statusu, ale celowo uniemożliwić jego uruchomienie, a status "skipped" jest liczony jako sukces.

API listy organizacji użytkownika w Gitea zwraca organizacje o ograniczonej widoczności dla uwierzytelnionych kont ograniczonych, nie stosując restrykcji widoczności wymuszanej przez endpoint pojedynczej organizacji. Ograniczony użytkownik może wylistować publiczne członkostwa w organizacjach znanego użytkownika oraz pobrać nazwy, opisy i awatary organizacji o ograniczonej widoczności.

Rejestr pakietów Gitea przyznaje uwierzytelnionym użytkownikom dostęp do odczytu pakietów należących do użytkowników o ograniczonej widoczności, nie wykluczając kont ograniczonych. Ograniczony użytkownik może wyliczyć i pobrać takie pakiety mimo polityki widoczności, która powinna to uniemożliwiać.

Ścieżka autoryzacji współwłaściciela w Gitea przy odczycie międzyrepozytoryjnych workflow wielokrotnego użytku nie wyklucza uruchomień z forków pull requestów. Zatwierdzony workflow z forka wskazujący na prywatne repozytorium może odczytać pliki workflow z innego prywatnego repozytorium, które ufa właścicielowi repozytorium bazowego.

Parser pakietów Swift w Gitea ogranicza każdy manifest do 128 KiB, ale nie ogranicza liczby manifestów ani ich łącznego rozmiaru przed wczytaniem do pamięci. Uwierzytelniony użytkownik z uprawnieniem publikowania pakietów może przesłać silnie skompresowane archiwum z wieloma manifestami, powodując alokacje znacznie większe niż przesłane archiwum.

Gitea parsuje przesłane pakiety Alpine przed egzekwowaniem kwot rozmiaru pakietów i nie ogranicza zdekompresowanych danych .PKGINFO ani liczby wpisów zależności i provides. Uwierzytelniony użytkownik z uprawnieniem publikowania pakietów może przesłać małe, silnie skompresowane archiwum powodujące nieproporcjonalnie duże alokacje pamięci podczas parsowania i generowania metadanych.

Downloader migracji OneDev w Gitea wczytuje całą odpowiedź zdalnej wersji do pamięci bez limitu rozmiaru i używa klienta bez limitu czasu. Uwierzytelniony użytkownik mogący rozpocząć migrację repozytorium może skierować ją do kontrolowanego przez atakującego serwera zgodnego z OneDev, który zwraca odpowiedź o nadmiernym rozmiarze lub nigdy się nie kończącą.

Renderer notatników Jupyter w Gitea wstawia metadane language_info.name notatnika do atrybutu klasy CSS, wyłączając sanityzację i renderując bezpośrednio w głównym dokumencie bez piaskownicy iframe. Złośliwy notatnik w repozytorium może dostarczyć wiele klas CSS tworzących nakładkę zasłaniającą widok i przechwytującą kliknięcia, gdy inny użytkownik go wyświetla. Zgłoszony wpływ to UI redress; wykonanie skryptu nie zostało wykazane.

Endpointy API ulubionych repozytoriów i śledzonego czasu w Gitea nie sprawdzają ponownie bieżących uprawnień do repozytorium przed zwróceniem danych powiązanych z żądającym użytkownikiem. Użytkownik, któremu odebrano dostęp do prywatnego repozytorium, może nadal pobierać metadane repozytorium przez /api/v1/user/starred oraz tytuły prywatnych zgłoszeń przez /api/v1/user/times.

Gdy włączone jest logowanie OpenID, Gitea przyjmuje podany przez użytkownika adres URL OpenID i wykonuje żądania discovery bez walidacji miejsca docelowego względem adresów sieci wewnętrznej. Nieuwierzytelniony zdalny atakujący może spowodować, że serwer połączy się z usługami HTTP na interfejsie loopback lub w sieci prywatnej.

Renderer znaczników Org-mode w Gitea przetwarza dyrektywy INCLUDE dostarczone do punktu końcowego znaczników repozytorium bez zapobiegania dostępowi do plików po stronie serwera. Niezautoryzowany atakujący może użyć publicznego repozytorium do odczytu plików dostępnych dla konta usługi Gitea. Jeśli ujawnione pliki zawierają app.ini i INTERNAL_TOKEN, atakujący może zmodyfikować hook Git i wykonać polecenia jako konto usługi Gitea.

Punkt tokenu OAuth2 Gitea weryfikował podpis i grant tokenu przesłanego z typem grantu refresh_token, ale nie sprawdzał, czy token jest tokenem odświeżania. Niewygasły token dostępu dla tej samej aplikacji OAuth2 i grantu mógł być wymieniony na nowy token dostępu i token odświeżania. Posiadacz takiego tokenu dostępu mógł utrzymać dostęp poza pierwotny czas życia tokenu.

Gitea akceptował wypchnięte drzewa Git zawierające dwa wpisy o tej samej nazwie, które własne kontrole spójności Gita odrzucają. Widoki internetowe Gitea rozwiązywały taką ścieżkę do pierwszego wpisu, podczas gdy `git checkout`, Gitea Actions i archiwa wydań używają ostatniego. Współpracownik mógł otworzyć pull request, którego diff i widoki plików pokazują nieszkodliwą treść, podczas gdy CI i checkouts w tym samym commicie używają innej, kontrolowanej przez atakującego treści. Przychodzące obiekty są teraz sprawdzane pod kątem spójności; obiekty już przechowywane w istniejących repozytoriach nie są ponownie skanowane.

Gitea Actions decydował, czy przebieg pull requesta z forka wymaga zatwierdzenia, na podstawie użytkownika, który wyzwolił zdarzenie, a nie autora pull requesta. Dla aktywności `pull_request` wyzwolonej przez opiekuna podczas zwykłego triażu, takiego jak dodanie etykiety, przebieg był tworzony bez wymagania zatwierdzenia, podczas gdy definicja przepływu pracy była nadal pobierana z głowy forka. Tam, gdzie Actions jest włączone i zarejestrowany jest pasujący runner, kod przepływu pracy kontrolowany przez fork mógł działać na runnerach bazowego repozytorium bez wyraźnego zatwierdzenia.

Ścieżki logowania Gitea przez OAuth2 i OpenID Connect nie wymagają wyzwania WebAuthn, gdy WebAuthn jest jedynym skonfigurowanym drugim czynnikiem uwierzytelniania. Osoba uwierzytelniona przez zewnętrzny przepływ tożsamości może uzyskać pełną sesję bez weryfikacji passkey, która jest wymagana przy logowaniu hasłem. Jedna z dotkniętych ścieżek może również utrwalić powiązanie zewnętrznej tożsamości, rozszerzając kompromitację poza początkową sesję; konta z TOTP są poza opisanym scenariuszem WebAuthn-only.

Gdy wbudowany serwer SSH Gitea jest włączony (`START_SSH_SERVER = true`), prezentowany klucz publiczny był wyszukiwany za pomocą porównania SQL `LIKE` jego zakodowanej treści, które jest niewrażliwe na wielkość liter na niektórych bazach danych, w tym domyślnym SQLite. Atakujący, który może skonstruować wariant wielkości liter zarejestrowanego klucza publicznego RSA innego użytkownika, dla którego może wyprowadzić klucz prywatny, może spowodować dopasowanie tego klucza do konta ofiary i uwierzytelnić się przez SSH jako ten użytkownik. Klucze są teraz wyszukiwane po odcisku palca.

Dwie podatności SSRF w migracji/mirrorowaniu Gitea (DNS rebinding + brak ponownej walidacji).

Tokeny repozytorium tylko do odczytu mogą aktualizować prywatne gałęzie head PR.

Endpoint łączący repozytorium z zespołem omija ustawienie organizacji RepoAdminChangeTeamAccess. Oznacza to, że użytkownik bez odpowiednich uprawnień może zmienić przypisanie repozytorium do zespołu.

Kradzież tokena „Remember-Me” w Gitea nie unieważnia sesji atakującego, co pozwala na dalszy nieautoryzowany dostęp.

Podatność umożliwia eskalację uprawnień poprzez rozszerzenie zakresu tokena dostępu w API.

Token o zakresie public-only może ominąć ograniczenia dla właścicieli o ograniczonej widoczności (kategorie Repozytorium i Pakiet) — pozostałość po CVE-2026-25714 / PR #37118.

Endpoint userinfo w OIDC zwraca dane tożsamości bez egzekwowania zakresów tokenów API.

Podatność w Gitea Actions Artifacts V4 wynika z niejednoznaczności HMAC w podpisanych URL-ach, co umożliwia odczyt artefaktów z innego repozytorium oraz zapis stanu przesyłania między zadaniami.

Podatność w Gitea przed wersją 1.26.0 polega na tym, że podczas przetwarzania wejścia z hooka pre-receive nie następuje zamknięcie połączenia w przypadku błędów bufio.Scanner. Umożliwia to przesłanie zbyt dużego wejścia, które omija sprawdzanie ochrony gałęzi.

Podatność w Gitea przed wersją 1.25.5 polega na tym, że operacje push LFS i synchronizacji mirror nie korzystają z transportu HTTP migracji, co omija skonfigurowane zabezpieczenia transportu migracji dla tych żądań LFS.

Podatność w Gitea przed wersją 1.25.5 nieprawidłowo przechowuje metodę wyzwania PKCE S256 podczas autoryzacji OAuth2, co umożliwia wymianę tokena bez wymaganego sprawdzenia weryfikatora.

Podatność w Gitea przed wersją 1.25.5 pozwala na ponowne użycie wygasłych lub jednorazowych kodów autoryzacyjnych OAuth2 podczas wymiany na token. Brak spójnego egzekwowania wygaśnięcia i jednorazowości kodów może prowadzić do nieautoryzowanego dostępu.

Podatność w Gitea przed wersją 1.25.5 nieprawidłowo obsługuje rozpoznawanie ścieżek podczas generowania repozytorium z szablonu, co pozwala na odczyt lub zapis przez dowiązania symboliczne lub inne nieregularne ścieżki.

Podatność CVE-2026-22874 dotyczy Gitea w wersjach do 1.26.2 włącznie. Mechanizm ochrony przed SSRF (Server-Side Request Forgery) w filtrach list dozwolonych dla webhooków i migracji jest niekompletny, co może umożliwić atakującemu wykonanie nieautoryzowanych żądań do wewnętrznych zasobów sieciowych.

W Gitea przed wersją 1.25.5 brakuje walidacji ograniczeń dla pól tworzenia repozytorium, w tym pól szablonów z limitem długości oraz wartości modelu zaufania lub formatu obiektu.

Obraz Dockera Gitea w wersjach do 1.26.2 domyślnie ustawia zmienną REVERSE_PROXY_TRUSTED_PROXIES=*, co pozwala dowolnemu źródłowemu adresowi IP podszyć się pod użytkownika, gdy włączone są nagłówki uwierzytelniania reverse proxy, takie jak X-WEBAUTH-USER.

Podatność w Gitea do wersji 1.26.1 włącznie umożliwia pobieranie archiwów repozytoriów z pominięciem kontroli zakresu tokena na punkcie końcowym pobierania archiwów przez WWW.

Podatność w Gitea umożliwia nieprawidłową walidację własności repozytorium podczas łączenia załączników z wydaniami. Załącznik przesłany do prywatnego repozytorium może zostać powiązany z wydaniem w innym publicznym repozytorium, co udostępnia go nieautoryzowanym użytkownikom.

Gitea nieprawidłowo weryfikuje własność repozytorium podczas usuwania blokad Git LFS. Użytkownik z prawem zapisu do jednego repozytorium może usunąć blokady LFS należące do innych repozytoriów.

Gitea nieprawidłowo weryfikuje własność projektu w operacjach na projektach organizacji. Użytkownik z uprawnieniami do zapisu w projekcie w jednej organizacji może modyfikować projekty należące do innej organizacji.

Gdy w Gitea opcja [oauth2_client].ACCOUNT_LINKING jest ustawiona na auto (nie domyślnie) i rejestracja jest włączona, formularz rejestracji przez linkowanie konta wyszukiwał istniejące konto po nazwie użytkownika lub e-mailu z formularza, zamiast po tożsamości potwierdzonej przez dostawcę OAuth2. Atakujący z kontem u dostawcy OAuth2 mógł podać nazwę innego użytkownika, powiązać swoją tożsamość zewnętrzną z tym kontem Gitea i zalogować się jako on bez hasła, w tym jako administrator; powiązanie pozostawało aktywne przy kolejnych logowaniach.