Podatności Gitea

Podczas transferu prywatnego repozytorium do użytkownika bez dostępu, Gitea przyznaje mu tymczasowy dostęp do odczytu jako współpracownikowi. Odrzucenie lub anulowanie transferu nie cofało tej współpracy, więc odbiorca zachowywał trwały dostęp do odczytu do prywatnego repozytorium, w tym do kodu, zgłoszeń, pull requestów i wiki, oraz mógł je klonować. Właściciel repozytorium nie był powiadamiany. Dostęp przyznany przez transfer jest teraz usuwany, a współprace istniejące przed transferem są zachowywane.

Gitea rozszerza statyczną macierz `strategy.matrix` w przepływie pracy do pełnego iloczynu kartezjańskiego bez limitu rozmiaru podczas tworzenia przebiegu, przed zastosowaniem bramki zatwierdzania pull requestów z forka. Użytkownik, który może otworzyć pull request z forka, może przesłać mały plik przepływu pracy, którego macierz rozszerza się do bardzo dużej liczby zadań, zużywając pamięć serwera i potencjalnie kończąc proces Gitea. Nie jest wymagany runner. Macierze statyczne powyżej 256 kombinacji są teraz odrzucane przed rozszerzeniem.

Gdy instalator internetowy Gitea jest dostępny dla bazy danych, która już zawiera użytkowników, na przykład po zresetowaniu `INSTALL_LOCK` do `false`, przesłanie formularza instalacji z nazwą administratora pasującą do istniejącego konta wydawało uwierzytelnioną sesję dla tego konta bez weryfikacji hasła. Jeśli konto jest administratorem, sesja daje pełny dostęp administracyjny, w tym możliwość zmiany hasła konta. Bazy danych z jednym użytkownikiem również nie wymagały potwierdzenia ponownej instalacji.

Przy ustawieniu `[migrations] ALLOWED_DOMAINS` na pasujący wpis, taki jak `*` lub wildcard nazwy hosta, walidacja adresów URL migracji w Gitea mogła zezwalać na adresy zastrzeżone i link-local, takie jak `169.254.169.254`, nawet gdy `ALLOW_LOCALNETWORKS = false`. Lista blokowania sieci lokalnych nie obejmowała tych zakresów, a nazwa hosta pasująca do listy dozwolonych była akceptowana niezależnie od jej rozwiązanego adresu. Użytkownik, który może rozpocząć migracje na takiej instancji, mógł dotrzeć do tych adresów z serwera Gitea; domyślna pusta konfiguracja `ALLOWED_DOMAINS` nie jest dotknięta.

Wyrażenie regularne zewnętrznego trackera problemów repozytorium zawierające naprzemienne grupy przechwytujące mogło generować nieprawidłowe indeksy wycinka podczas renderowania odniesień do problemów w Gitea, powodując błąd runtime, który kończył proces Gitea. Użytkownik, który może edytować ustawienia zewnętrznego trackera problemów repozytorium, mógł sprawić, że późniejsze renderowanie pasującej treści, takie jak przeglądanie README, spowoduje awarię instancji dla wszystkich użytkowników.

Podczas przetwarzania treści zgłoszeń i komentarzy, Gitea skanował cały poprzedzający tekst w poszukiwaniu słów kluczowych akcji, takich jak "closes" lub "fixes", raz dla każdego linku Markdown, co dawało czas przetwarzania kwadratowy w stosunku do rozmiaru wejścia. Uwierzytelniony użytkownik mogący przesyłać treść zgłoszeń lub komentarzy mógł wysłać spreparowaną treść o rozmiarze około 1 MB, która zajmuje rdzeń CPU przez kilka minut, trzymając otwartą transakcję bazy danych.

Gitea walidował adres zdalny mirrora push przeciwko listom dozwolonych i blokowanych `[migrations]` tylko podczas tworzenia mirrora. Każda synchronizacja przekazywała zapisany adres bezpośrednio do `git push`, więc nazwa, która później rozwiązała się na zablokowany lub wewnętrzny adres, była nadal osiągana. Użytkownik z dostępem administracyjnym do repozytorium, w tym repozytoriów, które sam tworzy, mógł skierować synchronizację mirrora push na wewnętrzne usługi Git i wymusić wypchnięcie zawartości repozytorium do nich.

