Podatności Gitea

W Gitea trasy webowego profilu oraz kanałów RSS/Atom użytkowników i organizacji sprawdzały jedynie, czy zalogowany widz może zobaczyć właściciela o ograniczonej widoczności, nie uwzględniając ograniczenia public-only tokena dostępu użytego do uwierzytelnienia. Każdy użytkownik z tokenem public-only mógł przesłać go przez HTTP Basic authentication i odczytać profil oraz kanał aktywności użytkowników i organizacji o ograniczonej widoczności, ukrytych przed anonimowymi odwiedzającymi i odrzucanych na równoważnych trasach API.

W Gitea trasa webowa /{username} akceptowała osobiste tokeny dostępu przez HTTP Basic authentication bez sprawdzania ich zakresu. Token ograniczony do niepowiązanego zakresu, np. read:issue, mógł odczytać prywatną aktywność właściciela przez kanał RSS/Atom i kartę aktywności profilu oraz aktywność innych członków prywatnej organizacji przez kanał organizacji; token public-only mógł wylistować prywatne repozytoria i organizacje właściciela oraz wyrenderować prywatne README profilu. Dla tokena administratora serwisu dotyczyło to każdego konta.

W Gitea tablice projektów repozytoriów i organizacji wyświetlały pull requesty odwołujące się do każdego zgłoszenia na tablicy bez sprawdzania, czy widz może je odczytać. Gdy prywatny pull request wspominał zgłoszenie na tablicy, którą widz może otworzyć, tablica ujawniała ścieżkę prywatnego repozytorium oraz numer, tytuł i stan pull requesta, w przypadku publicznej tablicy także anonimowym odwiedzającym. Treść, diff i pliki pull requesta nie zostały ujawnione.

W Gitea trasa DELETE /api/v1/orgs/{org}/repos usuwa wszystkie repozytoria organizacji, ale nie egzekwowała ograniczenia public-only tokenów dostępu: sprawdzała jedynie, czy sama organizacja jest publiczna. Token public-only właściciela publicznej organizacji mógł zatem trwale usunąć prywatne repozytoria organizacji, do których taki token nie powinien mieć dostępu.

W Gitea interfejs webowy blokuje zmiany zgłoszeń i pull requestów w zarchiwizowanych repozytoriach, ale kilka tras zgłoszeń w REST API nie sprawdzało, czy repozytorium jest zarchiwizowane. Użytkownik uprawniony do zmiany zgłoszeń w zarchiwizowanym repozytorium mógł przez API edytować, zamykać lub usuwać zgłoszenia, zmieniać etykiety i terminy, dodawać lub usuwać śledzony czas i stopery, dodawać reakcje, zmieniać blokady zgłoszeń i przypinać zgłoszenia, modyfikując dane, które archiwizacja ma zamrozić.

W Gitea wersja 1.27.3 uniemożliwiła osobistym tokenom dostępu ograniczonym do zasobów publicznych (public-only) tworzenie repozytoriów przez POST /api/v1/user/repos i POST /api/v1/repos/migrate, ale trasy POST /api/v1/org/{org}/repos, POST /api/v1/orgs/{org}/repos, POST /api/v1/orgs i POST /api/v1/repos/{owner}/{repo}/generate nadal akceptowały takie tokeny. Posiadacz tokena public-only z potrzebnymi zakresami zapisu mógł tworzyć prywatne repozytoria w organizacjach, w których właściciel tokena może tworzyć repozytoria, tworzyć prywatne organizacje i generować prywatne repozytoria z szablonów.

W Gitea endpoint userinfo OAuth2 (/login/oauth/userinfo) decydował, czy ograniczyć roszczenie groups do publicznych organizacji, ponownie parsując nagłówek Authorization jako token dostępu OAuth2, zamiast używać zakresu poświadczenia, które uwierzytelniło żądanie. Gdy token OAuth2 public-only był przesyłany jako parametr zapytania lub pole formularza, albo używano osobistego tokena public-only, zakres wracał pusty, a roszczenie wymieniało prywatne organizacje, zespoły i ukryte członkostwa właściciela tokena.

