Gitea CVE-2026-59774: publiczne repozytorium mogło czytać pliki serwera

W Gitea ujawniono krytyczną podatność CVE-2026-59774 w obsłudze dokumentów Org-mode. W określonej konfiguracji anonimowy użytkownik mógł umieścić odwołanie do lokalnego pliku w publicznym repozytorium, a serwer podczas renderowania dokumentu pobierał jego zawartość z uprawnieniami procesu Gitea. Zwykły plik tekstowy w repozytorium stawał się więc interfejsem do odczytu systemu plików hosta.

To ważny przypadek dla zespołów utrzymujących własny Git. Problem nie polega na przejęciu hasła ani złamaniu kryptografii. Naruszenie granicy zaufania powstało w wygodnej funkcji prezentacyjnej, uruchamianej automatycznie po wyświetleniu treści kontrolowanej przez użytkownika.

Jak działała podatność

Renderer Org-mode przetwarza osadzone odwołania, aby zbudować podgląd dokumentu. Według rekordu CVE-2026-59774 walidacja nie rozdzielała prawidłowo zasobów repozytorium od ścieżek lokalnych. W rezultacie żądanie renderowania mogło spowodować otwarcie pliku poza katalogiem repozytorium.

Atak był szczególnie niebezpieczny, ponieważ nie wymagał konta, jeśli napastnik mógł wskazać lub utworzyć zawartość widoczną publicznie. Odczyt następował w kontekście konta systemowego usługi. Jego zasięg zależał więc od uprawnień procesu, sposobu instalacji, wolumenów podłączonych do kontenera i lokalizacji sekretów.

Potencjalnie interesujące były pliki konfiguracyjne Gitea, klucze prywatne, tokeny integracji, dane dostępowe do bazy i zmienne zapisane w plikach środowiskowych. Sam odczyt nie daje automatycznie wykonania kodu, lecz pozyskany sekret może otworzyć API, bazę, CI albo konta administratorów. Dlatego klasyfikacja ryzyka musi uwzględniać cały graf zależności, a nie tylko serwer Git.

Kto jest narażony

Problem dotyczył wersji wskazanych w advisory producenta i został poprawiony w aktualnych wydaniach publikowanych przez projekt Gitea. Najwyższy priorytet mają instancje dostępne z internetu, z publiczną rejestracją lub publicznymi repozytoriami oraz te, które przechowują sekrety w zasięgu tego samego użytkownika systemowego.

Kontener nie rozwiązuje problemu sam z siebie. Jeżeli podłączono do niego socket Dockera, katalog domowy hosta, pliki wdrożeniowe lub wspólny wolumen z runnerem CI, lokalny odczyt wewnątrz kontenera może dotknąć szerszego środowiska. Bezpieczna instalacja powinna zakładać, że renderer treści może zostać zaatakowany.

Plan reakcji technicznej

1. Zaktualizuj Gitea do wersji naprawionej i potwierdź numer działającego procesu, nie tylko obraz zapisany w rejestrze.
2. Do czasu aktualizacji ogranicz publiczny dostęp oraz wyłącz renderowanie Org-mode, jeżeli wdrożenie na to pozwala.
3. Przeszukaj repozytoria i logi HTTP pod kątem nietypowych dokumentów Org-mode, ścieżek absolutnych, sekwencji przejścia katalogów i powtarzanych żądań podglądu.
4. Ustal, do jakich plików miał dostęp użytkownik Gitea. Traktuj ten wynik jako rzeczywisty zakres potencjalnego ujawnienia.
5. Rotuj klucze i tokeny znajdujące się w tym zakresie: bazę danych, SMTP, OAuth, webhooki, rejestr pakietów oraz poświadczenia runnerów.
6. Usuń zbędne mounty, zablokuj socket kontenera i uruchamiaj usługę jako osobny, nieuprzywilejowany użytkownik z tylko niezbędnymi prawami.
7. Zachowaj logi reverse proxy, Gitea, bazy i CI przed przebudową serwera, aby nie zniszczyć śladów.

Detekcja wymaga odtworzenia pracy renderera

Zwykłe logi dostępu mogą pokazywać jedynie poprawne żądanie strony repozytorium, bo otwarcie pliku następowało wewnątrz procesu. Warto zestawić czas renderowania z logami systemowymi, audytem odczytu plików i wywołaniami usług, których sekrety znajdowały się na hoście. Nagły dostęp procesu Gitea do katalogu SSH, konfiguracji bazy albo plików poza jego drzewem roboczym jest silniejszym sygnałem niż sam kod odpowiedzi HTTP.

Na przyszłość profil AppArmor lub SELinux powinien pozwalać usłudze czytać tylko pliki wykonywalne, konfigurację i własne dane. Sekrety można wstrzykiwać z menedżera poświadczeń dopiero do procesu, który ich potrzebuje, zamiast przechowywać komplet w czytelnym pliku. Oddzielny worker do renderowania, bez sieci i bez dostępu do konfiguracji produkcyjnej, ogranicza zasięg kolejnego błędu parsera. Test regresyjny powinien obejmować ścieżki absolutne, kodowanie separatorów, symlinki oraz odwołania przechodzące przez dozwolony katalog do celu poza nim.

Fakty źródłowe a wnioski Breachroad

Publiczne materiały potwierdzają klasę arbitrary file read, scenariusz bez uwierzytelnienia i dostępność poprawki. Nie potwierdzają masowego wykorzystania każdej podatnej instancji. Lista możliwych sekretów zależy od lokalnego wdrożenia i jest analizą ekspozycji, nie dowodem ich kradzieży.

Wniosek Breachroad: wszystkie renderery dokumentów należy traktować jak parsery nieufnego kodu. Szkolenia bezpiecznego wytwarzania oprogramowania powinny obejmować granice parserów i sekretów, a testy aplikacji webowych i API mogą zweryfikować także funkcje podglądu, importu i konwersji treści.