Gitea — trzy krytyczne podatności w lipcu 2026. Pilna aktualizacja do v1.27.1

Lipiec 2026 okazał się wyjątkowo trudnym miesiącem dla administratorów self-hosted Gitea. W ciągu czterech tygodni ujawniono trzy osobne krytyczne podatności — każda z odmiennym wektorem ataku, każda z oceną CVSS powyżej 9.0. Wszystkie naprawione zostały w wersji 1.27.1 wydanej 27 lipca 2026.

Dla instancji self-hosted — a właśnie te są najbardziej narażone — aktualizacja jest pilna, szczególnie że dla jednej z podatności opublikowany został publicznie kod PoC (proof-of-concept).

CVE-2026-60004 — RCE przez endpoint diffpatch (CVSS 9.8)

Najpoważniejsza z trojga. Podatność dotyczy endpointu diffpatch — mechanizmu Gitea odpowiedzialnego za nakładanie łatek (patches) na repozytoria z użyciem poleceń Git.

Mechanizm ataku

Gdy Gitea nakłada łatkę, tworzy tymczasowy klon repozytorium w trybie bare. Katalog główny tego klonu jest traktowany przez Gita jako katalog .git/ — co oznacza, że plik umieszczony w hooks/post-index-change staje się aktywnym hookiem Gita. Atakujący z dostępem do zapisu w repozytorium może spreparować złośliwą łatkę instalującą taki hook, a następnie wysłać tę samą łatkę dwukrotnie — za drugim razem Git wykonuje hook podczas aktualizacji indeksu, uruchamiając dowolne polecenia powłoki z uprawnieniami konta systemowego, na którym działa usługa Gitea.

Podatność sklasyfikowana jest jako CWE-94 (Improper Control of Code Generation).

Dlaczego atak jest de facto nieuwierzytelniony

Exploit formalnie wymaga uwierzytelnienia i dostępu do zapisu w repozytorium. W praktyce jednak Gitea domyślnie zezwala na otwartą rejestrację — każdy odwiedzający może założyć konto i stworzyć repozytorium bez żadnych wstępnych poświadczeń. Na niezmodyfikowanej instalacji Gitea podatność jest więc dostępna dla każdego użytkownika internetu.

Wyłączenie otwartej rejestracji ogranicza wektor ataku, ale nie jest naprawą — istniejący użytkownicy z dostępem do zapisu pozostają zagrożeniem dopóki podatność nie zostanie usunięta przez aktualizację.

Szczegóły wydania

Łatka została scalona i przeniesiona wstecznie 26 lipca. Wersja 1.27.1 ukazała się 27 lipca. Komunikat bezpieczeństwa pojawił się dzień później — 28 lipca.

Istotna pułapka: w notach wydania zmiana widnieje pod sekcją MISC jako „refactor: git patch apply", a nie pod sekcją SECURITY. Zespoły klasyfikujące priorytety aktualizacji na podstawie etykiet bezpieczeństwa mogły nie nadać tej wersji odpowiedniego priorytetu.

Gitea nie potwierdza aktywnej eksploatacji w środowiskach produkcyjnych, ale opublikowany PoC obejmuje odczyt /etc/passwd z hosta Gitea 1.27.0 — co znacząco skraca czas do pierwszych prób eksploatacji przez zewnętrznych atakujących.

Mechanizm ataku

Gdy Gitea nakłada łatkę, tworzy tymczasowy klon repozytorium w trybie bare. Katalog główny tego klonu jest traktowany przez Gita jako katalog .git/ — co oznacza, że plik umieszczony w hooks/post-index-change staje się aktywnym hookiem Gita. Atakujący z dostępem do zapisu w repozytorium może spreparować złośliwą łatkę instalującą taki hook, a następnie wysłać tę samą łatkę dwukrotnie — za drugim razem Git wykonuje hook podczas aktualizacji indeksu, uruchamiając dowolne polecenia powłoki z uprawnieniami konta systemowego, na którym działa usługa Gitea.

Podatność sklasyfikowana jest jako CWE-94 (Improper Control of Code Generation).

Dlaczego atak jest de facto nieuwierzytelniony

Exploit formalnie wymaga uwierzytelnienia i dostępu do zapisu w repozytorium. W praktyce jednak Gitea domyślnie zezwala na otwartą rejestrację — każdy odwiedzający może założyć konto i stworzyć repozytorium bez żadnych wstępnych poświadczeń. Na niezmodyfikowanej instalacji Gitea podatność jest więc dostępna dla każdego użytkownika internetu.

Wyłączenie otwartej rejestracji ogranicza wektor ataku, ale nie jest naprawą — istniejący użytkownicy z dostępem do zapisu pozostają zagrożeniem dopóki podatność nie zostanie usunięta przez aktualizację.

Szczegóły wydania

Łatka została scalona i przeniesiona wstecznie 26 lipca. Wersja 1.27.1 ukazała się 27 lipca. Komunikat bezpieczeństwa pojawił się dzień później — 28 lipca.

Istotna pułapka: w notach wydania zmiana widnieje pod sekcją MISC jako „refactor: git patch apply", a nie pod sekcją SECURITY. Zespoły klasyfikujące priorytety aktualizacji na podstawie etykiet bezpieczeństwa mogły nie nadać tej wersji odpowiedniego priorytetu.

Gitea nie potwierdza aktywnej eksploatacji w środowiskach produkcyjnych, ale opublikowany PoC obejmuje odczyt /etc/passwd z hosta Gitea 1.27.0 — co znacząco skraca czas do pierwszych prób eksploatacji przez zewnętrznych atakujących.

