Przejdź do treści
Luki i patche

Krytyczna luka zero-day w serwerze Gogs. Administratorzy muszą natychmiast zaktualizować

Krytyczna luka zero-day w serwerze Gogs umożliwia zdalne wykonanie kodu. Atakujący z podstawowym kontem może przejąć serwer i odczytać prywatne repozytoria. Administratorzy powinni natychmiast zaktualizować oprogramowanie do wersji 0.14.3.

4 min read
An abstract digital fortress made of glowing blue code blocks, with a single crack shaped like a keyhole, surrounded by dark clouds of tangled cables and faint red warning pulses.

Badacze bezpieczeństwa z firmy Rapid7 ujawnili krytyczną lukę typu zero-day w serwerze Gogs, popularnej platformie do hostowania repozytoriów kodu źródłowego. Podatność umożliwia atakującym z podstawowymi uprawnieniami użytkownika zdalne wykonanie kodu i przejęcie kontroli nad serwerem. Administratorzy powinni niezwłocznie zaktualizować swoje instalacje do wersji 0.14.3, która usuwa zagrożenie.

Czym jest Gogs i dlaczego luka jest groźna?

Gogs to lekki serwer repozytoriów Git, napisany w języku Go, często używany jako alternatywa dla GitHub Enterprise lub GitLaba. Jest popularny w małych i średnich firmach, a także w projektach open source, które chcą mieć pełną kontrolę nad swoim kodem. Według danych serwisu Shadowserver, w Internecie dostępnych jest obecnie ponad 2300 instancji Gogs, z czego najwięcej w Azji (1839) i Europie (312).

Odkryta przez badacza Jonaha Burgessa z Rapid7 luka to podatność typu argument injection w funkcji Merge(). Pozwala ona uwierzytelnionemu atakującemu bez uprawnień administracyjnych na wykonanie dowolnego kodu na serwerze. Jak wyjaśnia Burgess: „Ponieważ Gogs domyślnie włącza otwartą rejestrację i nie ogranicza tworzenia repozytoriów, nieuwierzytelniony atakujący może po prostu założyć konto i repozytorium na każdej domyślnie skonfigurowanej instancji”.

Skutki udanego ataku mogą być poważne: przejęcie serwera, odczytanie dowolnych repozytoriów (w tym prywatnych), kradzież poświadczeń, a także modyfikacja kodu źródłowego. Atakujący może też przemieszczać się po sieci wewnętrznej organizacji, co zwiększa ryzyko eskalacji ataku na inne systemy.

Podobne luki w przeszłości – wzór zaniedbań

To nie pierwszy raz, gdy w Gogs wykryto poważną podatność. Jak zauważa Burgess, obecna luka jest bardzo podobna do wcześniejszych błędów argument injection, które zespół Gogs łatał w ostatnich latach (m.in. CVE-2024-39933, CVE-2024-39932, CVE-2026-26194 i CVE-2024-39930). Różnica polega na tym, że nowa podatność dotyczy innej ścieżki kodu – funkcji Merge() – która wcześniej nie została zabezpieczona.

W grudniu 2025 roku Gogs załatał inną lukę RCE (CVE-2025-8110), która była już wykorzystywana w atakach zero-day do przejmowania setek serwerów. W styczniu 2026 roku amerykańska agencja CISA dodała ją do swojego katalogu podatności aktywnie wykorzystywanych, nakazując agencjom federalnym zabezpieczenie serwerów w ciągu trzech tygodni. „Ten typ podatności jest częstym wektorem ataku dla złośliwych cyberaktorów i stanowi znaczące ryzyko dla przedsiębiorstw federalnych” – ostrzegała wówczas CISA.

Powtarzające się problemy z bezpieczeństwem Gogs pokazują, że administratorzy nie mogą polegać wyłącznie na domyślnej konfiguracji. Otwarta rejestracja i brak limitów na tworzenie repozytoriów to cechy, które znacznie zwiększają powierzchnię ataku.

Jak się zabezpieczyć? Aktualizacja i środki ograniczające

Głównym zaleceniem jest natychmiastowa aktualizacja do wersji 0.14.3, wydanej 7 czerwca 2026 roku. Łatka została zaimplementowana w pull requeście #8301. Rapid7 podkreśla, że wszyscy użytkownicy Gogs powinni jak najszybciej zastosować poprawkę.

Dla tych, którzy nie mogą od razu zaktualizować serwera, badacze proponują tymczasowe środki ograniczające ryzyko:

  • Ograniczenie rejestracji użytkowników – ustawienie parametru DISABLE_REGISTRATION = true w pliku app.ini uniemożliwia nieznajomym zakładanie kont. To najskuteczniejsza ochrona, ponieważ exploit wymaga posiadania konta na serwerze.
  • Ograniczenie tworzenia repozytoriów – ustawienie MAX_CREATION_LIMIT = 0 blokuje użytkownikom możliwość zakładania własnych repozytoriów. Można to też zrobić indywidualnie w panelu administracyjnym. To rozwiązanie nie chroni jednak przed atakiem ze strony użytkowników, którzy mają już dostęp do istniejących repozytoriów z prawem zapisu.
  • Audyt ustawień rebase merge – wyłączenie opcji „Rebase before merging” w ustawieniach repozytorium nie jest skuteczną obroną przed złośliwym użytkownikiem, który jest właścicielem repozytorium lub ma do niego dostęp administracyjny, ponieważ może on w każdej chwili ponownie włączyć rebase.

Warto również regularnie monitorować logi serwera pod kątem podejrzanych działań oraz stosować zasadę najmniejszych uprawnień – użytkownicy powinni mieć dostęp tylko do tych repozytoriów, które są niezbędne do ich pracy.

Co dalej? Obserwujmy rozwój sytuacji

Na razie nie ma publicznych doniesień o masowym wykorzystywaniu tej luki w atakach, jednak historia CVE-2025-8110 pokazuje, że podatności w Gogs są szybko przejmowane przez cyberprzestępców. Administratorzy powinni traktować tę sytuację poważnie i nie zwlekać z aktualizacją. Warto też śledzić komunikaty zespołu Gogs oraz wpisy na blogu Rapid7, który może opublikować dodatkowe informacje o luce. W dłuższej perspektywie twórcy Gogs powinni rozważyć gruntowny przegląd kodu pod kątem podobnych błędów argument injection, aby zapobiec kolejnym incydentom.

Redakcja sekuret.pl

Redakcja sekuret.pl

AUTHOR