Luka CVE-2026-97229 w GitLab CI/CD: które instancje są naprawdę zagrożone

Wyrażenie regularne, które kończy się wykonaniem kodu

GitLab przy przetwarzaniu konfiguracji CI/CD kompiluje wyrażenia regularne zapisane w pliku .gitlab-ci.yml. W tym kompilatorze tkwi przepełnienie liczby całkowitej (CWE-190), które odpowiednio spreparowane wyrażenie zamienia w wykonanie dowolnego kodu. Ważne jest miejsce: kod uruchamia się na samym serwerze GitLab, poza odizolowanymi runnerami. Atakujący ląduje więc tam, gdzie leżą repozytoria, zmienne CI/CD i tokeny. GitLab ocenił lukę na CVSS 10.0 (CVE-2026-97229).

Rapid7 odtworzył atak na niezałatanym oficjalnym obrazie GitLab CE, a działający kod PoC leży publicznie na GitHubie. Do 22 października 2026 r. nikt nie potwierdził ataków, luki nie ma też w katalogu CISA KEV. Przy publicznym exploicie nie zakładałbym, że ten stan potrwa długo.

Bez logowania czy z kontem: co to znaczy dla Waszej instancji

GitLab i NVD piszą, że w pewnych warunkach do ataku nie trzeba się uwierzytelniać. Rapid7 doprecyzowuje te warunki: atakujący musi umieścić złośliwy plik .gitlab-ci.yml w gałęzi publicznego projektu. Jeśli instancja pozwala zwykłym użytkownikom tworzyć projekty publiczne, wystarczy dowolne konto. Przy otwartej rejestracji takie konto założy sobie każdy, więc w praktyce luka staje się dostępna bez logowania.

Z tego wynika podział pilności:

• Łatajcie dziś: instancje dostępne z internetu z otwartą rejestracją, a także te, na których konta mają osoby z zewnątrz (podwykonawcy, klienci, praktykanci) i mogą tworzyć projekty publiczne.
• Najbliższe okno serwisowe, najlepiej w tym tygodniu: typowa firmowa instancja za VPN albo SSO, z kontami tylko dla pracowników i bez projektów publicznych. Tu atak wymaga przejętego konta albo kogoś z wewnątrz. Ryzyko rośnie przy każdym wycieku haseł, ale nocna aktualizacja nie jest tu potrzebna.

GitLab.com jest już załatany, a klienci GitLab Dedicated nie muszą nic robić. Problem dotyczy instalacji self-managed CE i EE, wszystkich typów.

Wersje podatne i poprawione

• 19.4 przed 19.4.2
• 19.3 przed 19.3.5
• 19.2 przed 19.2.8

Na gałęzi 19.3 pomińcie wersję 19.3.4. Miała błąd stron merge requestów przy włączonej integracji Ona i nie jest docelową poprawką. Celem jest 19.3.5.

To samo wydanie usuwa w sumie 24 luki: 1 krytyczną, 5 wysokich, 14 średnich i 4 niskie. Z wysokich najbardziej interesujące dla zespołów DevOps są CVE-2026-16301 (uruchamianie pipeline'ów na chronionych gałęziach bez uprawnień, CVSS 8.5) i CVE-2026-14814 (dostęp do chronionych zmiennych CI/CD przez zatrute pliki w cache, CVSS 8.2). Do tego CVE-2026-92883, czyli XSS w podświetlaniu składni (CVSS 8.7). CVE-2026-14814 dotyczy wszystkich wersji przed poprawkami, więc instancja na 19.1 lub starszej nie jest bezpieczna tylko dlatego, że CVE-2026-97229 jej nie obejmuje. Poprawki dostały wyłącznie gałęzie 19.2–19.4.

Gdzie GitLab potrafi się schować

Najczęściej umyka serwer testowy postawiony „na chwilę”, stara instancja po migracji, której nikt nie wyłączył, albo GitLab w kontenerze u dewelopera. Wersję sprawdzicie tak:

1. W przeglądarce: po zalogowaniu strona /help albo przegląd w Admin Area.
2. Instalacja Omnibus (paczka Linux): sudo gitlab-rake gitlab:env:info, wiersz Version w sekcji GitLab information.
3. Docker: docker ps --format '{{.Names}} {{.Image}}' | grep -i gitlab, a potem docker exec -it <kontener> gitlab-rake gitlab:env:info. Tag latest niczego nie gwarantuje, dopóki kontener nie zostanie odtworzony z nowego obrazu.
4. Kubernetes (Helm): helm list -A | grep -i gitlab pokazuje wersję chartu i aplikacji.

Przy okazji zajrzyjcie w Admin Area do ustawień rejestracji (Sign-up restrictions) i sprawdźcie, kto może tworzyć projekty publiczne. To decyduje o tym, do której grupy pilności trafia instancja.

Aktualizacja i plan B

Wydanie zawiera migracje bazy danych, więc instancja jednowęzłowa będzie przez chwilę niedostępna. Zróbcie kopię zapasową i zarezerwujcie krótkie okno.

Jeśli nie możecie zaktualizować od razu, zamknijcie znaną ścieżkę ataku: wyłączcie otwartą rejestrację, ograniczcie anonimowy dostęp do projektów publicznych i odbierzcie niezaufanym użytkownikom możliwość tworzenia projektów publicznych i zapisu do nich. Rapid7 zaznacza, że to blokuje tylko znany scenariusz i nie usuwa błędu. Traktujcie to jako zabezpieczenie na kilka dni.

Co sprawdzić w logach i po aktualizacji

GitLab opublikował sześć reguł wykrywania dla tej luki, m.in. dla awarii natywnego procesu Onigmo, awarii procesu Workhorse przy CI lint oraz wrogich wyrażeń regularnych wysyłanych przez GraphQL CI lint. W praktyce szukajcie:

• nieoczekiwanych restartów i awarii procesów GitLaba,
• nowych kont i nowych projektów publicznych z nietypowym .gitlab-ci.yml,
• nowych tokenów dostępu, kluczy SSH, kont z uprawnieniami administratora i zarejestrowanych runnerów, których nikt nie zamawiał,
• nieznanych procesów na serwerze.

Jeśli instancja była podatna i wystawiona do internetu z otwartą rejestracją, zróbcie ten przegląd także po aktualizacji. Poprawka zamyka lukę, ale nie usuwa kogoś, kto już wszedł. Przy jakimkolwiek podejrzeniu rotujcie tokeny i chronione zmienne CI/CD, bo to one są najcenniejszym łupem.

Wniosek na dłużej

GitLab wydaje nową wersję minor co miesiąc, a poprawki bezpieczeństwa dostają tylko ostatnie gałęzie, w tym przypadku 19.2–19.4. Instancja, która zostaje kilka wersji w tyle, w pewnym momencie przestaje dostawać łatki w ogóle. Opłaca się mieć stały, comiesięczny termin aktualizacji GitLaba i spis wszystkich instancji, łącznie z testowymi. Równie ważne są ustawienia: zamknięta rejestracja, projekty publiczne tylko tam, gdzie są potrzebne, i ograniczony krąg osób, które mogą tworzyć projekty i uruchamiać pipeline'y.