Gdy push był uwierzytelniany kluczem wdrożeniowym, Gitea rejestrował właściciela repozytorium jako wypychającego, więc kontrole uprawnień w potoku hooka push oceniały właściciela zamiast klucza wdrożeniowego. Posiadacz zapisywalnego klucza wdrożeniowego mógł tworzyć chronione tagi bez znajdowania się na liście dozwolonych tagów i zmieniać widoczność repozytorium przez opcje push, na przykład czyniąc prywatne repozytorium publicznym. Pull requesty utworzone przez przepływ AGit z kluczem wdrożeniowym były również przypisywane do właściciela.

Gitea sprawdza nazwę hosta migracji repozytorium względem list dozwolonych i zablokowanych przed wywołaniem Git, ale podproces Git niezależnie rozwiązuje nazwę hosta podczas łączenia. Atakujący, który może rozpocząć migrację i kontrolować DNS celu, może zmienić adres między walidacją a połączeniem, aby dotrzeć do zablokowanego wewnętrznego adresu. Dotknięta ścieżka to operacja klonowania Git; walidacja w dialerze klienta HTTP migracji nie chroni niezależnie łączącego się podprocesu Git.

Gitea sprawdza początkowy zdalny URL dla mirrorów push, zdalnych kontroli wiki i pobierania głów pull requestów migracji, ale późniejsze operacje Git podążają za przekierowaniami HTTP bez ponownej walidacji celu. Administrator repozytorium używający dozwolonego punktu końcowego, który przekierowuje, może sprawić, że klient Git Gitea wyśle żądania na adres, który polityka hostów wychodzących w przeciwnym razie zablokowałaby. Wpływ zależy od skonfigurowanej polityki i wewnętrznych usług dostępnych z serwera.

Gitea Actions blokuje zadania przebiegów workflow z pull requestów od pierwszego kontrybutora z forka, dopóki opiekun nie zatwierdzi przebiegu. Ścieżka ponownego uruchomienia wymagała tylko, aby przebieg był zakończony, i budowała zadania nowej próby bez uwzględnienia oczekującego zatwierdzenia, więc gdy użytkownik z uprawnieniami zapisu do Actions anulował przebieg oczekujący na zatwierdzenie, a następnie uruchomił go ponownie, nowe zadania zostały utworzone jako oczekujące, a nie zablokowane, podczas gdy przebieg nadal rejestrował, że wymagane jest zatwierdzenie. Anulowanie i ponowne uruchamianie starych kontroli z forka jest rutynową czynnością, która nie obejmuje kontroli zatwierdzenia, więc tam, gdzie Actions jest włączone i zarejestrowany jest pasujący runner, kod workflow pobrany z głowy pull requesta z forka może zostać uruchomiony na runnerach repozytorium bez wyraźnego zatwierdzenia.

Użytkownik, który może otworzyć pull request z forka, może umieścić treść workflow ze współdzieloną grupą współbieżności na poziomie przebiegu w przebiegu Gitea Actions oczekującym na zatwierdzenie. Gdy późniejszy przebieg w tej grupie anuluje zablokowane zadanie, przebieg staje się terminalny, ale nadal oznaczony jako wymagający zatwierdzenia. Jeśli opiekun później zatwierdzi przebieg, Gitea przekazał już anulowane zadanie z powrotem przez przygotowanie współbieżności, ustawił je na oczekujące i umożliwił przejęcie przez pasujący runner, wykonując kod workflow kontrolowany przez fork. Wykorzystanie wymaga późniejszego zatwierdzenia przez opiekuna, włączonych Actions i runnera akceptującego zadania repozytorium.

Gdy wstawiano przebieg Gitea Actions, starsze przebiegi w tej samej grupie współbieżności na poziomie workflow były anulowane bez sprawdzania, czy nowy przebieg nadal wymaga zatwierdzenia. Ponieważ przebiegi z pull requestów z forków są wstawiane pod repozytorium bazowym, użytkownik, który może otworzyć pull request z forka, może anulować zaufane trwające przebiegi, które dzielą grupę współbieżności z włączoną opcją `cancel-in-progress`, bez zatwierdzenia i bez uruchamiania żadnego kodu. Na self-hosted runnerach może to przerwać wdrożenia i pozostawić częściowy stan.

