GitLab wydał pilne aktualizacje zabezpieczeń dotyczące CVE-2026-110264, luki o maksymalnej powadze, która może pozwolić nieautoryzowanemu atakującemu na wykonanie dowolnego kodu na podatnych na ataki serwerach GitLab zarządzanych samodzielnie. Usterka ma wynik CVSS 10.0 i dotyczy zarówno GitLab Community Edition (CE), jak i Enterprise Edition (EE).
Luka jest szczególnie godna uwagi, ponieważ dotknięty nią kod pochodzi z GitLab 7.0, wydanego w 2014 roku. To pozostawia około 12 lat wydań GitLab w podatnym zakresie, chociaż obecnie nie ma dowodów na to, że atakujący eksploatowali tę słabość przez cały ten okres. GitLab ujawnił problem i wydał poprawione wersje 21 października 2026 roku.
Luka pochodzi z przepełnienia liczby całkowitej uruchamianego podczas kompilacji specjalnie stworzonego wyrażenia regularnego przez GitLab. W określonych warunkach, nieautoryzowany atakujący mógłby użyć tego warunku do wykonania dowolnego kodu na bazowym serwerze GitLab. GitLab celowo wstrzymał pełną ścieżkę eksploatacji i specyficzne wymagania, aby administratorzy mogli zastosować poprawki.
Dla organizacji prowadzących infrastrukturę GitLab zarządzaną samodzielnie, potencjalny wpływ jest poważny. Repozytoria GitLab często zawierają kod źródłowy, konfigurację CI/CD, tajemnice do wdrożenia, tokeny dostępu, definicje infrastruktury i połączenia do środowisk produkcyjnych. Kompromis na poziomie serwera może zatem stwarzać możliwości kradzieży poświadczeń, manipulacji repozytoriami, ataków na łańcuch dostaw, zachowania trwałości lub ruchu poziomego.
Zespoły ds. bezpieczeństwa poszukujące możliwości wykrywania CVE-2026-110264 mogą wykorzystać platformę AI-Native Detection Intelligence firmy SOC Prime, aby wzmocnić widoczność eksploitacji tej luki i powiązanych zachowań po kompromitacji w środowiskach SIEM, EDR i Data Lake.
Kliknij Przeglądaj wykrycia aby uzyskać dostęp do odpowiednich treści wykrycia i logiki namierzania. Aby wykryć próby eksploatacji CVE-2026-110264, obrońcy powinni korelować telemetrię aplikacji GitLab z wykonaniem procesów, nieprawidłowym działaniem serwera i nowo wydaną logiką wykrywania zagrożeń GitLab.
Praktycy bezpieczeństwa mogą również użyć Prime Architect do przekształcania nowych informacji o lukach w reguły Sigma i zapytania łowieckie, weryfikowania logiki wykrywania, generowania odpowiednich przepływów ataku i tłumaczenia treści wykrywania na wspierane platformy bezpieczeństwa.
Skontaktuj się z działem sprzedaży
analiza CVE-2026-110264
GitLab opisuje lukę jako przepełnienie liczby całkowitej w swoim kompilatorze wyrażeń regularnych. W określonych warunkach, kompilacja specjalnie stworzonego wyrażenia regularnego może prowadzić do wykonania dowolnego kodu na serwerze GitLab bez uwierzytelniania.
GitLab przypisał lukę do maksymalnej wartości CVSS v3.1 wynoszącej 10,0, z wektorem CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Oznacza to, że jest to podatność dostępna przez sieć z niską złożonością ataku, bez wymaganych uprawnień i interakcji użytkownika, z potencjalnie wysokim wpływem na poufność, integralność i dostępność.
Badacz bezpieczeństwa joaxcar odkrył i zgłosił tę lukę za pośrednictwem programu nagród za błędy GitLab na platformie HackerOne. Notatki o wydaniu GitLab dodatkowo odnoszą się do poprawek w obsłudze wyrażeń regularnych Ruby, a raporty wskazują, że dotkniętym silnikiem jest Onigmo, implementacja wyrażeń regularnych Ruby zintegrowana z pakietami GitLab.
CVE-2026-110264 dotyka GitLab CE i EE w niezwykle szerokim zakresie:
- GitLab od wersji 7.0 do wersji przed 18.11.13
- GitLab 19.0 przed 19.0.10
- GitLab 19.1 przed 19.1.9
- GitLab 19.2 przed 19.2.9
- GitLab 19.3 przed 19.3.6
- GitLab 19.4 przed 19.4.3
- GitLab 19.5 przed 19.5.1
GitLab przeniósł poprawki do wersji 18.11.13, 19.0.10, 19.1.9 i 19.2.9 oprócz standardowych gałęzi poprawek z powodu powagi i niezwykle szerokiego zasięgu.
Długi podatny okres nie oznacza, że usterka była aktywnie wykorzystywana od 2014 roku. Raczej funkcjonalność wyrażeń regularnych podatna na ataki istniała w wydaniach datowanych od GitLab 7.0. Ani GitLab, ani dostarczone raporty nie potwierdziły wykorzystywania w atakach rzeczywistych do dnia 22 października 2026 roku.
Tę lukę nie należy mylić z CVE-2026-97229, inną krytyczną luką GitLab umożliwiającą zdalne wykonanie kodu związaną z przetwarzaniem wyrażeń regularnych, która została załatana wcześniej w październiku. Problem ten dotknął węższą gamę nowszych wydań. Instalacja poprawek z 12 października dla tej luki nie zapewnia automatycznie ochrony systemów przed tą nowo ujawnioną usterką.
Administratorzy, którzy niedawno zaktualizowali GitLab, muszą zatem zweryfikować swoją dokładną zainstalowaną wersję, zamiast zakładać, że poprzednie październikowe wydanie zabezpieczeń zapewnia wystarczającą ochronę.
Obecnie dostępne szczegóły dotyczące CVE-2026-110264 nie ujawniają dokładnych wejść kontrolowanych przez atakującego, punktu końcowego, funkcji ani warunków wymaganych do dotarcia do podatnego kompilatora wyrażeń regularnych. GitLab na ogół udostępnia szczegółowe problemy z zabezpieczeniami publicznie 90 dni po wydaniu zawierającym poprawkę, ograniczając natychmiastową dostępność możliwych do wykorzystania technicznych informacji, podczas gdy klienci instalują poprawki.
Żaden publiczny PoC CVE-2026-110264 nie został ujawniony w dostarczonych raportach ani w doradztwie GitLab. Cybersecurity News szczególnie podkreśla, że GitLab nie opublikował publicznego exploita, natomiast firma ograniczyła ujawnienie pełnej ścieżki ataku.
Brak publicznego dowodu koncepcji nie powinien być interpretowany jako niskie ryzyko. Zdalnie dostępna, nieuwierzytelniona luka z oceną CVSS 10.0 stanowi atrakcyjny cel, zwłaszcza że serwery GitLab zarządzane samodzielnie są często eksponowane na Internet.
Obecnie nie ma kampanii specyficznych dla CVE-2026-110264, takich jak złośliwe adresy IP, domeny, hashe ładunków lub potwierdzone wzorce żądań eksloitowania, ponieważ ani GitLab, ani cytowani badacze bezpieczeństwa nie zgłosili aktywnego wykorzystywania.
GitLab opublikował jednak dwa wykrycia zagrożeń mające na celu identyfikację możliwych prób eksploatacji na instalacjach samodzielnie zarządzanych:
- Awaria natywnego pracownika Onigmo
- Org mode burst błędu renderowania
Te wykrycia zaprojektowane są w celu identyfikacji podejrzanego zachowania związanego z próbami wywołania luki. Ich obecność nie potwierdza sama w sobie udanego kompromisu i powinna być korelowana z szerszą telemetrią aplikacji i punktów końcowych.
Zespoły bezpieczeństwa powinny badać niespodziewane awarie aplikacji GitLab, nagłe błędy renderowania, anomalne procesy pochodzące z komponentów GitLab lub Ruby, niespodziewane wykonanie powłoki, nowo utworzone mechanizmy trwałości i połączenia wychodzące z serwerów GitLab, które odbiegają od normalnych wzorców operacyjnych.
Mitigacja CVE-2026-110264
GitLab zdecydowanie zaleca, aby wszystkie organizacje, które działają na dotkniętych instalacjach zarządzanych samodzielnie, natychmiast przeprowadziły aktualizację. Poprawione wersje to:
| Gałąź GitLab | Poprawiona wersja |
| 18.11 i wcześniejsze ścieżki migracji wspierane | 18.11.13 |
| 19.0 | 19.0.10 |
| 19.1 | 19.1.9 |
| 19.2 | 19.2.9 |
| 19.3 | 19.3.6 |
| 19.4 | 19.4.3 |
| 19.5 | 19.5.1 |
GitLab.com został już zaktualizowany. Najemcy GitLab Dedicated uruchamiający wewnętrzne wersje 19.3.5-internal0, 19.4.2-internal0 lub nowsze już zawierają niezbędne poprawki i nie muszą podejmować działania dla tej luki.
Klienci zarządzający samodzielnie nie powinni opóźniać sprostowania, oczekując na dodatkowe szczegóły dotyczące wykorzystania. GitLab nie opublikował alternatywnej ominięcia, która zapewniłaby równoważną ochronę, co czyni instalację poprawionej wersji niezawodną ścieżką sprostowania.
Przed aktualizacją administratorzy powinni przejrzeć dokumentację aktualizacji GitLab i uwzględnić migracje baz danych. GitLab ostrzega, że wdrożenia na jednym węźle mogą doświadczyć przestojów podczas zakończenia migracji, podczas gdy poprawnie skonfigurowane środowiska wielowęzłowe mogą zastosować proces aktualizacji bez przestojów od dostawcy. Wersje 19.3.6 i 19.4.3 zawierają regularne migracje, a 19.4.3 obejmuje także migrację po wdrożeniu.
Po załataniu, zespoły bezpieczeństwa powinny przeprowadzić retrospektywną analizę zamiast traktowania samej aktualizacji jako dowodu, że serwer nigdy nie był celem ataku. Przejrzyj dzienniki aplikacji GitLab dotyczące dwóch wskaźników eksploatacji opublikowanych przez GitLab i zbadania podejrzanej działalności przed aktualizacją.
Obrońcy powinni także przeglądać telemetrię systemu operacyjnego w poszukiwaniu:
- Nieoczekiwane procesy podrzędne pochodzące z GitLab, Ruby lub związanych z nimi pracowników
- Wykonanie powłoki lub interpretera skryptów pod kontami usługi GitLab
- Nowe klucze SSH lub konta administracyjne
- Nieoczekiwane modyfikacje w repozytoriach lub potokach CI/CD
- Nowo utworzone zaplanowane zadania lub mechanizmy trwałości
- Zmiany w biegaczach, tokenach wdrożeniowych, osobistych tokenach dostępu i tokenach dostępu do projektów
- Nietypowe połączenia wychodzące z serwera GitLab
- Nieautoryzowany dostęp do sekretów przechowywanych w zmiennych CI/CD
- Nieoczekiwane pakiety, wydania lub modyfikacje repozytoriów
Jeśli podejrzenie kompromisu jest uzasadnione, organizacje powinny odizolować serwer, zachować dzienniki i artefakty analizy kryminalistycznej, obrócić potencjalnie narażone poświadczenia i tokeny oraz zweryfikować integralność repozytoriów i przepływów pracy CI/CD przed przywróceniem instancji do środowiska produkcyjnego.
Ponieważ instalacje GitLab często pełnią funkcję zaufanej infrastruktury w ramach przepływów pracy w rozwoju oprogramowania, reakcjonariusze powinni także ustalić, czy atakujący mógł zmienić kod źródłowy, artefakty, obrazy kontenerów, szablony infrastruktury jako kodu lub przepływy pracy wdrożeniowe. Kompromitowany serwer GitLab może stwarzać ryzyko dla łańcucha dostaw nawet po załataniu oryginalnego serwera.
Platforma AI-Native Detection Intelligence firmy SOC Prime może pomóc organizacjom w wzmocnieniu postury wykrywania przed eksploatacją nowych zagrożeń poprzez dostarczanie nieustannie aktualizowanych treści wykrywania opartych na zachowaniach, skoordynowanych z MITRE ATT&CK®.~
Zrzeczenie odpowiedzialności: Treści detekcyjne mogą nie być dostępne dla każdego CVE. Sprawdź platformę SOC Prime, aby poznać aktualne pokrycie. Jeśli odpowiednie wykrycia nie są jeszcze dostępne, sprawdź ponownie, ponieważ nowa inteligencja zagrożeń i treści wykrywania są ciągle dodawane.
FAQ
Czym jest CVE-2026-110264 i jak działa?
CVE-2026-110264 to krytyczna luka umożliwiająca zdalne wykonanie kodu, dotykająca GitLab Community Edition i Enterprise Edition. Wywodzi się z przepełnienia liczby całkowitej, które może wystąpić, gdy GitLab kompiluje specjalnie skonstruowane wyrażenie regularne. W określonych warunkach nieautoryzowany zdalny atakujący mógłby wywołać usterkę i wykonać dowolny kod na serwerze GitLab. GitLab nie ujawnił jeszcze pełnego wejścia ani ścieżki aplikacji wymaganej do dotarcia do podatnego kodu.
Kiedy po raz pierwszy odkryto CVE-2026-110264?
Luka została zgłoszona do GitLab przez badacza bezpieczeństwa joaxcar za pośrednictwem programu nagród za błędy HackerOne firmy. GitLab publicznie ujawnił problem i wydał poprawki 21 października 2026 roku. Sama podatna na ataki wersja kodu istniała w wydaniach GitLab od wersji 7.0 w 2014 roku, ale nie oznacza to, że luka była znana lub wykorzystywana przez cały 12-letni okres.
Jaki jest wpływ CVE-2026-110264 na systemy?
Udana eksploatacja mogłaby pozwolić nieautoryzowanemu atakującemu na wykonanie dowolnego kodu na podatnym serwerze GitLab zarządzanym samodzielnie. Ponieważ GitLab może przechowywać kod źródłowy, poświadczenia, tokeny dostępu, sekrety CI/CD, artefakty budowania, konfiguracje wdrożenia i definicje infrastruktury, kompromitacja serwera może potencjalnie skutkować kradzieżą danych wrażliwych, manipulacją repozytoriami, trwałością, kompromitacją poświadczeń, ruchem bocznym lub atakami na łańcuch dostaw oprogramowania. Ocena CVSS GitLab określa potencjalny wpływ na poufność, integralność i dostępność jako wysoki.
Czy CVE-2026-110264 może nadal dotyczyć mnie w 2026 roku?
Tak. Każda instalacja GitLab CE lub EE zarządzana samodzielnie w ramach dotkniętego zakresu wersji pozostaje podatna na ataki, dopóki nie zostanie zaktualizowana do wersji z poprawką. GitLab.com został już załatany, a aktualizowane środowiska GitLab Dedicated są chronione. Organizacje zarządzane samodzielnie powinny zweryfikować dokładną zainstalowaną wersję, ponieważ nawet systemy zaktualizowane podczas wcześniejszych październikowych cykli poprawek GitLabu mogą nadal wymagać kolejnej aktualizacji.
Jak mogę chronić się przed CVE-2026-110264?
Natychmiast zaktualizuj GitLab zarządzany samodzielnie do wersji 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3, 19.5.1 lub nowszej wspieranej wersji. Po załataniu, przejrzyj wykrycia opublikowane przez GitLab „Awaria pracownika natywnego Onigmo” i „Burst błędów renderowania org mode”, zbadaj historię telemetrii aplikacji i punktów końcowych pod kątem podejrzanej aktywności oraz rozpoznaj niespodziewane wykonywanie procesu lub zmiany w konfiguracji. Jeśli istnieją oznaki kompromisu, odizoluj dotkniętą instancję, obróć poświadczenia i tokeny dostępu, przejrzyj sekrety CI/CD i aktywa robocze oraz zweryfikuj integralność repozytoriów, pakietów, artefaktów budowy i potoków wdrożeniowych przed przywróceniem normalnych operacji.