Czym jest CVE-2026-110264
GitLab korzysta z wbudowanego w Ruby silnika wyrażeń regularnych Onigmo. Gdy ten silnik kompiluje specjalnie spreparowane wyrażenie regularne, dochodzi do przepełnienia liczby całkowitej (integer overflow), a GitLab twierdzi, że można to zamienić na wykonanie dowolnego kodu na serwerze, z uprawnieniami użytkownika git, bez konta. Przepełnienie jest w samym silniku, dlatego luka sięga aż do GitLab 7.0.
Ścieżka ataku, według własnej reguły detekcji GitLaba: GitLab renderuje pliki Org-mode (format dokumentu tekstowego) za pomocą gemu org-ruby, który buduje wyrażenie regularne z keyworda w linii #+TODO: pliku .org, bez escapowania. Keyword powtórzony ponad 32 767 razy przepełnia licznik w silniku regex. Atak nie wymaga logowania, wystarczy jeden publiczny projekt zawierający spreparowany plik .org, który GitLab wyrenderuje. Udana próba może przebiegać cicho i niekoniecznie wywołuje awarię serwera.
GitLab ocenia lukę na CVSS 10.0 i tę ocenę należy traktować jako wiążącą.
Kogo to dotyczy
Działania wymaga tylko self-managed GitLab, Community Edition i Enterprise Edition, na każdej metodzie instalacji (pakiet Linux, Docker, Helm, źródła).
- GitLab.com już działa na załatanej wersji. Nic do zrobienia.
- GitLab Dedicated na załatanych buildach wewnętrznych już ma poprawkę. Nic do zrobienia.
- Self-managed, dowolna wersja od 7.0 wzwyż: podatny. Zakładaj, że jest w zasięgu, dopóki nie potwierdzisz wersji.
Pułapka łatki z 12 października
To część, która zaskakuje zespoły przekonane, że są już zabezpieczone. 12 października GitLab załatał inną lukę regex (CVE-2026-97229) w 19.4.2, 19.3.5 i 19.2.8. CVE-2026-110264 to osobny błąd o szerszym zasięgu. Serwer zaktualizowany do tych wydań z 12 października jest nadal podatny i potrzebuje wersji o jeden patch wyżej. Obie luki zgłosił ten sam badacz, a to już czwarty problem z silnikiem regex od niego w ciągu miesiąca.
Poprawka: zaktualizuj do wersji właściwej dla Twojej gałęzi
Wydane 21 października 2026 dla CE i EE:
| Jeśli masz | Zaktualizuj do | Uwagi |
|---|---|---|
| 19.5 | 19.5.1 | Wszystkie 12 poprawek |
| 19.4 | 19.4.3 | Wszystkie 12 poprawek, zawiera migracje bazy |
| 19.3 | 19.3.6 | Wszystkie 12 poprawek, zawiera migracje bazy |
| 19.2 | 19.2.9 | Tylko poprawka krytyczna |
| 19.1 | 19.1.9 | Tylko poprawka krytyczna |
| 19.0 | 19.0.10 | Tylko poprawka krytyczna |
| 18.11 | 18.11.13 | Tylko poprawka krytyczna |
| 18.10 i starsze | Brak załatanego wydania | Przejdź na wspieraną gałąź |
Zostań na gałęzi minor, którą masz (np. 19.4.x idzie do 19.4.3); aktualizacja na poziomie patcha nie wymaga dodatkowych przystanków. Tylko 19.4.3 i 19.3.6 zawierają migracje bazy danych, więc serwer jednowęzłowy pozostaje niedostępny do ich zakończenia. Instalacje wielowęzłowe mogą skorzystać z procedury zero-downtime GitLaba.
Dokładne komendy per metoda instalacji, sprawdzenie wersji i sposób uruchomienia dwóch reguł detekcji GitLaba na logach opisaliśmy w runbooku o łataniu CVE-2026-110264.
Jeśli masz GitLab 18.10 lub starszy: to decyzja o modernizacji
Poniżej gałęzi 18.11 nie ma załatanego wydania. Jeśli instancja self-managed jest na 18.10 lub starszej, łatanie nie wchodzi w grę, trzeba podnieść wersję do wspieranej, a aktualizacje GitLaba przez kilka wersji minor wymagają etapowych „przystanków” (nie da się przeskoczyć prosto do najnowszej). W praktyce instancja zostawiona tak daleko w tyle zwykle ma też przestarzały system operacyjny, runnery i backup.
Uczciwe ujęcie: tego GitLaba i tak trzeba było kiedyś podnieść. CVE-2026-110264 tylko wyznaczył termin, a kosztem zwłoki jest teraz nieuwierzytelnione RCE o maksymalnej ocenie na serwerze, który trzyma Wasz kod źródłowy i prawdopodobnie sekrety wdrożeniowe.
Co zrobić w tym tygodniu
- Zinwentaryzuj każdą instancję self-managed GitLab. Uwzględnij repliki Geo, staging, DR i serwery testowe. Zapomniana instancja to wciąż droga wejścia.
- Sprawdź wersję, którą faktycznie serwuje każda z nich (nie tylko CLI; komendy per instalacja są w runbooku).
- Załataj wspierane gałęzie natychmiast do wersji z tabeli. Jeśli łatałeś 12 października, idź o jeden patch wyżej.
- Zajmij się tym, co jest na 18.10 lub starszym: zaplanuj ścieżkę aktualizacji albo zdejmij instancję z publicznego internetu do czasu, aż się da.
- Sprawdź próby wykorzystania przy pomocy reguł detekcji GitLaba, a jeśli znajdziesz ślady kompromitacji, zrotuj zmienne CI/CD, tokeny runnerów, klucze deploy i tokeny dostępu trzymane na serwerze.
Na 22 października nie zgłoszono żadnych ataków, luki nie było w katalogu CISA KEV, a publiczny proof of concept się nie pojawił. To jest okno, w którym łatasz. Wcześniejszą lukę tego samego badacza Rapid7 odtworzył w ciągu doby od wydania, więc nie licz na to, że pozostanie cicho.
Nie wiesz, które z Waszych instancji GitLab są narażone?
Pomagamy zespołom zinwentaryzować self-managed GitLab, bezpiecznie załatać wspierane gałęzie (w tym wydania z migracjami bazy) i zaplanować ścieżkę aktualizacji dla wszystkiego, co utknęło na niewspieranej wersji. Zobacz naszą pracę w obszarze Bezpieczeństwo i Zgodność lub umów rozmowę poniżej.
Prowadzisz self-managed GitLab?
Umów bezpłatną 30-minutową rozmowę. Pomożemy potwierdzić, co jest załatane, przeprowadzić aktualizacje z migracjami bazy i zaplanować zejście z każdej niewspieranej wersji.