Rejestr kontenerów Gitea serwował pobieranie blobów z `Content-Type` pobranym z typu mediów zadeklarowanego w wypchniętych manifestach obrazów, bez `Content-Disposition` ani restrykcyjnej polityki bezpieczeństwa treści. Użytkownik, który może wypychać obrazy kontenerów, może opublikować blob zawierający HTML i JavaScript z typem mediów `text/html`. Gdy ofiara uwierzytelniona w instancji otworzy URL bloba w przeglądarce, skrypt uruchamia się na originie Gitea i może wykonywać działania jako ofiara, takie jak tworzenie tokenów API.

Zmiana uprawnień zespołu organizacji przez API z tylko polem `permission` nie odbudowywała dostępu per-jednostka zespołu, a żądany poziom nie był stosowany jako limit. Po tym, jak właściciel organizacji zdegradował zespół, na przykład z admina do read, członkowie zespołu zachowali poprzednie uprawnienia jednostek, w tym dostęp do zapisu do repozytoriów zespołu. Formularz internetowy nie był dotknięty.

Kontrole egress dla migracji repozytoriów i mirrorów pull w Gitea mogły zostać ominięte przez nazwę hosta zwracającą wiele odpowiedzi DNS, ponieważ walidowany adres niekoniecznie był adresem, z którym Git później się łączył. Użytkownik z niskimi uprawnieniami, który może tworzyć migracje lub mirrory, mógł skierować serwer do wewnętrznych usług, czytając i zapisując do dostępnych wewnętrznych punktów końcowych Git lub HTTP. Treść z wewnętrznych odpowiedzi mogła być dodatkowo ujawniona przez komunikaty błędów migracji i mirrorów.

W Gitea, gdy skonfigurowano `[migrations] ALLOWED_DOMAINS`, nazwa hosta z listy dozwolonych była akceptowana bez weryfikacji jej rozwiązanego adresu względem ograniczeń sieci lokalnej. Użytkownik mogący uruchamiać migracje repozytoriów i kontrolujący DNS dozwolonej nazwy hosta mógł wymusić jej rozwiązanie na adres loopback lub prywatny, omijając `ALLOW_LOCALNETWORKS = false` i uzyskując dostęp do usług wewnętrznych z serwera Gitea. Instancje bez skonfigurowanego `ALLOWED_DOMAINS` nie są dotknięte tym obejściem.

Nieograniczone metadane plików pakietów Arch mogą powodować amplifikację zasobów podczas przesyłania pakietów w Gitea.

Nagłówek autoryzacji webhooka jest zwracany w postaci zwykłego tekstu przez API.

Poprawka ClearRepoWatches nie została zastosowana do ścieżki API EditRepo — siostrzana ścieżka kodu zachowuje nieaktualne obserwacje przy zmianie repozytorium z publicznego na prywatne.

Ujawnienie istnienia prywatnego repozytorium przez punkt końcowy go-get Meta.

Oracle enumeracji identyfikatorów etykiet między repozytoriami przez nieograniczone API DeleteIssueLabel.

Obejście egzekwowania zakresu osobistego tokena dostępu na stronie głównej repozytorium (`GET /{owner}/{repo}`) ujawnia zawartość prywatnego repozytorium.

SSRF w migracji repozytorium przez obejście listy dozwolonych DNS z wieloma odpowiedziami.

SSRF w restore-repo przez nieoczyszczony Head.CloneURL w pull_request.yml.

Webhooki utworzone przez współpracownika nadal działają po cofnięciu mu dostępu do repozytorium, co umożliwia ciągłą eksfiltrację zawartości prywatnego repozytorium w czasie rzeczywistym. Problem wynika z niepełnego usuwania uprawnień w funkcji `DeleteCollaboration`.

Ochrona gałęzi może zostać ominięta poprzez zmianę celu pull requesta, co pozwala zachować nieaktualną flagę zatwierdzenia `official`. Umożliwia to wprowadzanie zmian do chronionych gałęzi bez wymaganego zatwierdzenia.

Międzyrepozytoryjna podatność IDOR w usuwaniu zależności problemu (issue-dependency) pozwala atakującemu manipulować i komentować prywatne repozytoria, do których nie ma dostępu. Brakuje odpowiedniej autoryzacji na poziomie obiektu.

Podatność umożliwia manipulację widocznością repozytorium poprzez opcje push w Git. Atakujący może zmienić widoczność repozytorium (np. z prywatnego na publiczne) bez odpowiednich uprawnień.

Funkcja ParseAcceptLanguage w oprogramowaniu pośredniczącym Locale powoduje atak DoS o złożoności kwadratowej na nieuwierzytelnionych żądaniach. Wysyłanie specjalnie spreparowanych nagłówków Accept-Language może przeciążyć serwer.

Podatność w Gitea LFS umożliwia eskalację uprawnień za pomocą kluczy wdrożeniowych (deploy keys). Osoba posiadająca klucz wdrożeniowy może uzyskać wyższe uprawnienia niż zamierzono.

Metadane prywatnego repozytorium pozostają dostępne po cofnięciu dostępu użytkownikowi. Oznacza to, że informacje o repozytorium (np. nazwa, opis) mogą być nadal widoczne dla osób, które utraciły uprawnienia.

W kodzie code.gitea.io/gitea występuje brak autoryzacji oraz obejście autoryzacji poprzez kontrolowany przez użytkownika klucz, nieprawidłowe przypisanie uprawnień do krytycznych zasobów oraz ujawnienie wrażliwych informacji nieupoważnionemu aktorowi.

Ograniczenie tokenów API tylko do publicznych zasobów nie jest egzekwowane na trasach API zespołów. Oznacza to, że token przeznaczony tylko do publicznego dostępu może uzyskać dostęp do danych zespołów, które powinny być prywatne.

Podatność umożliwia obejście zakresu osobistych tokenów dostępu typu public-only w punktach końcowych organizacji i uprawnień. Oznacza to, że token przeznaczony tylko do operacji publicznych może uzyskać dostęp do operacji wymagających szerszych uprawnień.

Podatność umożliwia obejście listy dozwolonych rozszerzeń dla załączników wydań poprzez formularz edycji wydania w przeglądarce. Jest to wariant wcześniejszej podatności CVE-2025-68939.

Podatność powoduje wyciek listy członków prywatnej organizacji przez punkt końcowy /members API. Jest to niekompletna poprawka dla PR #38145.

Podatność w introspekcji tokenów OAuth powoduje zwracanie metadanych tokenów wydanych innym klientom, co narusza sekcję 4 specyfikacji RFC 7662.

Podatność umożliwia lokalne włączenie pliku (Local File Inclusion) poprzez użycie URI file:// w funkcji przywracania migracji. Atakujący może odczytać dowolne pliki z systemu plików serwera.

Podatność w REST API ujawnia publicznie członkostwo w organizacjach prywatnych. Osoby nieuprawnione mogą uzyskać informacje o członkach prywatnych organizacji.

Podatność w zadaniach Actions dla pull requestów z forka umożliwia odczyt trzeciego prywatnego repozytorium poprzez gałąź collaborative-owner. Brakuje zabezpieczenia dla fork-PR.

W Gitea 1.26.2 znaleziono dwie podatności typu Server-Side Request Forgery (SSRF). Umożliwiają one atakującemu wysyłanie żądań z serwera do wewnętrznych zasobów.

Podatność umożliwia ujawnienie informacji między repozytoriami poprzez API Actions na poziomie organizacji (Run/Job APIs). Atakujący może uzyskać dane z innych repozytoriów.

Podatność w migracji repozytoriów pozwala na podążanie za przekierowaniami HTTP Git po walidacji URL (allow/block), co umożliwia eksfiltrację wewnętrznych repozytoriów Git.

Podatność umożliwia ponowne powiązanie załączników do zgłoszeń/komentarzy między repozytoriami, co może ujawnić treść prywatnych załączników.

Podatność powoduje odmowę usługi (wyczerpanie CPU i pamięci) przez złożoność O(N^2) przy konkatenacji stringów podczas przesyłania pakietów Debiana.

Parser kluczy SSH w Gitea jest podatny na odmowę usługi, co może prowadzić do przeciążenia systemu.

Logowanie przez OAuth2 może reaktywować konto dezaktywowane przez administratora, jeśli źródło autoryzacji nie używa tokenów odświeżania (niepełna poprawka #38009).

API zarządzania e-mailami omija ograniczenia funkcji ManageCredentials, umożliwiając nieautoryzowane operacje na adresach e-mail.

Odwołanie do wskaźnika null w API AddTime powoduje uwierzytelnioną odmowę usługi.