Ing. Calogero Bono
12 października 2026 GitLab opublikował wersje 19.4.2, 19.3.5 i 19.2.8 dla Community Edition oraz Enterprise Edition. Zawierają poprawkę CVE-2026-97229, podatności z wynikiem CVSS 10.0, która może prowadzić do wykonania dowolnego kodu na serwerze. W czwartek amerykańska CISA potwierdziła aktywne wykorzystywanie i dodała ją do katalogu KEV. Jeśli prowadzisz własną instancję GitLab, sprawa wymaga natychmiastowej aktualizacji.
Kilka pojęć, zanim przejdziemy do faktów. CVE to kod identyfikujący publicznie znaną podatność. CVSS to wskaźnik wagi od 0 do 10. CI/CD oznacza zautomatyzowane potoki, które kompilują, testują i publikują kod. KEV to katalog CISA podatności, które zostały już wykorzystane w prawdziwych atakach. RCE oznacza zdalne wykonanie kodu, czyli uruchamianie poleceń na serwerze kogoś innego.
Czym jest CVE-2026-97229?
Zgodnie z oficjalną stroną GitLab jest to problem integer overflow w kompilatorze wyrażeń regularnych, używanym w konfiguracjach CI/CD. W określonych warunkach użytkownik niezalogowany mógł wykonać dowolny kod na serwerze, używając starannie skonstruowanego wyrażenia regularnego, z powodu niewystarczającej walidacji.
Wektor CVSS wskazuje sieć, niską złożoność, brak uprawnień i brak interakcji użytkownika. Dlatego wynik wynosi 10.0. Zgłoszenia dokonał joaxcar w ramach programu bug bounty na HackerOne.
Kto ją wykorzystuje?
Jak informuje BleepingComputer, CISA dodała podatność do KEV i poprosiła agencje federalne o zabezpieczenie serwerów do niedzieli. Według The Hacker News termin dla agencji cywilnych to 1 listopada 2026.
Wpis wiąże się z incydentem zgłoszonym przez Alpine Linux. Nieznany aktor bezskutecznie próbował wykorzystać podatność na ich instancji 20 i 21 października 2026. Wysłał specjalnie przygotowane konfiguracje CI i osiem razy spowodował awarie procesów workerów. W czterech przypadkach exploit zawiódł na kolejnym etapie. Atakujący pobrał także obraz kontenera GitLab Alpine. Nowe próby z 25 i 26 października zostały zablokowane.
Opiekunowie Alpine stwierdzili – «Atak był bliski powodzenia». Dodali, że nie znaleźli dowodów na udane włamanie, ale nie mogą go wykluczyć, dlatego odtworzyli instancję od zera. Według nich repozytorium aports, pakiety i wydania z 21 października nie zostały zmanipulowane.
Które wersje są dotknięte?
Dla CVE-2026-97229 GitLab wskazuje wszystkie wersje od 19.2 przed 19.2.8, od 19.3 przed 19.3.5 oraz od 19.4 przed 19.4.2. GitLab.com korzysta już z poprawnej wersji. Instancje GitLab Dedicated zostały zaktualizowane wewnętrznym wydaniem przed publikacją.
GitLab informuje też, że w wersji 19.3.4 wystąpił błąd na stronach merge request przy aktywnej integracji Ona. Jest naprawiony w 19.3.5. Firma wydała także sześć reguł wykrywania zagrożeń, które pomogą administratorom instancji self-managed wykryć próby wykorzystania.
Inne podatności w tej samej łatce
Wydanie nie zawiera tylko najpoważniejszego przypadku. Wśród pozostałych poprawek, z wynikami podanymi przez GitLab, są m.in. –
- CVE-2026-92883, cross-site scripting w podświetlaniu składni, CVSS 8.7.
- CVE-2026-16301, użytkownik z rolą Developer mógł uruchamiać potoki na chronionych gałęziach, CVSS 8.5.
- CVE-2026-14814, zatruwanie pamięci podręcznej plików raw, z możliwym ujawnieniem chronionych zmiennych, CVSS 8.2.
- CVE-2026-81839, potoki uruchamiane z uprawnieniami nowej grupy po przeniesieniu projektu (tylko EE), CVSS 7.7.
- CVE-2026-96893, wstrzyknięcie w instrukcje agentów AI GitLab Duo (tylko EE), CVSS 7.3.
Są też pięć podatności o średniej wadze, w tym odczyt poufnych notatek przez GraphQL i ujawnienie tokenów w logach GitLab Pages. Pełny obraz znajduje się na oficjalnej stronie.
Ograniczenia, o których warto wiedzieć
Nie wiemy, ile instancji zostało przejętych. Shadowserver, cytowany przez BleepingComputer, śledzi prawie 2.800 instancji Community Edition wystawionych w Internecie, ale nie wskazuje, ile z nich jest już zaktualizowanych. Tej liczby nie należy traktować jako liczby podatnych systemów.
Z dostępnych źródeł nie wiadomo, kim jest atakujący ani czy istnieją inne przypadki poza Alpine. Szczegóły techniczne exploita nie zostały opublikowane. GitLab udostępnia zgłoszenia 90 dni po wydaniu łatki, więc mogą pojawić się kolejne szczegóły.
Co to zmienia dla osób pracujących w cyfrowym świecie
Jeśli masz self-managed GitLab w swoim studiu lub firmie, priorytetem jest wersja. Podatność bez uwierzytelniania na serwerze, który przechowuje kod, sekrety i potoki, to realne ryzyko również dla klientów. Kto hostuje repozytorium na GitLab.com, jest już chroniony po stronie platformy.
Lekcja z Alpine jest praktyczna. Jeśli nie możesz wykluczyć kompromitacji, odtwórz instancję i zmień sekrety. Automatyzacja instalacji pomaga, o czym piszemy w przewodniku o Ansible do konfiguracji i wdrożeń. Serwery wymagają też dyscypliny w aktualizacjach, o czym pisaliśmy przy okazji Fragnesia i PHP2Shell. Innym niedawnym przykładem skanowania po łatce jest Oracle E-Business Suite. Jeśli nie masz czasu śledzić wszystkiego, dostępne są hosting i serwery zarządzane z aktualizacjami bezpieczeństwa.
Nasza opinia
Ta sprawa pokazuje, jak krótki jest czas między łatką a atakiem. Poprawka pochodzi z 12 października, a próby na Alpine z 20, czyli osiem dni później. Kto aktualizuje dopiero w kolejnym cyklu miesięcznym, działa po terminie.
Pozostaje jedna krytyczna uwaga. GitLab jest wymieniany jako obecny w ponad połowie firm z listy Fortune 100, a BleepingComputer wylicza serię podatności o maksymalnej wadze w tym samym okresie, w tym dwie kolejne o najwyższej wadze. Dla usługi, która przechowuje kod i sekrety firmy, ta częstotliwość ma znaczenie. Nie wystarczy powiedzieć, że GitLab szybko łata, nawet jeśli tak jest. Kto decyduje się trzymać wszystko u siebie, musi liczyć się z ciągłym nadzorem albo powierzyć go specjalistom.
Najczęściej zadawane pytania
Czy muszę od razu zaktualizować GitLab?
Tak, jeśli instancja jest self-managed i działa w wymienionych wersjach. GitLab zaleca natychmiastową aktualizację do 19.4.2, 19.3.5 lub 19.2.8. Aktywne wykorzystywanie potwierdziła CISA.
Czy GitLab.com jest zagrożony?
Według GitLab nie. GitLab.com korzysta już z poprawnej wersji, a instancje Dedicated zostały zaktualizowane przed publicznym wydaniem.
Czy do wykorzystania podatności potrzebne jest konto?
Nie. Wektor CVSS wskazuje brak wymaganych uprawnień i brak interakcji użytkownika. Atak przechodzi przez starannie przygotowaną konfigurację CI/CD.
Jak sprawdzić, czy zostałem zaatakowany?
Ze źródeł nie wynika pewny sposób. GitLab udostępnił sześć reguł wykrywania dla instancji self-managed. Alpine zauważył powtarzające się awarie workerów po nietypowych konfiguracjach CI.
Czy wystarczy aktualizacja?
To zależy. Jeśli instancja była wystawiona i niezałatana w ostatnich dniach, nie możesz wykluczyć kompromitacji. Alpine zdecydowało się odtworzyć ją od zera.
Na co zwrócić uwagę w najbliższych tygodniach, między łatami a kontrolami
W najbliższych dniach ważne będzie ustalenie, czy pojawią się kolejne przypadki poza Alpine i czy zostaną opublikowane szczegóły techniczne. Oto trzy wskazówki.
- Zaktualizuj do najnowszej wersji dostępnej dla swojej gałęzi i sprawdź numer po instalacji.
- Sprawdź logi workerów pod kątem powtarzających się awarii i nietypowych konfiguracji CI, korzystając z reguł GitLab.
- Jeśli instancja była wystawiona i nieaktualna, zmień tokeny i chronione zmienne oraz rozważ odtworzenie.
