Łatanie GitLab CVE-2026-110264: inwentaryzacja, wersje z poprawką, migracje i detekcja

Ten runbook dotyczy wyłącznie self-managed GitLab. GitLab.com i GitLab Dedicated są już załatane. Po pomoc w zaplanowaniu aktualizacji z niewspieranej wersji zobacz Migrację do chmury lub umów konsultację.

Objawy

Nie ma błędu, na który można czekać. Luka jest cicha: udana próba niekoniecznie wywołuje awarię serwera. O podatności decyduje wersja, a nie wpis w logu.

• Dowolna instancja self-managed GitLab CE/EE na wersji od 7.0 aż do poprawki z 21 października jest podatna.
• Instancje załatane 12 października (19.4.2, 19.3.5, 19.2.8) są nadal podatne na tę lukę. Tamta poprawka naprawiała inny błąd (CVE-2026-97229).
• GitLab.com i GitLab Dedicated (na załatanych buildach wewnętrznych) nie są dotknięte.

Krok 1: zinwentaryzuj każdą instancję

Wypisz każdy serwer GitLab, który prowadzisz, w tym te łatwe do przeoczenia:

• Repliki Geo (tylko do odczytu)
• Instancje staging, QA i demo
• Serwery zapasowe disaster-recovery
• Stare lub „tymczasowe” instancje, których nikt już nie pilnuje

Zapomniana instancja na podatnej wersji to pełne, nieuwierzytelnione wejście RCE. Potraktuj inwentaryzację jako właściwy rezultat tego kroku.

Krok 2: sprawdź wersję serwowaną przez każdą instancję

Sprawdź, co aplikacja faktycznie uruchamia, per metoda instalacji:

# Pakiet Linux (Omnibus)
sudo cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

# Docker
docker exec <container> cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

# Helm chart: odczytaj kolumnę APP VERSION, nie wersję chartu
helm list --all-namespaces | grep -i gitlab

# API (dowolna instalacja) - wymaga tokenu
curl --header "PRIVATE-TOKEN: <twoj-token>" \
  "https://gitlab.example.com/api/v4/version"

Zalogowani użytkownicy mogą też odczytać wersję pod /help w przeglądarce. Dla Helm chart: jeśli ustawiłeś global.gitlabVersion, ta wartość ma pierwszeństwo przed wersją aplikacji z chartu.

Krok 3: wybierz wersję z poprawką dla swojej gałęzi

Porównaj działającą wersję z tabelą i zaktualizuj w obrębie bieżącej gałęzi minor. Aktualizacja na poziomie patcha (np. 19.4.1 do 19.4.3) nie wymaga dodatkowych przystanków.

Wydania 19.2, 19.1, 19.0 i 18.11 to backporty zawierające tylko poprawkę krytyczną. Pozostałe 11 poprawek z tego dnia (dwie o wysokiej wadze) jest tylko w 19.3.6, 19.4.3 i 19.5.1. Jeśli jesteś na 19.2 lub starszej i chcesz pełen zestaw, zaplanuj przejście na 19.3.6 lub nowszą, co może wymagać przystanków.

Krok 4: zastosuj poprawkę (uważaj na migracje)

Tylko 19.4.3 i 19.3.6 zawierają migracje bazy danych. Na serwerze jednowęzłowym GitLab pozostaje niedostępny do zakończenia migracji, więc zaplanuj krótkie okno. Instalacje wielowęzłowe mogą skorzystać z procedury zero-downtime GitLaba.

# Pakiet Linux (Omnibus) - Debian/Ubuntu
sudo apt update && sudo apt install gitlab-ce=19.4.3-ce.0   # lub gitlab-ee=19.4.3-ee.0
# Pakiet Linux - RHEL/Amazon Linux
sudo dnf install gitlab-ce-19.4.3-ce.0

# Docker: pobierz dokładny tag i odtwórz kontener
docker pull gitlab/gitlab-ce:19.4.3-ce.0
# następnie odtwórz kontener z tymi samymi wolumenami/konfiguracją