W Gitea workflowy wyzwalane przez recenzję pull requesta były odczytywane z commita wskazanego w commit_id recenzji, podczas gdy ograniczenia fork były ustalane na podstawie recenzowanego pull requesta, a commit nie był sprawdzany pod kątem przynależności do tego pull requesta. Użytkownik z dostępem do odczytu repozytorium mógł umieścić w nim własny commit, przez pull request z forka lub push AGit, i przesłać recenzję wskazującą ten commit na pull requeście, którego gałąź head znajduje się w tym samym repozytorium. Na instancjach z runnerem obsługującym repozytorium workflow atakującego uruchamiał się bez zatwierdzenia, otrzymywał sekrety Actions repozytorium i jego właściciela oraz GITEA_TOKEN z dostępem zapisu do repozytorium.

Podczas parsowania przesłanego wykresu Helm Gitea dekompresowała archiwum i odczytywała każdy wpis tar w poszukiwaniu `Chart.yaml` bez limitu rozmiaru po dekompresji, a robiła to przed sprawdzeniem limitu rozmiaru pakietu, który uwzględnia tylko skompresowany rozmiar przesłania. Użytkownik z prawem zapisu do pakietów mógł wielokrotnie przesyłać małe, silnie skompresowane archiwa, powodując zużycie CPU proporcjonalne do rozmiaru po dekompresji i pogorszenie dostępności instancji Gitea.

API osi czasu zgłoszeń oraz strona WWW zgłoszenia ukrywały zdarzenia odwołań krzyżowych wskazujące na zgłoszenia niedostępne dla czytelnika, ale nie ukrywały zdarzeń „dependency added” i „dependency removed”. Gdy czytelne zgłoszenie było powiązane jako zależność ze zgłoszeniem w niedostępnym repozytorium, każdy czytelnik pierwszego zgłoszenia, w tym anonimowi użytkownicy publicznego repozytorium, otrzymywał tytuł, treść, stan, etykiety, autora i nazwy załączników powiązanego zgłoszenia przez API oraz jego repozytorium, numer i tytuł na stronie WWW.

Zakładki repozytoriów, gwiazdek i obserwowanych w profilach użytkowników oraz lista repozytoriów na stronach głównych organizacji zawierały prywatne repozytoria dla każdego zalogowanego żądania bez sprawdzania, czy żądanie używa tokenu dostępu ograniczonego do zasobów publicznych (`public-only`). Posiadacz takiego tokenu mógł wylistować prywatne repozytoria widoczne dla właściciela tokenu oraz jego gwiazdki i obserwacje prywatnych repozytoriów.

Grupa tras `/api/v1/admin` nie egzekwowała ograniczenia `public-only` tokenów dostępu osobistego. Token public-only z zakresem administratora wydany przez administratora witryny mógł wylistować prywatne organizacje i adresy e-mail wszystkich użytkowników, tworzyć organizacje, uzyskiwać tokeny rejestracji runnerów oraz tworzyć nowe konta administratorów witryny, które pozostają aktywne po unieważnieniu tokenu.

Token `GITEA_TOKEN` zadania Gitea Actions uwierzytelnia jako użytkownik systemowy `gitea-actions`, a endpointy e-mail i kluczy GPG `/api/v1/user` akceptowały tego użytkownika, więc zadanie mogło zarejestrować adres e-mail i klucz GPG; bez wymaganego potwierdzenia e-mail adres był zapisywany jako aktywowany. Weryfikacja commitów traktuje klucz bez rzeczywistego właściciela jako klucz podpisujący instancji, więc każdy użytkownik mogący uruchomić zadanie workflow mógł sprawić, że commity podpisane jego własnym kluczem były wyświetlane jako zaufane i podpisane przez instancję.

Trasy API dla wydań, zasobów wydań, kamieni milowych i etykiet repozytorium nie odrzucały zmian w zarchiwizowanych repozytoriach. Użytkownik z prawem zapisu do zarchiwizowanego repozytorium lub posiadacz jego tokenu z zakresem zapisu mógł zastępować lub usuwać zasoby wydań zachowując ich adresy pobierania, usuwać wydania i tagi oraz tworzyć, edytować lub usuwać kamienie milowe i etykiety repozytorium, które powinno być tylko do odczytu.

Gitea nie odrzucała tokenów dostępu osobistego ograniczonych do zasobów publicznych (`public-only`) na endpoincie tokenu rejestracji runnera Actions organizacji, a runner zarejestrowany uzyskanym tokenem nie był ograniczony do publicznych repozytoriów. Posiadając tylko taki token z `write:organization` należący do właściciela publicznej organizacji, atakujący mógł zarejestrować runner na poziomie organizacji i odbierać zadania prywatnych repozytoriów organizacji z włączonym Actions, w tym treść workflow, sekrety i zmienne Actions oraz token zadania z dostępem do prywatnego repozytorium.

