Ponad 1 000 serwerów GitLab nadal narażonych na aktywnie wykorzystywane ataki RCE - Security Bez Tabu

Ponad 1 000 serwerów GitLab nadal narażonych na aktywnie wykorzystywane ataki RCE

Cybersecurity news

Wprowadzenie do problemu / definicja

Podatności typu remote code execution, czyli RCE, należą do najgroźniejszych kategorii błędów bezpieczeństwa, ponieważ pozwalają atakującemu uruchomić własny kod na docelowym serwerze. W najnowszym przypadku problem dotyczy samodzielnie utrzymywanych instancji GitLab, gdzie wykryto krytyczną lukę związaną z przetwarzaniem konfiguracji CI/CD.

Sprawa ma szczególne znaczenie dla środowisk DevSecOps, ponieważ GitLab często pełni centralną rolę w zarządzaniu repozytoriami, pipeline’ami, sekretami oraz procesem budowania i wdrażania oprogramowania. Kompromitacja takiego systemu może wywołać skutki znacznie wykraczające poza pojedynczy serwer.

W skrócie

Podatność oznaczona jako CVE-2026-97229 dotyczy GitLab CE i EE i może prowadzić do zdalnego wykonania kodu bez uwierzytelnienia w określonych warunkach. Źródłem problemu jest integer overflow w komponencie CI/CD Regular Expression Compiler, odpowiedzialnym za analizę wyrażeń regularnych używanych w konfiguracjach pipeline’ów.

Choć producent udostępnił poprawki bezpieczeństwa, ponad 1 000 publicznie dostępnych instancji nadal pozostaje podatnych. Dodatkowo luka została już potwierdzona jako aktywnie wykorzystywana, co znacząco podnosi pilność działań po stronie administratorów.

Kontekst / historia

GitLab jest jednym z najważniejszych narzędzi wspierających współczesny proces wytwarzania oprogramowania, dlatego każda krytyczna podatność w tej platformie zyskuje wysoki priorytet operacyjny. W ostatnim czasie rozwiązanie było już przedmiotem analiz związanych z innymi poważnymi błędami bezpieczeństwa, co pokazuje, że infrastruktura DevOps pozostaje atrakcyjnym celem dla napastników.

W przypadku CVE-2026-97229 producent opublikował aktualizacje bezpieczeństwa 12 października 2026 roku i zalecił natychmiastowy upgrade instancji self-managed. Następnie podatność została powiązana z aktywną eksploatacją i trafiła do katalogu Known Exploited Vulnerabilities, co dla wielu organizacji jest wyraźnym sygnałem do uruchomienia procedur awaryjnych.

Analiza techniczna

Problem koncentruje się w module CI/CD Regular Expression Compiler, który odpowiada za parsowanie i ewaluację wyrażeń regularnych obecnych w konfiguracjach pipeline’ów. Błąd wynika z integer overflow połączonego z niewystarczającą walidacją odpowiednio spreparowanych wzorców regex.

W praktyce oznacza to, że atakujący może przygotować złośliwą konfigurację CI/CD zawierającą specjalnie zaprojektowany wzorzec. Jeśli podatna instancja przetworzy taki ładunek, w określonych warunkach może dojść do wykonania arbitralnego kodu na serwerze GitLab.

To szczególnie groźny scenariusz, ponieważ GitLab często posiada dostęp do krytycznych zasobów organizacji, takich jak:

  • repozytoria kodu źródłowego,
  • sekrety i zmienne środowiskowe CI/CD,
  • tokeny dostępu i poświadczenia integracyjne,
  • artefakty buildów i mechanizmy publikacji.

Z perspektywy bezpieczeństwa łańcucha dostaw oprogramowania przejęcie takiego systemu może umożliwić modyfikację pipeline’ów, manipulację artefaktami lub przygotowanie dalszych ataków na środowiska produkcyjne. Warto również zwrócić uwagę na rozbieżności w komunikacji dotyczącej wersji pośrednich, dlatego najbezpieczniejszym podejściem pozostaje aktualizacja do najnowszego wspieranego wydania danej gałęzi lub wyższej wersji.

