GitLab CVE-2026-110264: krytyczne RCE bez logowania i pilna aktualizacja

GitLab wydał krytyczne poprawki dla CVE-2026-110264, podatności umożliwiającej w określonych warunkach zdalne wykonanie kodu na serwerze GitLab. Atak nie wymaga uwierzytelnienia ani działania użytkownika. Producent ocenił błąd na 10.0 w CVSS 3.1 i zaleca natychmiastową aktualizację wszystkich podatnych instalacji self-managed.

Problem dotyczy kompilacji specjalnie przygotowanego wyrażenia regularnego i błędu przepełnienia liczby całkowitej. Dla firmy najważniejsza nie jest jednak klasa błędu, lecz rola GitLaba: serwer zwykle przechowuje kod, sekrety CI/CD, artefakty, klucze wdrożeniowe i ścieżki dostępu do produkcji. Wykonanie kodu na tej platformie może więc stać się początkiem incydentu obejmującego cały łańcuch dostarczania oprogramowania.

Które wersje są podatne

GitLab wymienia następujące zakresy CE i EE:

• od 7.0 do wersji wcześniejszych niż 18.11.13;
• 19.0 przed 19.0.10;
• 19.1 przed 19.1.9;
• 19.2 przed 19.2.9;
• 19.3 przed 19.3.6;
• 19.4 przed 19.4.3;
• 19.5 przed 19.5.1.

Poprawki są dostępne w 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 i 19.5.1. Producent wykonał dodatkowe backporty poza standardowymi gałęziami, co ułatwia szybką reakcję organizacjom, które nie mogą natychmiast przejść na najnowszą linię.

GitLab.com już działa na wersji poprawionej. GitLab podaje też, że klienci GitLab Dedicated na 19.3.5-internal0 i 19.4.2-internal0 lub nowszych mają poprawkę i nie muszą podejmować działań. Pilne zadanie dotyczy przede wszystkim właścicieli GitLab Self-Managed.

Dlaczego ta podatność otrzymuje najwyższy priorytet

Wektor CVSS producenta wskazuje atak przez sieć, niską złożoność, brak wymaganych uprawnień i brak interakcji użytkownika. Potencjalny wpływ na poufność, integralność i dostępność jest wysoki.

Ocena 10.0 nie oznacza automatycznie, że każda instancja została zaatakowana. W chwili publikacji komunikatu producent nie potwierdził wykorzystania podatności na szeroką skalę. Nie należy jednak czekać na taki dowód: zewnętrznie dostępny GitLab, który mieści kod i procesy wdrożeniowe, ma bardzo wysoki wpływ biznesowy, a poprawka jest dostępna.

Wniosek Breachroad: publicznie dostępne instalacje i systemy połączone z produkcyjnymi runnerami powinny znaleźć się na początku kolejki. Instancji wewnętrznej nie można uznać za bezpieczną tylko dlatego, że nie ma publicznego adresu — dostęp przez VPN, konta partnerów, stacje pracowników i inne przejęte systemy nadal tworzy ścieżkę ataku.

Plan działania na dziś

1. Potwierdź typ usługi i wersję

Rozdziel GitLab.com, Dedicated i Self-Managed. Dla własnych instalacji odczytaj wersję z wiarygodnego źródła oraz sprawdź wszystkie węzły, kontenery i środowiska odtworzeniowe. Inwentarz obejmujący tylko główny adres może pominąć staging, zapasowy węzeł lub starą instancję działającą dla jednego zespołu.

2. Aktualizuj do poprawionej wersji

Wybierz poprawione wydanie zgodne z używaną linią i dokumentacją GitLaba. Przed zmianą potwierdź kopię zapasową, wymagania migracji oraz plan przywrócenia działania. Nie odkładaj instalacji tylko po to, aby od razu wykonać większy upgrade funkcjonalny — krytyczna poprawka ma osobny priorytet.

3. Ogranicz ekspozycję do czasu zakończenia zmiany

Jeżeli aktualizacja wymaga okna serwisowego, ogranicz dostęp przez reverse proxy, VPN, allowlistę lub kontrolę sieciową, o ile nie odcina to niezbędnych procesów. Jest to mitygacja tymczasowa, nie zamiennik poprawki.

4. Użyj detekcji producenta

GitLab opublikował dwie reguły dla instalacji self-managed: Onigmo native worker crash i Org mode render error burst. Ich trafienie powinno uruchomić analizę incydentu. Brak alarmu nie stanowi jednak dowodu bezpieczeństwa — detekcja próby nie jest tym samym co gwarancja wykrycia skutecznego wykonania kodu.

5. Sprawdź skutki, nie tylko sygnał wejściowy

Przejrzyj nowe konta i klucze, zmiany ról, ustawienia runnerów, webhooki, tokeny, pipeline’y, chronione gałęzie i nietypowe operacje administracyjne. Jeżeli pojawia się podejrzenie wykonania kodu, traktuj GitLaba jako system potencjalnie przejęty: zabezpiecz logi, izoluj, sprawdź integralność i zaplanuj rotację poświadczeń dostępnych dla platformy.

Co powinien wiedzieć zarząd i właściciel procesu

Komunikat „GitLab został zaktualizowany” nie zamyka ryzyka biznesowego. Właściciel powinien otrzymać cztery odpowiedzi:

1. Ile instancji było w podatnym zakresie i które były dostępne z zewnątrz?
2. Kiedy każda z nich otrzymała poprawkę?
3. Czy logi obejmują cały czas od publikacji do aktualizacji?
4. Czy znaleziono oznaki próby lub skutków kompromitacji?

Warto też sprawdzić, czy runner ma stałe poświadczenia do produkcji i czy sekret jednego projektu może zostać użyty poza jego zakresem. Krytyczna podatność platformy deweloperskiej często ujawnia wcześniejsze zaniedbania w segmentacji i zarządzaniu sekretami.

Jak nie powtórzyć problemu przy następnym krytycznym CVE

Proces zarządzania podatnościami powinien łączyć informację producenta z inwentarzem aktywów i wpływem biznesowym. Minimalny standard to właściciel każdej instancji, automatyczne raportowanie wersji, subskrypcja biuletynów, zdefiniowane okno dla krytycznych poprawek oraz sprawdzony tryb awaryjny.

Ważne jest również przechowywanie logów poza samym GitLabem. Jeżeli system zostanie przejęty, lokalne dzienniki mogą zostać zmodyfikowane lub usunięte. Centralny SIEM, logi reverse proxy i telemetria EDR tworzą niezależne źródła dowodowe.

Fakty źródłowe i wnioski Breachroad

GitLab potwierdza charakter RCE, wektor bez uwierzytelnienia, ocenę 10.0, zakres podatnych wersji, wydania naprawcze oraz dostępność dwóch detekcji. Producent potwierdza również stan GitLab.com i wskazanych wersji Dedicated.

Priorytetyzacja według ekspozycji, zakres przeglądu skutków i pytania raportowe są rekomendacjami Breachroad. Więcej kontekstu daje proces zarządzania podatnościami i przewodnik po bezpieczeństwie pipeline’ów CI/CD. Zespoły deweloperskie, administratorzy i właściciele usług mogą przećwiczyć wspólną reakcję podczas szkoleń cyberbezpieczeństwa dla firm, a odporność platformy sprawdzić przez audyt bezpieczeństwa IT.

Źródło pierwotne: GitLab — Critical Patch Release 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 i 18.11.13.