CVE-2026-97229: Krytyczna luka RCE w GitLab umożliwia nieautoryzowane wykonanie kodu

GitLab wydał nadzwyczajne aktualizacje zabezpieczeń dotyczące CVE-2026-97229, krytycznej luki umożliwiającej zdalne wykonanie kodu, wpływającej na GitLab Community Edition (CE) i Enterprise Edition (EE). Wada ma wynik CVSS równy 10.0 i może umożliwić nieautoryzowanemu zdalnemu napastnikowi wykonanie dowolnego kodu na podatnym serwerze GitLab w określonych warunkach.

Luka znajduje się w kompilatorze wyrażeń regularnych CI/CD GitLab i wynika z niewystarczającej walidacji specjalnie sformułowanych wyrażeń regularnych. Pomyślne wykorzystanie tej luki może naruszyć poufność, integralność i dostępność środowiska GitLab bez konieczności uwierzytelnienia lub interakcji użytkownika.

GitLab wydał poprawione wersje 19.2.8, 19.3.4 i 19.4.2 w dniu 12 października 2026 roku, gorąco zachęcając administratorów instalacji zarządzanych samodzielnie do natychmiastowej aktualizacji. GitLab.com już działa na poprawionej wersji, podczas gdy klienci GitLab Dedicated nie muszą podejmować dodatkowych działań.

Z zarządzaniem kodem źródłowym i infrastrukturą CI/CD zawierającymi wrażliwe repozytoria, poświadczenia, tajemnice wdrożeniowe i dostęp do środowisk produkcyjnych, luki w GitLab mogą stwarzać znaczące ryzyko dla współczesnych łańcuchów dostaw oprogramowania.

Zespoły ds. bezpieczeństwa mogą wzmocnić swoje obrony przed pojawiającym się wykorzystywaniem luk dzięki platformie SOC Prime AI-Native Detection Intelligence, przyspieszając łowiectwo zagrożeń i inżynierię detekcji, dostosowując logikę detekcji do telemetryki bezpieczeństwa swojej organizacji.

Skontaktuj się z działem sprzedaży

Analiza CVE-2026-97229

CVE-2026-97229 wpływa na instalacje GitLab CE i EE w trzech obecnie podatnych gałęziach wydań:

• GitLab 19.2 przed 19.2.8
• GitLab 19.3 przed 19.3.4
• GitLab 19.4 przed 19.4.2

Luka jest spowodowana przepełnieniem całkowitym w kompilatorze wyrażeń regularnych CI/CD. Ten komponent przetwarza wyrażenia regularne używane w konfiguracjach potoków projektów. Według GitLab, niewystarczająca walidacja wyrażeń regularnych może pozwolić nieautoryzowanemu napastnikowi na dostarczenie specjalnie spreparowanego wyrażenia, co ostatecznie prowadzi do wykonania dowolnego kodu na serwerze GitLab.

GitLab nadał lukcie maksymalny wynik CVSS 3.1 wynoszący 10.0, z wektorem AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Odzwierciedla to powagę luki dostępnej z sieci, która nie wymaga ani uwierzytelnienia, ani interakcji użytkownika i może potencjalnie mieć duży wpływ na poufność, integralność i dostępność.

Wada jest szczególnie niebezpieczna, ponieważ serwery GitLab często zajmują bardzo uprzywilejowaną pozycję w infrastrukturze rozwojowej. Mogą hostować kod źródłowy chroniony prawnie, zmienne CI/CD, poświadczenia wdrożeniowe, tokeny dostępu, pliki konfiguracyjne oraz integracje z chmurą i środowiskami produkcyjnymi.

Wykonanie dowolnego kodu na podległym serwerze GitLab może zatem dać napastnikom możliwości uzyskania dostępu do wrażliwych repozytoriów, wyodrębnienia tajemnic, manipulacji kodem źródłowym, ingerencji w potoki, ustanowienia trwałości lub użycia skompromitowanej infrastruktury jako odskoczni do dodatkowych systemów.

Luka została zgłoszona do GitLab za pośrednictwem programu nagród za zgłaszanie błędów HackerOne przez badacza bezpieczeństwa joaxcar. GitLab nie określi publicznie dokładnej daty, w której problem został początkowo odkryty lub zgłoszony prywatnie. Został publicznie ujawniony wraz z krytycznym wydaniem poprawek z 12 października 2026.

