Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
W platformie Gitea ujawniono krytyczną podatność typu remote code execution, która może doprowadzić do wykonania poleceń systemowych po stronie serwera. Problem wynika z niebezpiecznej interakcji między mechanizmem aplikowania łatek a zachowaniem narzędzia Git w określonych warunkach przetwarzania patchy.
Luka została oznaczona jako CVE-2026-60004 i oceniona na 9.8 w skali CVSS, co wskazuje na bardzo wysoki poziom ryzyka. Choć atak wymaga uwierzytelnienia oraz prawa zapisu do repozytorium, w praktyce warunek ten może być łatwy do spełnienia na publicznie dostępnych instancjach z otwartą rejestracją użytkowników.
W skrócie
- Podatność dotyczy Gitea od wersji 1.17 do wydań wcześniejszych niż 1.27.1.
- Umożliwia wykonanie kodu na serwerze z uprawnieniami konta systemowego usługi Gitea.
- Wektor ataku opiera się na złośliwej łatce i mechanizmie hooków Git.
- Do skutecznego wykorzystania wymagane jest konto z prawem zapisu do repozytorium.
- Producent usunął problem w wersji 1.27.1.
Kontekst / historia
Gitea jest szeroko wykorzystywaną, samoobsługową platformą do hostowania repozytoriów Git, wdrażaną zarówno w środowiskach deweloperskich, jak i w infrastrukturze CI/CD oraz systemach wewnętrznych organizacji. Z tego powodu każda podatność wpływająca na bezpieczeństwo repozytoriów lub samego serwera ma istotne znaczenie operacyjne.
Opisywany problem dotyczy ścieżki API odpowiedzialnej za aplikowanie łatek do repozytorium. Luka została publicznie ujawniona pod koniec lipca 2026 roku, a wraz z pojawieniem się informacji o błędzie opublikowano także publiczny proof-of-concept. To istotnie zwiększa ryzyko szybkiej adaptacji exploita przez mniej zaawansowanych atakujących.
W momencie ujawnienia nie potwierdzono aktywnego wykorzystywania podatności w rzeczywistych atakach, jednak sam charakter błędu oraz dostępność kodu demonstracyjnego sprawiają, że organizacje korzystające z Gitea powinny potraktować temat priorytetowo.
Analiza techniczna
Sedno problemu tkwi w sposobie, w jaki Gitea przetwarza przekazaną łatkę we współdzielonym, tymczasowym klonie typu bare. W podatnych wersjach wykorzystywane jest wywołanie git apply z parametrami związanymi z aktualizacją indeksu i obsługą danych binarnych. W określonych środowiskach możliwe jest również użycie ścieżki awaryjnej z trójstronnym scalaniem.
Scenariusz ataku polega na dostarczeniu tej samej złośliwej łatki dwukrotnie, co prowadzi do kolizji typu add/add. W takiej sytuacji mechanizm fallbacku może doprowadzić do utworzenia pliku w lokalizacji odpowiadającej katalogowi $GIT_DIR repozytorium bare. Jeśli spreparowany plik trafi pod ścieżkę hooks/post-index-change, staje się aktywnym hookiem Git.
To kluczowy moment całego łańcucha nadużycia. Git może uruchomić taki plik jako wykonywalny skrypt podczas aktualizacji indeksu, co skutkuje wykonaniem poleceń systemowych na serwerze. W praktyce atakujący uzyskuje możliwość działania z uprawnieniami użytkownika systemowego, pod którym uruchomiona jest usługa Gitea.
Publicznie opisany proof-of-concept pokazuje, że do przeprowadzenia ataku może wystarczyć zwykłe konto użytkownika, utworzenie repozytorium i dwukrotne przesłanie złośliwej łatki. Co istotne, odzyskanie wyników wykonanych poleceń nie musi wymagać klasycznego połączenia zwrotnego, ponieważ dane mogą zostać zapisane w obiektach Git i następnie pobrane przez HTTP po uwierzytelnieniu.
Nie jest to więc całkowicie anonimowe RCE, ale wymagania ataku pozostają relatywnie niskie. Jeśli instancja Gitea pozwala na samodzielną rejestrację nowych kont i nie ogranicza nadawania praw zapisu, ryzyko praktycznego wykorzystania błędu znacząco rośnie.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją podatności jest wykonanie kodu w kontekście konta usługi Gitea. Dalszy zakres szkód zależy od izolacji instancji, poziomu segmentacji sieci, modelu uprawnień oraz tego, jakie zasoby są dostępne z poziomu procesu aplikacji.
W wielu środowiskach skuteczna kompromitacja może oznaczać dostęp do sekretów aplikacyjnych, zmiennych środowiskowych, danych uwierzytelniających do baz danych, tokenów OAuth, zamontowanych zasobów oraz usług wewnętrznych osiągalnych z hosta. Dla organizacji traktujących serwer Git jako centralny element procesu wytwarzania oprogramowania oznacza to ryzyko znacznie wykraczające poza samą platformę repozytoryjną.
Potencjalny wpływ obejmuje również manipulację kodem źródłowym, webhookami, procesami CI/CD, artefaktami buildów i mechanizmami wdrożeniowymi. Innymi słowy, pojedyncza luka w systemie zarządzania repozytoriami może stać się punktem wyjścia do ataku na cały software supply chain.
Dodatkowym problemem jest możliwość przeoczenia poprawki przez administratorów, którzy śledzą wyłącznie ogólne informacje o wydaniach. Jeżeli organizacja nie monitoruje komunikatów bezpieczeństwa projektu, mogła nie nadać aktualizacji odpowiedniego priorytetu.
Rekomendacje
Najważniejszym działaniem jest natychmiastowa aktualizacja Gitea do wersji 1.27.1 lub nowszej. W środowiskach produkcyjnych, szczególnie tych publicznie dostępnych, poprawka powinna zostać wdrożona w trybie pilnym.
Do czasu pełnej aktualizacji warto ograniczyć powierzchnię ataku i zweryfikować konfigurację instancji. Pomocne będą zwłaszcza następujące działania:
- wyłączenie otwartej rejestracji nowych użytkowników,
- przegląd kont posiadających prawo zapisu do repozytoriów,
- ograniczenie możliwości tworzenia nowych repozytoriów przez niezweryfikowane konta,
- monitorowanie logów API pod kątem nietypowych wywołań endpointu diffpatch,
- sprawdzenie środowiska tymczasowego serwera pod kątem podejrzanych hooków Git i artefaktów pośrednich,
- przegląd sekretów dostępnych dla procesu Gitea i ich rotacja w razie podejrzenia naruszenia,
- weryfikacja segmentacji sieciowej hosta w celu ograniczenia ruchu lateralnego,
- ocena, czy konto systemowe Gitea nie ma nadmiernych uprawnień do plików, baz danych i zasobów współdzielonych.
W bardziej dojrzałych organizacjach warto również uruchomić działania typu threat hunting, obejmujące analizę nietypowych zmian w repozytoriach, gałęziach technicznych oraz obiektach Git, które mogły zostać wykorzystane do ukrycia wyników działania exploita.
Podsumowanie
CVE-2026-60004 pokazuje, jak pozornie ograniczone uprawnienia aplikacyjne mogą przełożyć się na pełnoprawne wykonanie kodu na serwerze. Choć atak wymaga konta z prawem zapisu, jego praktyczna wykonalność pozostaje wysoka na publicznych lub słabiej kontrolowanych wdrożeniach Gitea.
Z uwagi na wysoką ocenę CVSS, dostępność publicznego proof-of-concept i możliwy wpływ na łańcuch dostaw oprogramowania, aktualizacja do wersji 1.27.1 powinna być traktowana jako działanie o najwyższym priorytecie. Dla wielu organizacji będzie to nie tylko kwestia ochrony kodu źródłowego, ale także zabezpieczenia całego zaplecza DevSecOps.
Źródła
- New Gitea RCE Lets Repository Writers Plant a Git Hook to Run Shell Commands — https://thehackernews.com/2026/07/new-gitea-rce-lets-repository-writers.html
- Release v1.27.1 · go-gitea/gitea — https://github.com/go-gitea/gitea/releases/tag/v1.27.1
- Gitea Documentation — https://docs.gitea.com/
- Git Hooks Documentation — https://git-scm.com/docs/githooks