Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
GitLab mierzy się z poważnym zagrożeniem bezpieczeństwa związanym z łańcuchem podatności prowadzącym do zdalnego wykonania kodu (RCE) w środowiskach self-managed. Problem dotyczy obsługi różnic dla plików Jupyter Notebook oraz sposobu, w jaki aplikacja wykorzystuje bibliotekę Oj, czyli natywny parser JSON dla Ruby.
W praktyce oznacza to, że uwierzytelniony użytkownik posiadający możliwość wysyłania zmian do projektu może doprowadzić do wykonania poleceń na serwerze GitLab. Scenariusz nie wymaga uprawnień administracyjnych ani interakcji ze strony ofiary, co znacząco podnosi poziom ryzyka.
W skrócie
Ujawniony mechanizm ataku łączy dwa błędy w parserze Oj w skuteczny łańcuch eksploatacji RCE. Wektor prowadzi przez renderowanie diffów dla plików .ipynb, czyli notebooków Jupyter, które są przetwarzane przez podatną ścieżkę aplikacji.
- Zagrożone są wybrane wersje GitLab CE i EE.
- Atakujący potrzebuje konta z prawem do pushowania zmian.
- Wystarczy doprowadzić do przetworzenia diffu commita przez aplikację.
- Poprawki opublikowano w wersjach 18.10.8, 18.11.5 oraz 19.0.2.
Kontekst / historia
Publiczny opis działającego exploita pojawił się 24 lipca 2026 roku, jednak sama poprawka była dostępna wcześniej, bo już 10 czerwca 2026 roku w ramach wydań patch release GitLab. To istotny szczegół, ponieważ naprawa nie została szeroko wyeksponowana jako krytyczna luka bezpieczeństwa, lecz pojawiła się wśród standardowych poprawek.
Taki sposób komunikacji mógł sprawić, że część administratorów nie nadała aktualizacji odpowiedniego priorytetu. Jest to ważna lekcja operacyjna: nie każda krytyczna poprawka bezpieczeństwa musi zostać jednoznacznie opisana jako luka wysokiego ryzyka już w chwili publikacji.
Według dostępnych informacji podatna ścieżka obsługi notebooków występuje w GitLab od wersji 15.2.0. Starsze wydania wcześniejsze niż 15.2 nie korzystały w tym miejscu z tej samej logiki parsowania JSON, dlatego nie podlegają temu konkretnemu scenariuszowi ataku. Jednocześnie wiele starszych instalacji działających poza wspieranymi gałęziami nie otrzyma poprawek wstecznych.
Analiza techniczna
Atak rozpoczyna się podczas renderowania diffów dla plików notebooków Jupyter. Gdy użytkownik otwiera różnice dla pliku .ipynb, GitLab przekazuje surową zawartość JSON do parsera Oj::Parser.usual.parse działającego w procesie Puma. To właśnie ten punkt wejścia umożliwia wykorzystanie błędów pamięci w natywnej bibliotece.
Pierwszy element łańcucha dotyczy przepełnienia stosu zagnieżdżeń parsera. Odpowiednio spreparowany dokument JSON o nadmiernej głębokości może doprowadzić do zapisu poza przewidzianym obszarem pamięci. W efekcie możliwe staje się uszkodzenie sąsiednich struktur parsera i manipulacja jego stanem wewnętrznym.
Drugi element odpowiada za ujawnienie informacji z pamięci procesu. W tym wariancie atak wykorzystuje zbyt duży klucz obiektu JSON, którego długość jest nieprawidłowo obsługiwana podczas konwersji typów. Błąd umożliwia częściowy wyciek danych z pamięci sterty, co może pomóc w obejściu mechanizmów ochronnych i ustabilizowaniu exploita.
Kluczowe znaczenie ma także fakt, że Oj::Parser.usual działa jako współdzielony singleton w obrębie procesu Puma. Oznacza to, że jednorazowe uszkodzenie stanu parsera może wpływać na kolejne operacje wykonywane przez ten sam worker. W opisywanym scenariuszu dwa odpowiednio przygotowane notebooki w jednym commicie pozwalają najpierw zmodyfikować stan parsera, a następnie przejąć kontrolę nad dalszym wykonaniem kodu.
Jeśli eksploatacja powiedzie się, polecenia wykonywane są z uprawnieniami użytkownika git, pod którym pracują procesy Puma. To może oznaczać dostęp do kodu źródłowego, sekretów aplikacyjnych, poświadczeń usługowych oraz innych zasobów osiągalnych z poziomu serwera GitLab.
Konsekwencje / ryzyko
Ryzyko należy uznać za bardzo wysokie. Atak nie wymaga uprawnień administratora, nie wymaga uruchomienia pipeline’u CI i nie potrzebuje dodatkowej interakcji poza samym przetworzeniem diffu przez aplikację.
W praktyce konsekwencje mogą obejmować:
- kradzież kodu źródłowego,
- wyciek sekretów i poświadczeń,
- modyfikację repozytoriów,
- utrwalenie obecności w środowisku,
- ruch boczny do innych systemów wewnętrznych.
Szczególnie narażone są organizacje, w których GitLab działa w środowisku o słabej separacji, a konto aplikacyjne ma szeroki dostęp do usług pomocniczych, magazynów sekretów lub infrastruktury wewnętrznej. Problem zwiększa także ryzyko ze strony przejętych kont deweloperskich i zagrożeń wewnętrznych.
Rekomendacje
Najważniejszym działaniem jest natychmiastowa aktualizacja GitLab do wersji 18.10.8, 18.11.5 albo 19.0.2. Środowiska pozostające na niewspieranych gałęziach powinny zostać przeniesione do aktualnie obsługiwanej linii wydawniczej, ponieważ nie należy zakładać dostępności poprawek dla wszystkich historycznych wersji.
W środowiskach opartych o Helm lub Operator należy zweryfikować nie tylko wersję chartu, ale także rzeczywistą wersję obrazu Webservice obsługującego Puma. To właśnie ten komponent decyduje o obecności podatnego parsera w ścieżce wykonania.
- Ograniczyć możliwość pushowania zmian wyłącznie do zaufanych użytkowników.
- Monitorować nietypowe operacje związane z diffami plików
.ipynb. - Przeanalizować logi aplikacyjne i systemowe pod kątem anomalii w procesach Puma.
- Zweryfikować, jakie sekrety i poświadczenia są dostępne dla użytkownika
git. - Wzmocnić segmentację sieciową między GitLab a usługami wewnętrznymi.
- Stosować zasadę najmniejszych uprawnień dla kont aplikacyjnych i usług towarzyszących.
- Traktować każde patch release również jako potencjalną poprawkę bezpieczeństwa.
Jeżeli istnieje podejrzenie kompromitacji, incydent należy potraktować jak potencjalne wykonanie kodu po stronie serwera. W takim przypadku konieczne są rotacja sekretów, przegląd repozytoriów pod kątem nieautoryzowanych zmian, analiza artefaktów trwałości oraz inspekcja połączeń wychodzących z hostów GitLab.
Podsumowanie
Opisany łańcuch RCE w GitLab pokazuje, jak groźne mogą być błędy pamięci w natywnych zależnościach wykorzystywanych przez aplikacje webowe. Połączenie usterek w parserze JSON z realną ścieżką biznesową, jaką jest podgląd diffów notebooków Jupyter, stworzyło warunki do skutecznego ataku z poziomu uwierzytelnionego użytkownika.
Dla administratorów i zespołów bezpieczeństwa to wyraźny sygnał, że nawet pozornie zwykłe poprawki błędów mogą zamykać krytyczne luki. Priorytetem powinno być szybkie wdrożenie aktualizacji, przegląd modelu uprawnień oraz poprawa izolacji środowiska GitLab.
Źródła
- Security Affairs – GitLab Users Urged to Patch After Research Reveals Critical RCE Chain
https://securityaffairs.com/196062/hacking/gitlab-users-urged-to-patch-after-research-reveals-critical-rce-chain.html - GitLab Docs – GitLab Patch Release: 19.0.2, 18.11.5, 18.10.8
https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-0-2-released/ - Depthfirst – Going depthfirst: Achieving GitLab RCE via Two Ruby Memory Corruption Vulnerabilities
https://depthfirst.com/ - GitLab Blog – Patch Releases articles
https://about.gitlab.com/blog/tags/patch-releases/