Ujawnienie następuje po innych ostatnich lukach wpływających na komponenty przetwarzania wyrażeń regularnych GitLab. We wrześniu 2026 roku GitLab załatał CVE-2026-93577, kolejny przypadek przepełnienia całkowitego w kompilatorze wyrażeń regularnych, a także CVE-2026-89078, lukę podwójnego zwolnienia w parserze wyrażeń regularnych. Te wcześniejsze wady wymagały uwierzytelnienia, podczas gdy nowo ujawniona luka może zostać wykorzystana przez nieautoryzowanego napastnika w warunkach opisanych przez GitLab.

Od 12 października 2026 roku GitLab i wspomniane raporty bezpieczeństwa nie potwierdziły aktywnego wykorzystania luki w rzeczywistych atakach. Nie udokumentowano publicznie zweryfikowanego PoC CVE-2026-97229 w głównych źródłach przeglądanych w momencie pisania.

W celu wykrycia CVE-2026-97229 obrońcy powinni monitorować infrastrukturę GitLab zarządzaną samodzielnie pod kątem podejrzanej aktywności konfiguracji CI/CD, nietypowych wyrażeń regularnych, nieoczekiwanego zachowania usług GitLab oraz nieprawidłowych procesów uruchamianych z komponentów serwerowych GitLab.

Ponieważ pomyślne wykorzystanie zapewnia wykonanie dowolnego kodu, zachowanie po eksploatacji może znacznie się różnić w zależności od celów napastnika. Monitorowanie powinno zatem wykraczać poza wzory zapytań specyficzne dla luk i obejmować wykonywanie procesów, aktywność sieci wychodzących, dostęp do poświadczeń, mechanizmy trwałości oraz nieoczekiwane modyfikacje repozytoriów lub konfiguracji CI/CD.

Złagodzenie CVE-2026-97229

GitLab stanowczo zaleca, aby administratorzy samodzielnych wdrożeń CE i EE natychmiast zaktualizowali się do jednej z naprawionych wersji:

• 19.4.2 lub nowsza
• 19.3.4 lub nowsza
• 19.2.8 lub nowsza

GitLab.com już został zaktualizowany do poprawionej wersji, a klienci GitLab Dedicated nie muszą podejmować działań. CERT-EU podobnie zaleca priorytetowe traktowanie aktualizacji instancji zarządzanych lokalnie, szczególnie tych bezpośrednio dostępnych z internetu.

Organizacje powinny najpierw sporządzić inwentarz instalacji GitLab zarządzanych samodzielnie i określić ich dokładne wersje. Instancje skierowane na zewnątrz i serwery zintegrowane z wrażliwymi środowiskami rozwoju, wdrożenia, chmury lub produkcji powinny otrzymać najwyższy priorytet przy naprawianiu.

Administratorzy powinni również przeglądać ostatnie zmiany konfiguracji CI/CD pod kątem nietypowych lub niewyjaśnionych wzorów wyrażeń regularnych. Podejrzane zmiany w konfiguracji powinny być skorelowane z aktywnością uwierzytelniania, zmianami w repozytoriach Git, telemetrią serwera i zdarzeniami wykonywania procesów.

Aby wykryć próby wykorzystania CVE-2026-97229, zespoły bezpieczeństwa powinny szukać nietypowej aktywności związanej z przetwarzaniem konfiguracji CI/CD GitLab, po której następuje anomalne wykonywanie procesów po stronie serwera, nieoczekiwana aktywność powłoki, połączenia wychodzące lub zmiany w wrażliwych repozytoriach i zasobach potokowych.

Ponieważ GitLab nie ujawnił specyficznych dla ataku IOC CVE-2026-97229, obrońcy powinni polegać na monitorowaniu behawioralnym, zamiast czekać na statyczne hasze, adresy IP lub domeny. Organizacje, które odkrywają wskaźniki możliwego wykorzystania, powinny traktować serwer GitLab jako potencjalnie skompromitowany i badać dostęp do tajemnic CI/CD, poświadczeń repozytoriów, biegaczy, tokenów wdrożeniowych oraz zintegrowanej infrastruktury.

Poświadczenia i tajemnice dotknięte potencjalnym incydentem należy rotować po opanowaniu sytuacji. Zespoły ds. bezpieczeństwa powinny również przeglądać historię repozytoriów i konfiguracje potoków pod kątem nieautoryzowanych zmian, które mogą ustanowić trwałość w łańcuchu dostaw oprogramowania nawet po załataniu podległego serwera.

Platforma SOC Prime AI-Native Detection Intelligence może pomóc zespołom ds. bezpieczeństwa operacjonalizować pojawiające się informacje o zagrożeniach i dostosowywać logikę detekcji do ich SIEM, EDR i innych środowisk bezpieczeństwa, wspierając szybsze badanie podejrzanych zachowań związanych z krytycznymi lukami.