Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Upublicznienie działającego kodu proof-of-concept dla podatności typu remote code execution w GitLab istotnie zwiększa ryzyko ataków na organizacje utrzymujące własne instancje platformy. Problem dotyczy scenariusza, w którym uwierzytelniony użytkownik mający możliwość wykonania push do projektu może doprowadzić do uruchomienia poleceń na serwerze z uprawnieniami konta git. Szczególnie niepokojące jest to, że atak nie wymaga uprawnień administratora, dostępu do runnerów CI/CD ani interakcji ze strony ofiary.
W skrócie
Badacze bezpieczeństwa opublikowali publiczny PoC dla łańcucha RCE w GitLab Self-Managed. Podatność wiąże się z mechanizmem przetwarzania różnic dla notebooków Jupyter i wynika z połączenia dwóch błędów pamięci w bibliotece Oj używanej do parsowania JSON w środowisku Ruby. Atakujący może przygotować spreparowane pliki .ipynb, doprowadzić do wycieku informacji z pamięci procesu, a następnie wykonać polecenia systemowe na serwerze.
- Zagrożone są wybrane wersje GitLab CE i EE.
- Eksploit wymaga uwierzytelnienia, ale nie wymaga praw administratora.
- Publiczny PoC obniża próg wejścia dla kolejnych napastników.
- Rekomendowanym działaniem jest pilna aktualizacja do wersji naprawczych.
Kontekst / historia
Sprawa zyskała duże znaczenie po opublikowaniu kodu exploitacyjnego 24 lipca 2026 roku, kilka tygodni po udostępnieniu poprawek przez producenta. Według dostępnych informacji poprawka trafiła do GitLab 10 czerwca 2026 roku, jednak nie została jednoznacznie opisana jako klasyczna poprawka bezpieczeństwa. Z operacyjnego punktu widzenia ma to znaczenie, ponieważ wiele zespołów administracyjnych priorytetyzuje aktualizacje na podstawie biuletynów bezpieczeństwa, numerów CVE lub ocen ryzyka.
Problem obejmuje wydania GitLab CE/EE od 15.2.0 do 18.10.7, od 18.11.0 do 18.11.4 oraz od 19.0.0 do 19.0.1. Wersje naprawcze to odpowiednio 18.10.8, 18.11.5 i 19.0.2. Dodatkowo znaczenie ma również poprawka w gemie Oj, która została udostępniona w wersji 3.17.3.
Analiza techniczna
Łańcuch ataku koncentruje się na ścieżce renderowania diffów dla notebooków Jupyter. GitLab analizuje pliki .ipynb i przekazuje kontrolowany przez repozytorium JSON do parsera Oj działającego wewnątrz procesu aplikacyjnego. W praktyce oznacza to, że dane dostarczone przez atakującego trafiają do natywnego kodu C odpowiedzialnego za zarządzanie pamięcią.
Opisany scenariusz wykorzystuje dwa błędy pamięci. Pierwszy umożliwia zapis poza stałym stosem zagnieżdżeń parsera, co może prowadzić do przejęcia kontroli nad callbackiem start. Drugi powoduje wyciek wskaźnika z pamięci sterty na skutek nieprawidłowej obsługi bardzo długiego klucza obiektu JSON i jego skrócenia w polu 16-bitowym ze znakiem. W rezultacie GitLab renderuje ujawnioną wartość w widoku różnic, dając atakującemu prymityw informacyjny potrzebny do ustalenia położenia bibliotek w pamięci procesu.
Praktyczny przebieg ataku jest stosunkowo prosty od strony uprawnień, ale zaawansowany technicznie. Napastnik posiadający możliwość pushowania do projektu dodaje odpowiednio spreparowane notebooki Jupyter, a następnie otwiera ich diff. Kolejne etapy umożliwiają odtworzenie układu pamięci i przygotowanie ładunku, który finalnie kieruje wykonanie do funkcji system(), skutkując uruchomieniem poleceń jako użytkownik git.
Warto zaznaczyć, że publiczny PoC został przygotowany dla konkretnego środowiska referencyjnego, w tym dla GitLab 18.11.3 na architekturze x86-64. Oznacza to, że gotowy kod może wymagać dostosowania do innych wersji, offsetów bibliotek, zachowania alokatora pamięci czy cyklu życia procesów Puma. Sama publikacja znacząco obniża jednak barierę wejścia dla mniej zaawansowanych aktorów zagrożeń.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją jest możliwość zdalnego wykonania poleceń na serwerze aplikacyjnym przez zwykłego uwierzytelnionego użytkownika projektu. W zależności od architektury wdrożenia może to oznaczać dostęp do kodu źródłowego, sekretów aplikacyjnych, poświadczeń usługowych, danych CI/CD oraz systemów wewnętrznych osiągalnych z poziomu procesu GitLab.
Ryzyko rośnie tam, gdzie konto git ma szeroki dostęp do zasobów lokalnych lub sieciowych. Nawet jeśli exploit nie zapewnia od razu uprawnień roota, przejęcie procesu aplikacyjnego w środowisku DevSecOps może stać się punktem wyjścia do ruchu bocznego, kradzieży tokenów, modyfikacji pipeline’ów lub utrwalenia obecności w łańcuchu dostaw oprogramowania.
Dodatkowym wyzwaniem jest wykrywalność. Atak wykorzystuje legalne operacje w repozytorium oraz zwykłe przeglądanie diffów, dlatego początkowo może przypominać standardową aktywność deweloperską. Organizacje, które nie monitorują nietypowych plików .ipynb, anomalii w renderowaniu diffów lub nietypowych procesów potomnych uruchamianych przez komponenty GitLab, mogą opóźnić wykrycie incydentu.
Rekomendacje
Priorytetem powinno być niezwłoczne przejście do wersji naprawczych GitLab: 18.10.8, 18.11.5 albo 19.0.2, zależnie od używanej gałęzi. Organizacje utrzymujące starsze, niewspierane linie wersji powinny zaplanować migrację do obsługiwanych wydań.
Zespoły operacyjne powinny potwierdzić faktyczną wersję działającego komponentu aplikacyjnego, a nie opierać się wyłącznie na wersji chartu Helm lub operatora. W środowiskach kontenerowych kluczowe jest zweryfikowanie obrazu webservice uruchamiającego procesy Puma, ponieważ to tam wykonywana jest podatna ścieżka kodu.
- Ograniczyć uprawnienia i zasięg sieciowy konta
git. - Wdrożyć segmentację sieci między GitLab a systemami wewnętrznymi.
- Przeprowadzić rotację sekretów i tokenów dostępnych dla aplikacji.
- Monitorować procesy potomne uruchamiane przez usługi GitLab.
- Kontrolować nietypowe commity zawierające spreparowane pliki
.ipynb. - Analizować logi pod kątem anomalii związanych z renderowaniem notebook diff.
Jeżeli natychmiastowa aktualizacja nie jest możliwa, środowisko należy traktować jako podwyższonego ryzyka i wdrożyć kontrole kompensacyjne, takie jak ograniczenie możliwości pushowania do mniej zaufanych projektów, wzmożony monitoring telemetryczny oraz przegląd ekspozycji serwera na użytkowników zewnętrznych. Nie zastępuje to jednak pełnej aktualizacji.
Podsumowanie
Publiczny PoC dla GitLab RCE to przykład sytuacji, w której techniczna poprawka szybko przeradza się w problem operacyjny o wysokim priorytecie. Łańcuch ataku łączy błędy pamięci w parserze JSON z funkcją renderowania diffów notebooków Jupyter i pozwala uwierzytelnionemu użytkownikowi wykonać polecenia na serwerze jako git. Dla zespołów bezpieczeństwa oznacza to konieczność pilnej weryfikacji wersji GitLab, przyspieszenia aktualizacji oraz oceny wpływu potencjalnej kompromitacji platformy deweloperskiej na szersze środowisko organizacji.