CVE-2026-59774 — nieuwierzytelniony odczyt plików i eskalacja do RCE (CVSS 9.1)

Druga podatność atakuje inną warstwę: endpoint renderowania znaczników (markup rendering) w repozytoriach publicznych.

Mechanizm ataku

roblem tkwi w endpoincie renderowania znaczników: weryfikuje on uprawnienia dostępu, ale nieuwierzytelniony użytkownik może je spełnić, celując w publiczne repozytorium z włączoną obsługą kodu. Atakujący może przesłać znaczniki bezpośrednio do endpointu — bez konieczności zatwierdzenia pliku, uzyskania uprawnień do zapisu ani uwierzytelnienia w instancji Gitea.

Przez ten mechanizm możliwy jest odczyt dowolnych plików na serwerze (path traversal), a przy sprzyjających warunkach — eskalacja do zdalnego wykonania kodu.

Podatność dotyczy wersji od 1.22.1 do 1.27.0. Poprawka dostępna w wersji 1.27.1.

CVE-2026-20896 — uwierzytelnienie przez nagłówek HTTP w obrazach Docker (CVSS 9.8)

Trzecia podatność dotyczy instalacji Gitea w kontenerach Docker i jest już aktywnie badana przez grupy atakujących — Sysdig odnotował pierwsze próby eksploatacji 13 dni po ujawnieniu.

Mechanizm ataku

Oficjalne obrazy Docker Gitea domyślnie dostarczane są z plikiem konfiguracyjnym app.ini zawierającym ustawienie REVERSE_PROXY_TRUSTED_PROXIES = *. Przy włączonym logowaniu przez odwrotne proxy oznacza to, że platforma ufa nagłówkowi X-WEBAUTH-USER z dowolnego adresu IP.

Efekt: nieuwierzytelniony klient internetowy może wysłać nagłówek X-WEBAUTH-USER: admin i uzyskać pełny dostęp administracyjny do instancji Gitea — bez żadnych poświadczeń.

Sysdig potwierdził aktywne próby eksploatacji tej podatności w środowiskach produkcyjnych.

Ważne: CVE-2026-20896 dotyczy instalacji Docker

Podatność wynika z domyślnej konfiguracji obrazu Docker, nie z kodu Gitea jako takiego. Instalacje binarne bez REVERSE_PROXY_TRUSTED_PROXIES = * w konfiguracji nie są podatne. Użytkownicy oficjalnych obrazów Docker powinni bezwzględnie zweryfikować zawartość app.ini.

Co zrobić — priorytetowe działania

1. Zaktualizuj do Gitea 1.27.1

Wszystkie trzy podatności są naprawione w wersji 1.27.1. To jedyna skuteczna naprawa.

Weryfikacja aktualnej wersji:

bash

gitea --version
# lub przez API
curl -s http://localhost:3000/api/swagger | grep -i version

2. Zweryfikuj konfigurację Docker

Jeśli używasz oficjalnych obrazów Docker Gitea, sprawdź app.ini:

bash

grep REVERSE_PROXY_TRUSTED_PROXIES /path/to/gitea/app.ini

Jeśli wartość to * — zmień ją na konkretny adres IP lub zakres adresów zaufanego reverse proxy przed następnym restartem kontenera.

3. Wyłącz otwartą rejestrację (środek tymczasowy)

Jeśli natychmiastowa aktualizacja nie jest możliwa, wyłączenie otwartej rejestracji ogranicza wektor ataku dla CVE-2026-60004 — ale nie eliminuje go dla istniejących użytkowników z dostępem do zapisu.

W app.ini:

ini

[service]
DISABLE_REGISTRATION = true

4. Monitoruj logi pod kątem anomalii

Dla CVE-2026-60004 — szukaj podwójnych żądań do endpointu diffpatch z tym samym identyfikatorem łatki w krótkim oknie czasowym.

Dla CVE-2026-20896 — szukaj żądań z nagłówkiem X-WEBAUTH-USER przychodzących spoza zaufanej sieci reverse proxy.

5. Rotacja INTERNAL_TOKEN i poświadczenia

Jeśli podejrzewasz, że instancja mogła być narażona — zrotuj wartość INTERNAL_TOKEN w app.ini oraz wszelkie poświadczenia przechowywane w plikach konfiguracyjnych Gitea (klucze OAuth, tokeny dostępu do bazy danych, zmienne środowiskowe).

Kontekst: dlaczego instancje self-hosted Gitea są szczególnie narażone

Gitea jest popularna właśnie dlatego, że jest lekka i prosta do wdrożenia — co sprawia, że trafia do środowisk poza centralnym IT: wdrożona przez indywidualny zespół inżynierski, przez kontraktora, na osobnej instancji chmurowej dla jednego projektu, wewnątrz stosu narzędziowego który nigdy nie był formalnie zinwentaryzowany.

Instancje, które mają największe znaczenie dla CVE-2026-60004, to często te, o których nikt nie pamięta. Dwie cechy konfiguracyjne podnoszą ryzyko: otwarta rejestracja (domyślna w standardowej instalacji) i publiczne repozytoria z włączoną jednostką kodu (CVE-2026-59774).

Gitea Cloud nie wymaga żadnych działań — instancje zostały zaktualizowane automatycznie 27 lipca.

Podsumowanie

Trzy podatności, jeden komunikat: zaktualizuj do wersji 1.27.1 natychmiast. Jeśli używasz obrazów Docker — zweryfikuj REVERSE_PROXY_TRUSTED_PROXIES w app.ini niezależnie od wersji.