GitLab opublikował pilną aktualizację bezpieczeństwa dla własnych instalacji Community Edition i Enterprise Edition. Najpoważniejsza z usuniętych podatności otrzymała maksymalną ocenę CVSS 10.0. W określonych warunkach atakujący nie musi nawet posiadać konta – odpowiednio przygotowana konfiguracja CI/CD może pozwolić mu na wykonanie dowolnego kodu na serwerze GitLab. Producent zaleca natychmiastową aktualizację.

12 października GitLab udostępnił wersje 19.4.2, 19.3.5 oraz 19.2.8 dla GitLab Community Edition i Enterprise Edition. Aktualizacje usuwają szereg błędów bezpieczeństwa, ale jeden z nich zdecydowanie wyróżnia się skalą potencjalnego zagrożenia.

Chodzi o podatność oznaczoną jako CVE-2026-97229, której przyznano maksymalny wynik 10.0 w skali CVSS.

Atak bez logowania do GitLaba

Problem dotyczy mechanizmu kompilowania wyrażeń regularnych wykorzystywanych w konfiguracji CI/CD. GitLab wyjaśnia, że przy spełnieniu określonych warunków nieautoryzowany użytkownik może przesłać specjalnie przygotowane wyrażenie regularne, które z powodu niewystarczającej walidacji doprowadzi do wykonania dowolnego kodu bezpośrednio na serwerze GitLab.

To bardzo poważny scenariusz. GitLab często przechowuje nie tylko kod źródłowy projektów, lecz również elementy związane z procesem wdrażania aplikacji, konfiguracje infrastruktury, tokeny, klucze i dane dostępowe wykorzystywane w automatycznych pipeline’ach.

Przejęcie serwera GitLab może więc potencjalnie stać się początkiem znacznie większego incydentu, prowadzącego do kradzieży kodu, pozyskania tajnych danych, modyfikacji oprogramowania albo ataków na kolejne elementy infrastruktury organizacji.

Które wersje GitLaba są podatne?

Według oficjalnego komunikatu problem CVE-2026-97229 dotyczy:

GitLab 19.2 – wszystkich wersji starszych niż 19.2.8, GitLab 19.3 – wszystkich wersji starszych niż 19.3.5 oraz GitLab 19.4 – wszystkich wersji starszych niż 19.4.2.

Administratorzy własnych serwerów GitLab powinni zaktualizować je odpowiednio do jednej z poprawionych wersji.

GitLab jednoznacznie zaleca, aby wszystkie podatne instalacje self-managed zostały zaktualizowane tak szybko, jak to możliwe. Serwis GitLab.com działa już na poprawionej wersji, a klienci GitLab Dedicated nie muszą podejmować dodatkowych działań.

Nie tylko jedna luka. Aktualizacja usuwa cały zestaw problemów

CVE-2026-97229 jest najpoważniejszą podatnością, ale aktualizacja z 12 października usuwa również szereg innych błędów.

Wśród nich znalazła się między innymi podatność XSS o wysokiej wadze, umożliwiająca w pewnych warunkach wykonanie JavaScriptu w sesji innego użytkownika za pomocą specjalnie przygotowanego repozytorium. GitLab poprawił też problemy z autoryzacją pipeline’ów oraz błąd, który mógł prowadzić do wykonania pipeline’u na chronionych gałęziach bez odpowiednich uprawnień.

Inna podatność mogła umożliwiać manipulowanie buforowanymi odpowiedziami dla plików repozytorium, co w określonych scenariuszach mogło doprowadzić do uruchomienia przygotowanej przez atakującego zawartości w pipeline CI/CD i ujawnienia chronionych zmiennych środowiskowych.

W Enterprise Edition poprawiono także lukę dotyczącą GitLab Duo Agent Platform, gdzie odpowiednio spreparowana zawartość mogła zostać wstrzyknięta do instrukcji agenta AI i prowadzić do niezamierzonego wykonywania poleceń.

Dlaczego luka w GitLabie może być tak niebezpieczna?

GitLab w wielu organizacjach pełni rolę centralnego punktu procesu tworzenia oprogramowania. Przechowywane są tam repozytoria, działa automatyzacja testów, kompilowanie aplikacji i ich wdrażanie.

To sprawia, że przejęcie środowiska GitLab może dać atakującemu dostęp znacznie szerszy niż do zwykłego serwera internetowego.

Cyberprzestępca, który uzyska możliwość wykonywania kodu na serwerze, może próbować szukać kluczy dostępowych, tokenów do usług chmurowych, danych wykorzystywanych w pipeline’ach czy poświadczeń służących do wdrażania aplikacji na środowiskach produkcyjnych.

Właśnie dlatego systemy DevOps są atrakcyjnym celem ataków na łańcuch dostaw oprogramowania.

Czy luka jest już wykorzystywana przez hakerów?

W oficjalnym komunikacie GitLab nie informuje o potwierdzonych masowych atakach wykorzystujących CVE-2026-97229. Sama maksymalna ocena podatności nie jest dowodem, że przestępcy już aktywnie używają jej przeciwko publicznym serwerom.

Nie jest to jednak powód do zwlekania z aktualizacją. Szczegóły dotyczące podatności bezpieczeństwa często stają się z czasem szerzej dostępne, a po wydaniu poprawki badacze i cyberprzestępcy mogą porównywać zmiany w kodzie, próbując odtworzyć sposób wykorzystania błędu.

GitLab zaznacza również, że szczegółowe zgłoszenia dotyczące naprawionych podatności są publikowane w jego trackerze po 90 dniach.

Co powinien zrobić administrator?

Najważniejsze jest sprawdzenie wersji działającej instalacji GitLab i jej natychmiastowa aktualizacja, jeśli znajduje się w podatnym zakresie.

Bezpieczne wersje z najnowszej aktualizacji to:

19.4.2
19.3.5
19.2.8

Jeżeli organizacja korzysta z własnej instalacji GitLab wystawionej do internetu, warto dodatkowo przejrzeć logi serwera i pipeline’ów pod kątem nietypowych operacji, nieznanych użytkowników oraz nieoczekiwanych zmian w konfiguracjach CI/CD.

Aktualizacja nie powinna być odkładana na później. CVSS 10.0 oznacza podatność o najwyższej możliwej ocenie ryzyka, a możliwość wykonania kodu bez uwierzytelnienia znacząco zwiększa jej potencjalne konsekwencje.