# Helm: ustaw tag obrazu na wersję z poprawką i zaktualizuj
helm upgrade gitlab gitlab/gitlab --reuse-values \
  --set global.gitlabVersion=19.4.3

# Po instalacji pakietu zrekonfiguruj (Omnibus)
sudo gitlab-ctl reconfigure

Przypnij dokładną wersję z poprawką zamiast „latest”, żeby każdy węzeł floty wylądował na tym samym buildzie.

Krok 5: zweryfikuj poprawkę

# 1. Potwierdź, że serwowana wersja odpowiada wydaniu z poprawką
sudo cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
# Oczekiwane: 19.4.3 (lub wersja, którą wybrałeś)

# 2. Potwierdź zakończenie migracji i zdrowie aplikacji (Omnibus)
sudo gitlab-ctl status
sudo gitlab-rake db:migrate:status 2>/dev/null | tail -5
# Oczekiwane: wszystkie usługi "run", brak oczekujących migracji

# 3. Potwierdź, że instancja odpowiada po HTTP
curl -s -o /dev/null -w "%{http_code}\n" https://gitlab.example.com/-/health
# Oczekiwane: 200

Powtórz kroki 2 do 5 dla każdej instancji z inwentaryzacji, w tym replik Geo i staging.

Krok 6: jeśli jesteś na 18.10 lub starszej

Poniżej gałęzi 18.11 nie ma załatanego wydania, więc nie da się załatać w miejscu. Zaktualizuj do wspieranej wersji. Aktualizacje GitLaba przez kilka wersji minor wymagają etapowych przystanków (konkretnych wersji pośrednich, przez które trzeba przejść), więc to zaplanowana migracja, a nie jednorazowe apt upgrade. Do czasu jej zakończenia zmniejsz ekspozycję: zdejmij instancję z publicznego internetu albo przynajmniej ogranicz widoczność projektów publicznych, bo ścieżka nieuwierzytelniona potrzebuje publicznego projektu ze spreparowanym plikiem .org. To zawęża atak; nie zamyka luki.

Krok 7: sprawdź próby wykorzystania

GitLab opublikował dwie reguły detekcji (format Sigma, w otwartym frameworku TLDR), które działają na logach aplikacji:

• Seria błędów renderowania Org-mode: jeden klient powodujący pięć lub więcej timeoutów renderowania Org-mode w ciągu 30 minut (exceptions_json.log).
• Awaria natywnego workera Onigmo: worker GitLaba padający wewnątrz silnika regex (puma_stderr.log).

Możesz też przeszukać checkouty repozytoriów pod kątem podrzuconych ładunków (zbyt długie linie #+TODO: w plikach .org):

# Uruchom wewnątrz checkoutu podejrzanego repozytorium
rg -l --glob '**/*.org' '^\#\+(TODO|SEQ_TODO|TYP_TODO):.{500,}'

Awaria to powód do zbadania, a nie dowód kompromitacji. Jeśli znajdziesz ślady udanego ataku, potraktuj serwer jako skompromitowany: kod działa z uprawnieniami konta, na którym działa GitLab, więc zrotuj zmienne CI/CD, tokeny runnerów, klucze deploy i tokeny dostępu trzymane na serwerze. Pamiętaj, że wiele instancji domyślnie nie zapisuje puma_stderr.log, więc potwierdź wymagane źródła logów dla każdej reguły, zanim na niej polegniesz.

Self-managed GitLab trzyma Wasz kod źródłowy i często sekrety wdrożeniowe, więc nieuwierzytelnione RCE o maksymalnej wadze jest bliskie najgorszego scenariusza. Załataj dziś, zweryfikuj każdą instancję (nie tylko tę, o której myślisz) i zachowaj datowany zapis wersji przed i po dla audytorów.

Self-managed GitLab do załatania lub aktualizacji?

Umów bezpłatną 30-minutową rozmowę. Potwierdzimy, co jest narażone, przeprowadzimy aktualizacje z migracjami bazy i zaplanujemy bezpieczne zejście z każdej niewspieranej wersji.

Umów rozmowę Napisz do nas