Konsekwencje / ryzyko

Ryzyko związane z CVE-2026-97229 należy uznać za bardzo wysokie. Mamy do czynienia z luką umożliwiającą zdalne wykonanie kodu, potencjalnie osiągalną bez uwierzytelnienia i potwierdzoną w realnych atakach.

Najważniejsze konsekwencje mogą obejmować:

  • przejęcie kontroli nad serwerem GitLab,
  • kradzież sekretów, tokenów i danych dostępowych,
  • manipulację repozytoriami oraz konfiguracją CI/CD,
  • naruszenie integralności procesu build i release,
  • wykorzystanie platformy jako punktu wejścia do dalszego ruchu bocznego w organizacji.

W środowiskach enterprise skutki mogą być jeszcze poważniejsze, ponieważ kompromitacja platformy DevOps może przełożyć się na zagrożenie dla całego cyklu życia oprogramowania. Publicznie wystawiona, niezałatana instancja GitLab powinna być traktowana jako aktywo wysokiego ryzyka.

Rekomendacje

Najważniejszym działaniem pozostaje natychmiastowa aktualizacja wszystkich instancji self-managed GitLab do wersji zawierającej poprawkę lub do nowszego wspieranego wydania. Tego typu upgrade powinien być traktowany jako priorytetowe zadanie bezpieczeństwa.

Organizacje powinny dodatkowo wdrożyć następujące działania:

  • zinwentaryzować wszystkie instancje GitLab, w tym środowiska testowe i tymczasowe,
  • potwierdzić wersję każdego serwera oraz gotowość do aktualizacji,
  • przeanalizować logi aplikacyjne, systemowe i sieciowe pod kątem anomalii związanych z CI/CD,
  • zweryfikować i w razie potrzeby zrotować sekrety, tokeny runnerów oraz poświadczenia integracyjne,
  • ograniczyć ekspozycję interfejsów administracyjnych do zaufanych adresów IP lub dostępu przez VPN,
  • włączyć dodatkowy monitoring zmian w pipeline’ach, webhookach, runnerach i ustawieniach projektów.

Jeżeli natychmiastowa aktualizacja nie jest możliwa, warto zastosować środki kompensacyjne, takie jak czasowe ograniczenie dostępu z Internetu, segmentacja sieci oraz filtrowanie ruchu przychodzącego. Należy jednak podkreślić, że takie działania nie usuwają samej podatności i mogą jedynie ograniczyć powierzchnię ataku.

Podsumowanie

CVE-2026-97229 to jedna z najpoważniejszych podatności, jakie mogą dotknąć platformę klasy DevSecOps. Połączenie maksymalnej wagi, możliwości zdalnego wykonania kodu oraz aktywnej eksploatacji sprawia, że każda niezałatana instancja GitLab stanowi realne zagrożenie dla organizacji.

Fakt, że ponad 1 000 serwerów nadal pozostaje podatnych, pokazuje skalę problemu i trudność w szybkim wdrażaniu poprawek bezpieczeństwa. Dla zespołów IT i cyberbezpieczeństwa oznacza to konieczność natychmiastowej reakcji, zanim luka zostanie wykorzystana do przejęcia infrastruktury lub naruszenia łańcucha dostaw oprogramowania.

Źródła

  1. Over 1,000 GitLab servers vulnerable to ongoing RCE attacks — https://www.bleepingcomputer.com/news/security/over-1-000-gitlab-servers-vulnerable-to-code-execution-attacks/
  2. GitLab warns of max severity code execution vulnerability — https://www.bleepingcomputer.com/news/security/gitlab-warns-of-max-severity-rce-flaw-in-regex-compiler-engine/
  3. GitLab 19 upgrade notes — https://docs.gitlab.com/update/versions/gitlab_19_changes/
  4. Known Exploited Vulnerabilities Catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog