GitLab w pakiecie datowanym na 12 października 2026 r. usuwa krytyczną lukę CI/CD, która w określonych warunkach mogła pozwolić na wykonanie kodu na serwerze bez logowania. Producent zaleca pilną aktualizację instalacji zarządzanych samodzielnie i wskazuje wersje 19.4.2, 19.3.5 oraz 19.2.8. Dla administratora i właściciela procesu wydawania oprogramowania pierwszą decyzją jest ustalenie, których własnych instancji dotyczy ostrzeżenie i kto potwierdzi wynik poprawki.

Czy informacja „zaktualizowaliśmy GitLab” pozwala ustalić, która wersja faktycznie działa na serwerze? Przy tym ostrzeżeniu poprośmy o pełny numer, bo komunikat CERT-EU wymienia jeszcze 19.3.4, podczas gdy producent wskazuje już 19.3.5. Proponujemy potraktować tę różnicę jako sprawdzian własnej procedury. W zgłoszeniu zmiany zapiszmy model hostingu, odczytaną wersję, ekspozycję instancji oraz osobę odpowiedzialną za odbiór prac. Jeśli któregoś pola nie da się uzupełnić, przypiszmy jego wyjaśnienie administratorowi. Sam status zadania nie odpowiada na pytanie o wersję uruchomionego GitLab. Odpowiedź powinna wynikać z kontroli konkretnej instalacji, a plan aktualizacji powinien od początku określać sposób zebrania takiego potwierdzenia.

GitLab opisuje wykonanie kodu bez uwierzytelnienia

Według komunikatu GitLab podatność CVE-2026-97229 otrzymała ocenę CVSS 10.0. Odpowiednio przygotowane wyrażenie regularne w konfiguracji CI/CD mogło w określonych warunkach umożliwić wykonanie kodu na serwerze przez nieuwierzytelnionego użytkownika. Zachowajmy zastrzeżenie producenta dotyczące warunków: opis możliwości ataku nie potwierdza przejęcia żadnego konkretnego serwera.

Brak wymogu logowania odróżnia ten pakiet od poprzedniego ostrzeżenia dotyczącego GitLab. Materiał z 25 września dotyczył komunikatu CERT 178/2026, jedenastu luk i uwierzytelnionego atakującego. W nowym przeglądzie nie zakładajmy więc, że CVE-2026-97229 też wymaga konta. Dla administratora punktem odniesienia powinien być opis tej konkretnej podatności oraz odpowiadający jej komunikat o poprawkach.

CVSS 10.0 nie określa liczby zaobserwowanych incydentów. Przywołane informacje nie ustalają daty odkrycia luki ani początku ewentualnego wykorzystania. Nie dają też podstaw do twierdzeń o masowych atakach, przejęciu wskazanych serwerów lub wycieku sekretów. Brak takich informacji nie dowodzi nieistnienia ataków; pozostawia ich występowanie i skalę nieustalone. W notatce o własnym GitLab oddzielmy zatem ocenę podatności od wiedzy o stanie instalacji.

Wersję 19.3.4 trzeba porównać z komunikatem producenta

Jak podaje GitLab, wersja 19.3.4 miała błąd stron merge request przy włączonej integracji Ona. Poprawiono go w 19.3.5. Bieżący komunikat producenta wymienia 19.4.2, 19.3.5 i 19.2.8, natomiast ostrzeżenie CERT-EU 2026-016 nadal wskazuje 19.3.4. Przy wyborze docelowej wersji oprzyjmy się na aktualnym komunikacie GitLab. Jeśli plan prac zawiera 19.3.4, wróćmy do jego weryfikacji przed zatwierdzeniem zmiany.

Numer wersji w zgłoszeniu powinien odpowiadać wersji, którą można sprawdzić na działającym serwerze.

Producent datuje pakiet na 12 października, bez godziny. Nie ustalono godziny zmiany dokumentacji z 19.3.4 na 19.3.5. Rozbieżność numerów potraktujmy jako powód ponownej kontroli celu aktualizacji, bez przypisywania administratorom zaniedbań. Proponowana kontrola polega na porównaniu zapisanego planu z komunikatem producenta i późniejszym odczytem wersji po wykonaniu prac.

