Gitea łata krytyczną lukę RCE umożliwiającą wykonanie kodu przez Git hook

Gitea to otwartoźródłowa, samodzielnie hostowana platforma Git. Została napisana w języku Go, a jej repozytorium na GitHubie ma prawie 60 tysięcy gwiazdek.

TLDR:

• Gitea usunęła krytyczną podatność RCE (CVE-2026-60004, CVSS 9.8), która pozwala użytkownikowi z prawem zapisu do repozytorium wykonać dowolny kod na serwerze.
• Luka wykorzystuje sposób działania endpointu diffpatch oraz możliwość utworzenia aktywnego Git hooka podczas git apply -3.
• Domyślna konfiguracja Gitea umożliwia założenie konta i własnego repozytorium, dzięki czemu atak nie wymaga wcześniejszego dostępu administracyjnego.
• Jedynym pełnym rozwiązaniem jest aktualizacja do Gitea w wersji 1.27.1 lub nowszej; wyłączenie rejestracji jedynie ogranicza powierzchnię ataku.

Pod koniec lipca załatano w niej krytyczną podatność, która umożliwiała zdalne wykonanie kodu. Każdy użytkownik instancji przy domyślnych uprawnieniach może przekształcić zawartość przesłanego patcha w aktywny Git hook i wykonywać polecenia powłoki jako konto usługi Gitea.

Luka otrzymała numer CVE-2026-60004 i ocenę 9.8 w skali CVSS. Dotyczy wersji od 1.17 do 1.27.0 (bez 1.27.1) i została naprawiona w wersji 1.27.1. Chociaż podatne API wymaga uwierzytelnienia oraz uprawnień do zapisu w repozytorium, domyślna konfiguracja umożliwia rejestrację nowych użytkowników. Potencjalny atakujący może więc utworzyć konto i repozytorium, a następnie wykorzystać podatność do przeprowadzenia ataku.

Lukę zgłosił badacz bezpieczeństwa posługujący się pseudonimem NightRang3r. Biuletyn bezpieczeństwa opublikowano 28 lipca 2026 r.

Problematyczny jest endpoint /api/v1/repos/{owner}/{repo}/diffpatch. Dostarczany w zapytaniu patch aplikowany jest w tymczasowym repozytorium typu bare. Oznacza to, że jego katalog główny jest jednocześnie katalogiem $GIT_DIR, w którym znajdują się m.in. katalogi objects, refs i hooks.

Podatne wersje wywołują git apply z opcjami –index, –recount, –cached i –binary, dodając opcję awaryjną -3 (o ile serwer korzysta z Git w wersji 2.32 lub nowszej). Atakujący przesyła ten sam patch dwukrotnie, aby utworzyć kolizję add/add. Następnie mechanizm trójstronnego scalania (-3) wykonuje checkout ścieżki znajdującej się w indeksie. W rezultacie wykonywalny plik umieszczony w hooks/post-index-change trafia do katalogu hooków Git i staje się aktywny. Git uruchamia go podczas aktualizacji indeksu.

W ramach PoC wykorzystano zwykłe konto użytkownika i utworzono prywatne repozytorium, dwukrotnie wysłano złośliwy patch i pobrano wynik polecenia. Wykorzystanie podatności daje atakującemu uprawnienia konta, z którego uruchomiona jest Gitea na serwerze. Może to doprowadzić do ujawnienia konfiguracji aplikacji i środowiska, treści repozytoriów, zawartości bazy danych, a także – o ile instancja z nich korzysta – poświadczeń OAuth.

Podatność załatano w wersji 1.27.1. Administratorom instancji Gitea polecamy pilną aktualizację do tej właśnie wersji (lub najnowszej, jeśli przeoczyliście tę aktualizację ;-))

Gitea poinformowała, że instancje w ramach usługi Cloud (czyli zarządzane przez twórców narzędzia) zostaną zaktualizowane automatycznie. W opublikowanym biuletynie bezpieczeństwa nie wspomniano o przypadkach wykorzystania podatności, ale zamieszczono proof-of-concept (PoC) demonstrujący problem.

Tymczasową poprawką może być wyłączenie możliwości samodzielnego zakładania nowych kont na instancji. Aby to zrobić, należy skorzystać z opcji DISABLE_REGISTRATION, a szczegóły zawarto w dokumentacji. Nie likwiduje to jednak podatności ani nie chroni przed wykorzystaniem jej przez istniejących już użytkowników posiadających uprawnienia do zapisu w repozytorium. Przy czym uprawnienia te w większości konfiguracji nie stanowią żadnej bariery – wystarczy stworzyć własne repozytorium, by mieć uprawnienia do zapisu w nim.

Aby zminimalizować skutki podobnych podatności w różnych otwartoźródłowych narzędziach (które na pewno będą się pojawiać – zarówno narzędzia, jak i luki w nich) polecamy dbać o regularne aktualizacje, a wszelkie wewnętrzne usługi (np. tylko dla osób w organizacji) chować za VPN-em.

Źródła:

• thehackernews.com
• github.com

~Tymoteusz Jóźwiak