Każda instalacja GitLaba utrzymywana na własnym serwerze, od wersji 7.0 z 2014 roku do poprawek z 21 października 2026, ma lukę, przez którą osoba bez konta może w pewnych warunkach uruchomić kod na serwerze. GitLab ocenił błąd CVE-2026-110264 na 10 w 10-stopniowej skali CVSS i wydał wersje 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 oraz 18.11.13, a serwis GitLab.com i usługa Dedicated są już załatane.
Których instalacji dotyczy CVE-2026-110264
CVE-2026-110264 to przepełnienie liczby całkowitej w kompilatorze wyrażeń regularnych GitLaba. Według wydania z 21 października nieuwierzytelniony użytkownik mógł dzięki niemu wykonać dowolny kod na serwerze. Luka dotyczy obu edycji: darmowej Community Edition i płatnej Enterprise Edition. Wydanie nie wskazuje typu wdrożenia, a według zasady producenta oznacza to, że podatne są wszystkie. Chodzi więc o pakiet Linux, Docker, Helm i instalację ze źródeł.
Bezpieczna jest wersja równa albo wyższa od tej w tabeli, w ramach Twojej gałęzi:
| Gałąź | Wersja z poprawką |
|---|---|
| 19.5 | 19.5.1 |
| 19.4 | 19.4.3 |
| 19.3 | 19.3.6 |
| 19.2 | 19.2.9 |
| 19.1 | 19.1.9 |
| 19.0 | 19.0.10 |
| 18.11 | 18.11.13 |
| 18.10 i starsze, od 7.0 | brak poprawki, trzeba przejść na nowszą gałąź |
Producent przeniósł poprawkę do czterech starszych gałęzi, ale najstarsza z nich to 18.11. Serwer na 18.10, 17.x czy 16.x nie dostanie łatki w swojej linii i musi przejść na jedną z wersji z tabeli.
Klienci chmury producenta nie muszą nic robić. Klienci usługi Dedicated od wersji 19.3.5-internal0 i 19.4.2-internal0 mają poprawkę w środku. Problem dotyczy więc wyłącznie GitLaba stawianego samodzielnie: w firmowej serwerowni, na VPS-ie albo w chmurze.
Jak działa atak: plik .org i silnik wyrażeń regularnych
Wektorem jest podgląd plików w formacie Org, które serwer wyświetla jak sformatowany dokument. Producent opisał mechanizm w publicznej regule wykrywania prób ataku. Pliki .org renderuje biblioteka org-ruby. Wstawia ona słowo kluczowe z linii #+TODO: wprost do wyrażenia regularnego. Słowo z ponad 32 767 powtórzeniami przepełnia licznik w silniku Onigmo, którego używa Ruby. Silnik zapisuje wtedy dane poza przydzieloną pamięcią.
Według GitLaba do ataku bez logowania wystarczy jeden publiczny projekt, w którym leży spreparowany plik .org. Kod wykonuje się z uprawnieniami użytkownika systemowego git. Producent wymienia też skutki udanego ataku. To kradzież pliku z sekretami instancji (gitlab-secrets.json), wszystkich zmiennych CI/CD, tokenów runnerów i tokenów dostępu oraz dostęp do każdego repozytorium na serwerze.
Dla firmy oznacza to utratę wszystkiego, co trzyma ten serwer: kodu, haseł do baz w zmiennych CI/CD i kluczy do środowisk produkcyjnych. W liście zmian wydania jest też łatka na przepełnienie w wyrażeniach regularnych Ruby dla wersji 3.3, 3.4 i 4.0.
Agenci AI · Kodożercy
Twoje przepływy w n8n mogą podejmować decyzje
Kurs Agenci AI od Kodożerców pokazuje, jak dołożyć do n8n warstwę, która czyta dokumenty, dobiera kolejny krok i pyta o zgodę, zanim zrobi coś nieodwracalnego. Budujesz to na własnych integracjach, moduł po module.
Sprawdź, jak to zbudować →
Trzecia luka w wyrażeniach regularnych w ciągu miesiąca
CVE-2026-110264 zamyka serię trzech błędów w tym samym obszarze. Wszystkie zgłosił przez program HackerOne badacz o pseudonimie joaxcar. 23 września producent załatał CVE-2026-93577 z oceną 9,9. Wtedy napastnik musiał mieć konto i wstawić wyrażenie do konfiguracji CI/CD. 12 października przyszła CVE-2026-97229 z oceną 10,0, już bez logowania. Opis detekcji GitLaba nazywa ją obejściem poprzedniej poprawki.
Najnowsza luka sięga dalej niż dwie poprzednie. Tamte dotyczyły gałęzi 19.2–19.4, a ta wszystkich wersji od 7.0, więc także serwerów, których nikt nie aktualizował od lat.
Producent nie pisze, że luka jest wykorzystywana w atakach. W katalogu aktywnie wykorzystywanych podatności amerykańskiej agencji CISA (stan z 21 października) żadnej z trzech nie ma. Jest tam za to CVE-2026-85706, wrześniowa luka GitLaba z odczytem danych, dopisana 11 września. Według BleepingComputer organizacja Shadowserver widzi w internecie ponad 2 700 instancji GitLab CE. Nie wiadomo, ile z nich ma już poprawkę.
W Polsce przed luką ostrzega CERT PSE, zespół reagowania Polskich Sieci Elektroenergetycznych, w komunikacie P26-418 z 22 października.
Jak sprawdzić wersję GitLaba
Wersję pokazuje strona pomocy w interfejsie. Według dokumentacji wybierz na dole lewego paska bocznego Help, a potem Help. Numer wersji jest na górze strony, trzeba być zalogowanym.
Z konsoli serwera administrator sprawdzi wersję poleceniem dla instalacji z pakietu Linux:
sudo gitlab-rake gitlab:env:info
W wyniku szukaj sekcji “GitLab information” i wiersza “Version”, a numer porównaj z tabelą wyżej. Przy instalacji ze źródeł polecenie brzmi tak:
bundle exec rake gitlab:env:info RAILS_ENV=production
Jak zaktualizować GitLaba: pakiet Linux, Docker i Helm
Zrób najpierw kopię zapasową. Dokumentacja zaleca też aktualizację GitLab Runnera do tej samej wersji co serwer. Wydanie z 21 października ma migracje bazy danych, więc na serwerze z jedną maszyną aktualizacja oznacza przestój do czasu ich zakończenia.
Pakiet Linux (Omnibus)
Na Ubuntu i Debianie dokumentacja producenta podaje takie polecenia, pierwsze dla Community Edition, drugie dla Enterprise Edition:
sudo apt update && sudo apt install gitlab-ce=<version>-ce.0
sudo apt update && sudo apt install gitlab-ee=<version>-ee.0
Za <version> wstaw numer z tabeli, na przykład 19.5.1. Przed instalacją pakiet sam robi kopię bazy, ale producent i tak zaleca własną, pełną kopię.
Starsza instalacja nie przeskoczy od razu na 19.5.1. Trzeba przejść przez wymagane przystanki aktualizacji: w gałęzi 18 są to 18.2, 18.5, 18.8 i 18.11, w gałęzi 19 wersje 19.2 i 19.5. Serwer na 18.9 dojdzie do poprawki najkrócej przez 18.11.13. Dłuższą drogę policzy narzędzie Upgrade Path, do którego linkuje ta sama strona.
Docker
Dla instalacji z Docker Engine instrukcja każe najpierw zrobić kopię, co najmniej bazy danych i pliku z sekretami. Potem zatrzymujesz i usuwasz kontener, pobierasz obraz z nową wersją i uruchamiasz kontener ponownie z tymi samymi opcjami co wcześniej:
sudo docker stop gitlab
sudo docker rm gitlab
sudo docker pull gitlab/gitlab-ce:<version>-ce.0
Dla Enterprise Edition obraz to gitlab/gitlab-ee:<version>-ee.0. Przy pierwszym starcie aplikacja sama się przekonfiguruje i zaktualizuje. Przy Docker Compose zmień wersję obrazu w pliku docker-compose.yml, a potem wykonaj docker compose pull i docker compose up -d.
Helm (Kubernetes)
Wersje wykresu Helm mają inną numerację niż sama aplikacja. Numer wykresu dla wersji z poprawką sprawdź w tabeli mapowania w dokumentacji wykresu. Przed aktualizacją zrób kopię i zapisz dotychczasowe ustawienia:
helm get values gitlab > gitlab.yaml
Co zrobić przed aktualizacją i po niej
Jeśli serwera nie da się zaktualizować od razu, ogranicz publiczną widoczność projektów. Tak radzi producent w opisie detekcji, bo ścieżka ataku bez logowania potrzebuje publicznego pliku .org.
Jednym z możliwych śladów próby ataku jest seria wpisów w dzienniku exceptions_json.log. W instalacji z pakietu Linux leży on w katalogu:
/var/log/gitlab/gitlab-rails/
Producent radzi szukać serii błędów Timeout::Error z renderera OtherMarkup przy plikach .org, wywołanych przez jednego klienta. Pliki z podejrzanie długą linią #+TODO: znajdzie w repozytoriach polecenie z tej samej reguły:
rg -l --glob '**/*.org' '^\#\+(TODO|SEQ_TODO|TYP_TODO):.{500,}'
Brak śladów niczego nie dowodzi. Producent zaznacza, że udany atak jest cichy i nie zawsze wywołuje awarię procesu. Jeśli znajdziesz ślady wykonania kodu, uznaj serwer za przejęty. Wymień wtedy sekrety instancji, zmienne CI/CD, tokeny runnerów i tokeny dostępu. To te same dane, na które polowali autorzy ataku opisanego w tekście o wykradaniu sekretów z GitHub Actions. Jeśli na tej samej maszynie działają inne usługi, sprawdź przy okazji wersję PHP, bo w tym tygodniu wyszły poprawki krytycznych luk w PHP.
FAQ
Czy luka w GitLabie jest już wykorzystywana w atakach?
Na 22 października 2026 producent o tym nie pisze, a CISA nie dopisała luki do katalogu aktywnie wykorzystywanych podatności. Opublikował jednak reguły wykrywania prób ataku. Przy ocenie 10/10 i ataku bez logowania nie warto czekać na pierwsze doniesienia.
Czy własny serwer GitLaba jest bezpieczniejszy niż chmura GitLab.com?
Przy tej luce nie. Chmura producenta dostała poprawkę przed publikacją, a każda instalacja samodzielna czeka na swojego administratora. Własny serwer daje kontrolę nad danymi, ale razem z nią obowiązek aktualizacji. Różnice między platformami opisujemy w porównaniu GitLab czy GitHub, a różnice w samych potokach w tekście GitHub Actions kontra GitLab CI.
{ dla firm }Co możemy zrobić dla Twojej firmy?
Budujemy strony, sklepy i aplikacje, łączymy systemy z KSeF i księgowością, wdrażamy automatyzacje i agentów AI, a na koniec dbamy o widoczność w Google. Zaczynamy od rozmowy o tym, co dziś zabiera Twojemu zespołowi najwięcej czasu.
Podsumowanie
GitLab 21 października 2026 roku załatał lukę CVE-2026-110264 z oceną 10/10. Przez spreparowany plik w formacie Org osoba bez konta może w pewnych warunkach uruchomić kod na serwerze jako użytkownik git. Podatne są wszystkie samodzielnie utrzymywane instalacje Community i Enterprise Edition od wersji 7.0. Poprawkę mają wersje 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 i 18.11.13. Starsze gałęzie muszą przejść na jedną z nich, z przystankami aktualizacji. Chmura producenta i usługa Dedicated nie wymagają działań. Do 22 października producent nie informował o atakach z jej użyciem, a CISA nie wpisała jej do katalogu wykorzystywanych podatności. To jednak trzeci taki błąd w ciągu miesiąca. Sprawdź wersję, zaktualizuj serwer i do tego czasu ogranicz publiczne projekty. Stan na 22 października 2026 roku, godz. 16:30.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