Endpoint `GET /api/v1/users/{username}/heatmap` obliczał mapę cieplną wkładu z uprawnieniami dostępu do repozytoriów właściciela tokenu i ignorował ograniczenie `public-only` tokenu dostępu, w przeciwieństwie do endpointów aktywności. Posiadacz tokenu public-only użytkownika mógł odczytać liczby wkładu i ich 15-minutowe przedziały czasowe pochodzące z aktywności tego użytkownika w prywatnych repozytoriach.

Starsze (v1 do v3) przesyłanie artefaktów Actions przechowywało nagłówek `Content-Encoding` żądania bez sprawdzenia w kolumnie serwowanej jako `Content-Type` artefaktu przy pobieraniu, a wartość zaczynająca się od `video/` lub `audio/` usuwała także politykę Content-Security-Policy piaskownicy. Użytkownik mogący uruchomić zadanie Actions mógł przesłać artefakt renderowany przez przeglądarkę jako HTML w domenie Gitea po otwarciu bezpośredniego adresu pobierania, a adres jest anonimowo osiągalny w publicznych repozytoriach.

Podatność w Gitea Actions polega na tym, że tokeny zadań uwierzytelniają się w API REST jako wspólny użytkownik systemowy o ujemnym ID, który nie podlega ograniczeniom właścicielskim w filtrach repozytoriów, organizacji, projektów i kluczy. Token nie miał też zakresu API ograniczającego trasy użytkownika, więc użytkownik mogący uruchomić workflow mógł użyć tokenu z `GET /api/v1/user/repos`, aby wylistować wszystkie repozytoria w instancji, w tym prywatne repozytoria innych użytkowników i organizacji, wraz z metadanymi. Zawartość repozytoriów pozostawała chroniona przez kontrolę uprawnień na poziomie repozytorium.

W Gitea siedem tras API pod /api/v1/users/{username} (followers, following, following/{target}, starred, subscriptions, keys i gpg_keys) zostało zarejestrowanych bez middleware individualPermsChecker, które wymusza widoczność docelowego użytkownika. Uwierzytelniony użytkownik mógł odczytać listy obserwujących, obserwowanych, oznaczone gwiazdką i obserwowane repozytoria oraz publiczne klucze SSH i GPG użytkownika o ograniczonej lub prywatnej widoczności. Problem naprawiono w wersjach 1.27.3 i 28.0.0, a ujawniono w 28.2.0.

Podczas usuwania etykiety porównywano ID repozytorium z żądania z ID organizacji etykiet organizacji, a sekwencje ID nakładają się. Użytkownik z prawem zapisu do zgłoszeń repozytorium mógł usunąć etykiety organizacji o tym samym numerycznym ID co repozytorium. Etykiety są teraz usuwane wyłącznie w obrębie własnego repozytorium lub organizacji.

Podczas dodawania załączników do wydania sprawdzano repozytorium i wydanie załącznika, ale nie sprawdzano, czy załącznik jest już powiązany ze zgłoszeniem lub komentarzem. Użytkownik z prawem zapisu do wydań repozytorium, znający UUID załącznika w tym repozytorium, mógł powiązać go z wydaniem. Ujawniało to nazwę pliku, rozmiar i liczbę pobrań załącznika oraz pozwalało na jego zmianę nazwy lub usunięcie.

Sprawdzenie widoczności profili użytkowników w Gitea było stosowane tylko do żądań GET, podczas gdy POST /{username} (obserwowanie i przestawanie obserwować) wymagał jedynie zalogowanego użytkownika. Każdy uwierzytelniony użytkownik mógł więc uzyskać imię i nazwisko, lokalizację, stronę internetową oraz opis użytkownika z prywatnym profilem z odpowiedzi. Problem naprawiono w wersji 28.1.0 i ujawniono w 28.2.0.

Utworzenie wersji roboczej wydania przez API zwracało listę `assets` zbudowaną z wydania bez identyfikatora, która pasowała do każdego załącznika niepowiązanego z wydaniem. Użytkownik mogący tworzyć wersję roboczą wydania w repozytorium otrzymywał więc metadane (nazwa pliku, UUID, czas przesłania, rozmiar i liczba pobrań) załączników zgłoszeń i komentarzy z repozytoriów, których nie mógł czytać, oraz porzuconych przesłań.

