Próba wykorzystania CVE-2026-97229 przeciwko GitLabowi Alpine Linux ujawnia ryzyko własnych wdrożeń Ruby

Wprowadzenie do problemu / definicja

Incydent związany z infrastrukturą Alpine Linux pokazuje, że samo zaktualizowanie GitLaba nie zawsze wystarcza do usunięcia krytycznej podatności. W centrum zdarzenia znalazła się luka CVE-2026-97229 o maksymalnej ocenie CVSS 10.0, powiązana z obsługą wyrażeń regularnych w mechanizmach CI/CD oraz silnikiem Onigmo wykorzystywanym przez Ruby.

To ważny sygnał dla administratorów środowisk self-managed, szczególnie tam, gdzie GitLab działa na własnym obrazie kontenera, własnej kompilacji albo korzysta z systemowego interpretera Ruby zamiast komponentów dostarczanych w oficjalnych pakietach producenta.

W skrócie

Alpine Linux poinformował o próbach wykorzystania krytycznej luki RCE przeciwko własnemu serwerowi GitLab. Atakujący posługiwał się spreparowanymi konfiguracjami CI, aby wywołać awarie procesów roboczych i potencjalnie doprowadzić do wykonania kodu.

Organizacja nie potwierdziła pełnego przejęcia serwera, ale nie mogła go też jednoznacznie wykluczyć. W efekcie odbudowano środowisko od podstaw, wymuszono reset haseł oraz przeprowadzono rotację kluczy i sekretów. Kluczowy problem polegał na tym, że poprawka GitLaba obejmowała Ruby zawarte w oficjalnych pakietach i obrazach, natomiast wdrożenie Alpine korzystało z własnego stosu Ruby.

Kontekst / historia

Podatność CVE-2026-97229 została ujawniona w październiku 2026 roku jako krytyczny błąd umożliwiający zdalne wykonanie kodu w określonych warunkach. Obejmowała wybrane gałęzie GitLab CE i EE 19.2, 19.3 oraz 19.4 przed wydaniami naprawczymi. Producent opublikował poprawki dla wersji 19.2.8, 19.3.5 oraz 19.4.2, a później również dalsze aktualizacje serwisowe dla nowszych wydań.

W przypadku Alpine Linux problem miał także wymiar operacyjny. Serwer projektu został 13 października zaktualizowany do GitLab 19.3.4 zamiast 19.3.5, co pozostawiło instancję bez właściwej poprawki. W dniach 20–21 października nowo utworzone konto zaczęło przesyłać złośliwe konfiguracje CI. Po wykryciu nietypowego zachowania usługi konto zablokowano, lecz później okazało się, że nawet aktualizacja do GitLab 19.3.6 nie usuwa całego ryzyka, ponieważ podatny pozostawał interpreter Ruby używany w obrazie wdrożeniowym.

Analiza techniczna

Od strony technicznej podatność wiąże się z kompilacją wyrażeń regularnych używanych przez logikę CI/CD. Mechanizm przetwarzania reguł GitLaba przekazuje dane kontrolowane przez użytkownika do silnika Onigmo będącego częścią Ruby. W określonym scenariuszu specjalnie przygotowane wyrażenie regularne oraz odpowiednio sformatowane ścieżki repozytorium mogą doprowadzić do błędu przepełnienia liczb całkowitych podczas kompilacji wzorca.

Konsekwencją może być naruszenie integralności przepływu sterowania i uruchomienie poleceń systemowych w kontekście użytkownika obsługującego GitLaba. Badacze bezpieczeństwa odtworzyli łańcuch eksploatacji na niezałatanym obrazie GitLab, pokazując możliwość wykonania komend jako użytkownik systemowy git.

W praktyce scenariusz demonstracyjny wymagał wcześniejszego umieszczenia złośliwego pliku .gitlab-ci.yml oraz odpowiednio nazwanej ścieżki w publicznym projekcie. Na instancjach dopuszczających samodzielną rejestrację nowych użytkowników i tworzenie projektów przez niezaufane konta próg wejścia dla atakującego znacząco się obniża.

W incydencie Alpine odnotowano osiem awarii procesów roboczych, a część prób wskazywała, że napastnik mógł przejść przez fragment łańcucha eksploatacji przed niepowodzeniem w kolejnym etapie. Dodatkowo pobranie obrazu kontenera GitLaba sugerowało próbę dostrojenia exploita do konkretnego środowiska ofiary. Analiza po incydencie była jednak utrudniona z powodu braku pełnych logów pomocniczych oraz niewystarczającego rejestrowania ruchu wychodzącego.

