CVE-2026-59774

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.

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.

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.