Według GitLab usługa GitLab.com jest już poprawiona, a klienci GitLab Dedicated nie muszą podejmować działań. Zalecenie pilnej aktualizacji dotyczy instalacji zarządzanych samodzielnie. Dlatego przy każdej pozycji w firmowym wykazie ustalmy model hostingu. Informacji o poprawieniu GitLab.com nie traktujmy jako potwierdzenia stanu własnego serwera, a zadania aktualizacji przypisujmy dopiero po rozstrzygnięciu, kto zarządza daną instalacją.

Właściciel CI/CD powinien odebrać wynik zmiany

CERT-EU zaleca rozpoczęcie aktualizacji od instancji dostępnych z internetu. Proponujemy przełożyć tę kolejność na plan prac: przy własnym GitLab zapiszmy ustaloną ekspozycję, właściciela zmiany i proponowane okno aktualizacji. Gdy dostępność instancji pozostaje nieznana, oznaczmy brak danych i osobę odpowiedzialną za sprawdzenie. Nie kwalifikujmy jej automatycznie jako wewnętrznej.

Właściciel procesu CI/CD powinien uzgodnić z administratorem, jakie potwierdzenie pozwoli odebrać zmianę. Nasza propozycja obejmuje odczyt wersji po aktualizacji, kontrolny pipeline oraz sprawdzenie stron merge request przy używanej integracji. To zalecenie redakcyjne dotyczące odbioru, a nie opis testów przeprowadzonych przez producenta. Błąd związany z Ona uzasadnia uwzględnienie używanej integracji w przygotowaniu kontroli działania GitLab.

Właściciel CI/CD odpowiada także za potwierdzenie wyniku poprawki.

Koszt prac i długość okna aktualizacji GitLab musi ustalić organizacja. Ocena CVSS nie wyznacza tych wartości ani nie zastępuje uzgodnienia zależności z zespołem wydającym oprogramowanie. Poprośmy o plan zawierający odpowiedzialność za wykonanie i sprawdzenie zmiany. W zapisie odbioru rozdzielmy odczytaną wersję od wyniku kontrolnego pipeline’u: każdy z tych elementów odpowiada na inne pytanie o zakończone prace.

Polski zespół powinien sprawdzić własną instalację

Dla administratora w Polsce zalecenie CERT-EU daje konkretną kolejność przeglądu: najpierw własne instancje GitLab dostępne z internetu. Przywołane fakty nie wskazują polskiej ofiary ani nie ustanawiają lokalnego obowiązku prawnego. Proponowane działania wynikają z ostrzeżenia technicznego i mają ustalić stan własnego środowiska.

Do rozmowy o kolejce prac można dołączyć materiał GTIG: priorytety napraw przy dużej liczbie podatności. Przy GitLab zacznijmy jednak od odpowiedzi dotyczących własnej instalacji: modelu hostingu, wersji i ekspozycji. Osobie zatwierdzającej okno aktualizacji przekażmy także listę zależności wymagających rozstrzygnięcia. Poniższe trzy kroki służą przygotowaniu decyzji; nazwa stałej rubryki nie jest zaleceniem czekania do poniedziałku z reakcją na pilny komunikat.

Co z tym zrobić w poniedziałek

  1. Sporządź początkowy wykaz GitLab. W 30 minut zbierz dostępne informacje o własnych instancjach, modelu hostingu, wersjach i ekspozycji. Zapisz niewiadome i przypisz je do administratorów. Rezultatem ma być lista do dalszej weryfikacji, z jawnymi brakami.
  2. Przygotuj propozycję aktualizacji. W 30 minut porównaj listę z bieżącym komunikatem GitLab i zapisz propozycję okna, właściciela oraz zależności. Zacznij od wpisów wskazujących 19.3.4. Ten krok obejmuje przygotowanie prac, bez obietnicy wykonania aktualizacji w pół godziny.
  3. Zapisz kryteria odbioru. W 30 minut przygotuj wymagania: odczyt wersji GitLab po zmianie, kontrolny pipeline i sprawdzenie MR przy używanej integracji. Wskaż, kto zbierze wyniki i przekaże je właścicielowi CI/CD do potwierdzenia.

Zamknięcie zadania aktualizacji GitLab uzależnijmy od sprawdzonego wyniku na wskazanej instancji. Właściciel CI/CD powinien móc powiązać odczytaną wersję z planem zmiany i wynikami kontroli działania. Jeśli potwierdzenia brakuje, pozostawmy konkretny punkt odbioru otwarty wraz z odpowiedzialną osobą.

Źródła

Redakcja cyberinsight.pl.