GitLab łata krytyczną lukę RCE

Krytyczna luka w GitLabie wymaga pilnej reakcji

GitLab opublikował poprawki bezpieczeństwa dla wydań Community Edition i Enterprise Edition, zamykające krytyczną podatność CVE-2026-110264. Błąd ma charakter integer overflow w kompilatorze wyrażeń regularnych i w określonych warunkach może prowadzić do zdalnego wykonania kodu na serwerze GitLab bez uwierzytelnienia.

To szczególnie poważna informacja dla administratorów instancji self-hosted, bo problem dotyczy bardzo szerokiego zakresu wersji — od GitLab 7.0, czyli od wydania z 2014 roku.

Co dokładnie jest zagrożone

Według opisu luki atakujący, który nie ma konta w systemie, może wykorzystać specjalnie przygotowane wyrażenie regularne. Źródłem problemu jest komponent związany z silnikiem regexów używanym przez Ruby, a GitLab dostarcza własne pakiety Ruby w obrazach Omnibus i CNG. Właśnie dlatego podatność sięga tak daleko wstecz.

GitLab nie ujawnił pełnych warunków uruchomienia ataku, ale zaznaczył, że ryzyko jest na tyle poważne, iż należy zaktualizować system natychmiast.

To nie jedyna poprawka w tym miesiącu

Sytuację komplikuje fakt, że osoby, które wdrożyły poprawki z 12 października, nie są jeszcze bezpieczne. Wtedy GitLab załatał inną krytyczną lukę, CVE-2026-97229, również umożliwiającą atak bez logowania. Wydania przygotowane przy tamtej okazji — 19.2.8, 19.3.5 i 19.4.2 — okazały się podatne na nowo ujawniony błąd.

W praktyce oznacza to, że część administratorów musi wykonać kolejną aktualizację krótko po poprzedniej.

Jakie wersje trzeba zainstalować

GitLab przygotował poprawione wydania dla aktualnie wspieranych gałęzi, a także dla starszych linii, do których cofnięto poprawkę:

• 19.5 → 19.5.1
• 19.4 → 19.4.3
• 19.3 → 19.3.6
• 19.2 → 19.2.9
• 19.1 → 19.1.9
• 19.0 → 19.0.10
• 7.0 do 18.11 → 18.11.13

Łącznie nowe wydania usuwają 12 podatności, w tym dwie o wysokiej wadze: CVE-2026-15723 oraz CVE-2026-112212.

Na co trzeba uważać przy aktualizacji

Administratorzy powinni zaplanować serwisowe okno na wdrożenie poprawek. W przypadku wydań 19.4.3 i 19.3.6 aktualizacja obejmuje migracje bazy danych, które mogą wydłużyć czas niedostępności usługi. Na instancjach jednowęzłowych GitLab uruchomi się ponownie dopiero po zakończeniu tych operacji.

Czy luka jest już wykorzystywana

Na ten moment nie ma informacji o aktywnym wykorzystaniu podatności. Nie pojawiła się też w katalogu KEV prowadzonym przez amerykańską agencję CISA. Nie zmienia to jednak faktu, że skala problemu i zakres zagrożonych wersji wymagają pilnej reakcji.

Co powinni zrobić administratorzy

Najważniejsze działania to:

1. sprawdzić aktualnie używaną gałąź GitLab,
2. zaplanować aktualizację do właściwej poprawionej wersji,
3. uwzględnić możliwą przerwę serwisową,
4. zweryfikować, czy instancja była wcześniej aktualizowana po 12 października.

W przypadku GitLaba to jedna z tych sytuacji, w których zwlekanie może oznaczać pozostawienie całej platformy z otwartą drogą do przejęcia serwera.