Najważniejszy wniosek techniczny dotyczy modelu dystrybucji poprawek. Oficjalne pakiety i obrazy GitLaba zawierały już poprawione Ruby, natomiast wdrożenia kompilowane samodzielnie lub oparte na osobno instalowanym Ruby wymagały niezależnej aktualizacji interpretera do wersji 3.3.13, 3.4.12, 4.0.9 lub nowszej. To oznacza, że część organizacji mogła błędnie uznać aktualizację samego GitLaba za wystarczającą.

Konsekwencje / ryzyko

Ryzyko związane z CVE-2026-97229 jest bardzo wysokie. Po pierwsze, luka otrzymała ocenę CVSS 10.0, czyli najwyższą możliwą. Po drugie, dotyczy platformy centralnej dla procesu wytwarzania oprogramowania, która często przechowuje kod źródłowy, sekrety CI/CD, tokeny runnerów, webhooki oraz dane integracyjne.

Skuteczne wykorzystanie podatności mogłoby prowadzić do kradzieży danych użytkowników, przejęcia tokenów automatyzacji, manipulacji pipeline’ami, podmiany artefaktów budowania, a nawet naruszenia łańcucha dostaw oprogramowania. W środowiskach takich jak Alpine Linux ryzyko ma także wymiar infrastrukturalny i reputacyjny.

Szczególnie narażone są instancje korzystające z własnych obrazów kontenerowych.
Podwyższone ryzyko dotyczy środowisk używających systemowego Ruby zamiast bundlowanego runtime.
Niebezpieczne są konfiguracje dopuszczające publiczną rejestrację kont i tworzenie projektów przez niezaufanych użytkowników.
Problem pogłębia brak pełnego logowania zdarzeń aplikacyjnych, kontenerowych i sieciowych.

Rekomendacje

Administratorzy GitLaba powinni potraktować ten incydent jako ostrzeżenie przed zbyt uproszczonym podejściem do zarządzania poprawkami. W praktyce niezbędna jest weryfikacja całego stosu wykonawczego, a nie wyłącznie numeru wersji aplikacji.

Zweryfikować model instalacji GitLaba i ustalić, czy środowisko działa na oficjalnym pakiecie, oficjalnym obrazie czy własnej kompilacji.
Zaktualizować GitLaba do wersji naprawczych właściwych dla używanej gałęzi oraz równolegle zaktualizować Ruby, jeśli instancja korzysta z niestandardowego runtime.
Ograniczyć publiczną rejestrację kont oraz możliwość tworzenia projektów przez niezaufanych użytkowników.
Przeanalizować logi pod kątem nietypowych żądań związanych z CI, ostrzeżeń regexp, awarii procesów Ruby i podejrzanych ścieżek.
Poszukać oznak kompromitacji, takich jak nieautoryzowane klucze SSH, zmienione zadania harmonogramu, nietypowe procesy i połączenia wychodzące.
Po każdym podejrzeniu wykonania kodu przeprowadzić pełną rotację sekretów, haseł, tokenów i danych integracyjnych.
Rozszerzyć monitoring o logowanie zadań w tle, zdarzeń kontenerowych i ruchu wychodzącego.
Sprawdzić własne obrazy kontenerowe i pipeline’y buildowe pod kątem zależności runtime aktualizowanych niezależnie od samego GitLaba.

Podsumowanie

Incydent Alpine Linux pokazuje, że krytyczne podatności w GitLabie mogą dotyczyć głębszych warstw stosu aplikacyjnego, a nie wyłącznie samej aplikacji. CVE-2026-97229 jest przykładem luki, której skuteczne usunięcie zależy bezpośrednio od modelu wdrożenia platformy.

Organizacje korzystające z niestandardowych buildów, własnych kontenerów i systemowego Ruby powinny uwzględniać nie tylko wersję GitLaba, lecz także stan bezpieczeństwa interpretera oraz bibliotek bazowych. Z perspektywy obrony najważniejsze pozostają identyfikacja modelu instalacji, pełna aktualizacja Ruby, ograniczenie powierzchni ataku oraz gotowość do szybkiej rotacji sekretów i odbudowy środowiska.