GET /api/v1/user/subscriptions zwracał metadane każdego repozytorium obserwowanego przez użytkownika bez sprawdzenia, czy użytkownik nadal ma do niego dostęp. Użytkownik, który obserwował prywatne repozytorium mając dostęp, a następnie go utracił (np. przez obniżenie uprawnień zespołu), nadal mógł odczytać jego nazwę, opis, adresy klonowania, właściciela i liczniki. Problem naprawiono w wersjach 1.27.0 i 28.0.0 i ujawniono w 28.2.0.

Gitea rozwiązywało principala certyfikatu SSH, przeszukując zawartość wszystkich przechowywanych kluczy publicznych zamiast tylko kluczy principal. Gdy Gitea ufa certyfikatowi użytkownika (SSH_TRUSTED_USER_CA_KEYS) i akceptuje dowolne principaly (SSH_AUTHORIZED_PRINCIPALS_ALLOW=anything), użytkownik mógł zarejestrować linię klucza publicznego innego użytkownika jako swój principal lub posiadacz certyfikatu podpisanego przez ten urząd mógł go wylistować, a następnie uwierzytelnić się jako właściciel tego klucza przez API podpisu HTTP i wbudowany serwer SSH. Instancje nieufające certyfikatowi użytkownika nie są dotknięte.

Handlery sieciowe Gitea do dodawania i usuwania reakcji na zgłoszeniach i komentarzach nie odrzucały zablokowanych zgłoszeń dla użytkowników bez uprawnień do zapisu, choć API to robiło. Zalogowany użytkownik mogący czytać zgłoszenie mógł więc dodawać lub usuwać reakcje na zablokowanym zgłoszeniu i jego komentarzach, omijając ograniczenie interakcji wynikające z blokady. Dotyczyło to tylko reakcji; żadna treść nie mogła zostać zmieniona.

POST /{owner}/{repo}/topics zostało zarejestrowane bez middleware logowania zapewniającego ochronę przed żądaniami cross-origin, więc żądanie wysłane przez witrynę trzeciej strony nie było odrzucane. Administrator repozytorium, który odwiedził złośliwą stronę, mógł mieć zmienione tematy swojego repozytorium. Żadne inne ustawienia repozytorium nie były osiągalne przez tę trasę.

Handlery artefaktów Gitea Actions v4 (Twirp) wczytywały całe ciało żądania do pamięci bez limitu rozmiaru. Użytkownik mogący uruchomić workflow i uzyskać token runnera tego uruchomienia mógł wysłać zbyt duże żądanie do usługi artefaktów i wyczerpać pamięć serwera, co kończy proces Gitea. Ciało żądania jest teraz ograniczone do 1 MiB.

Żądanie /{username}/-/repositories dla użytkownika indywidualnego zamiast organizacji powodowało, że handler strony głównej organizacji dereferencjonował nil organizację i panikował. Żądanie nie wymaga uwierzytelnienia ani specjalnej konfiguracji. Serwer odpowiadał błędem HTTP 500 i logował panikę dla każdego żądania; poprawka zwraca 404 dla użytkowników indywidualnych.

Callback powiązania OpenID w ustawieniach bezpieczeństwa Gitea akceptował pozytywną asercję OpenID 2.0 bez sprawdzenia, czy zalogowany użytkownik rozpoczął proces łączenia. Ponieważ OpenID 2.0 pozwala na asercje nieżądane, kontrolowany przez atakującego dostawca OpenID mógł przypiąć tożsamość atakującego do konta zalogowanej ofiary, która otworzyła spreparowany link, a następnie atakujący mógł zalogować się jako ofiara przez OpenID, co nie stosuje lokalnych kontroli TOTP ani WebAuthn. Callback wymaga teraz ograniczonego czasowo parametru `state` powiązanego z użytkownikiem.

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.

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

W Gitea, wymóg zatwierdzenia dla pierwszego kontrybutora z forka jest egzekwowany przez blokowanie zadań, ale niektóre ścieżki przejść i wysyłek nie sprawdzają ponownie wymogu zatwierdzenia. Osobne uruchomienie współdzielące grupę concurrency na poziomie zadania może anulować oczekujące zadanie i spowodować ponowne wyemitowanie i wysłanie zablokowanych zadań bez zatwierdzenia.

Wstępne sprawdzanie wersji podczas migracji z GitLab w Gitea używa klienta HTTP bez limitu czasu i nie dołącza kontekstu anulowania zadania migracji. Uwierzytelniony użytkownik mogący rozpoczynać migracje może wskazać kontrolowany przez atakującego serwer, który utrzymuje odpowiedź otwartą w nieskończoność. Żądanie trwa po anulowaniu zadania i może wyczerpać pulę procesów roboczych migracji, uniemożliwiając postęp innym migracjom.

API łączenia zespołów z repozytorium w Gitea pozwala administratorowi repozytorium, który nie jest właścicielem organizacji, przypinać zespoły organizacji do repozytorium mimo wyłączonego RepoAdminChangeTeamAccess. Endpoint nie egzekwuje ograniczenia organizacji dotyczącego zmiany dostępu zespołów przez administratorów repozytorium.

Żądanie strony profilu użytkownika lub organizacji z nagłówkiem Accept dla RSS/Atom zwracało kanał aktywności właściciela bez sprawdzenia widoczności, które stosują strona profilu i trasy .rss/.atom. Anonimowi, ograniczeni użytkownicy i nie-członkowie mogli potwierdzić istnienie ograniczonych lub prywatnych użytkowników i organizacji oraz czytać ich dane profilowe i publiczną aktywność, nawet gdy funkcja ENABLE_FEED była wyłączona. Aktywność w prywatnych repozytoriach nie była uwzględniana.

Punkt końcowy API Gitea do tworzenia mirrorów push sprawdzał tylko, czy mirrorowanie jest włączone, a nie ustawienie [mirror] DISABLE_NEW_PUSH, które egzekwuje interfejs webowy. Administrator repozytorium mógł tworzyć nowe mirrory push w instancjach, gdzie administrator witryny je wyłączył. Mirror push wypycha wszystkie refy repozytorium do zdalnego repozytorium wybranego przez wywołującego, przy każdym commicie lub zgodnie z harmonogramem.

Punkt API GET /api/v1/repos/{owner}/{repo}/media/{filepath} zapisywał pliki do 1 KiB przechowywane bezpośrednio w Git (nie w LFS) do odpowiedzi bez nagłówków content type i disposition, których Gitea używa dla treści użytkownika. Plik HTML w repozytorium był renderowany przez przeglądarkę na origin Gitea. Użytkownik z prawem push do repozytorium mógł uruchomić JavaScript w sesji ofiary otwierającej URL media i działać z jej uprawnieniami.

Przy ustawieniu [repository] FORCE_PRIVATE = true, Gitea tworzy nowe repozytoria jako prywatne, ale hook post-receive nadal stosował opcję push repo.private=false do pustego repozytorium utworzonego przez push. Każdy użytkownik mogący tworzyć repozytoria mógł uczynić swoje nowe repozytorium publicznym, naruszając politykę instancji. Domyślna konfiguracja nie jest dotknięta.

API mirrorów push Gitea sprawdzało, czy właściciel repozytorium, a nie żądający użytkownik, może używać ścieżek lokalnego systemu plików. W instancjach z [security] IMPORT_LOCAL_PATHS = true, administrator repozytorium bez uprawnień do importowania lokalnych ścieżek mógł dodać mirror push do lokalnej ścieżki na serwerze, gdy właściciel repozytorium miał takie uprawnienie. Gitea wypychał refy repozytorium do istniejącego repozytorium Git na tej ścieżce z uprawnieniami procesu Gitea.

Trasy API Gitea dla załączników do zgłoszeń (issues) akceptowały również załączniki należące do komentarzy na tym zgłoszeniu. Ponieważ autor zgłoszenia może edytować i usuwać załączniki zgłoszenia, użytkownik, który otworzył zgłoszenie, mógł zmienić nazwę lub usunąć załączniki, które inni użytkownicy opublikowali w komentarzach na tym zgłoszeniu. Zawartość załączników nie mogła być zmieniona.

Trasa webowa Gitea do usuwania tagów wymaga tylko zapisu do jednostki Code, ale współdzieli handler z usuwaniem wydań i nie sprawdzała, czy cel jest zwykłym tagiem. Współpracownik z prawem zapisu do Code i bez prawa zapisu do Releases mógł trwale usunąć opublikowane wydania tego repozytorium, w tym ich załączniki. Chronione reguły tagów obejmujące tag wydania nadal blokowały usunięcie.

Podczas migracji repozytorium z innej instancji Gitea, Gitea używało rozmiaru strony zgłoszonego w ustawieniach API serwera źródłowego do zakończenia paginowanych pobrań. Źródło zgłaszające max_response_items jako 0 powodowało, że te pętle działały w nieskończoność i zwiększały pamięć serwera aż do jej wyczerpania. Każdy użytkownik mogący migrować repozytoria mógł wskazać migrację na serwer, który kontroluje, i spowodować denial of service.