GitLab łata krytyczne luki, ataki już trwają

GitLab pod presją po ujawnieniu luk

GitLab wydał awaryjne poprawki dla dwóch poważnych podatności w swojej platformie do tworzenia oprogramowania. Jedna z nich ma maksymalną ocenę 10.0 w skali CVSS i pozwala nieautoryzowanemu atakującemu odczytać dowolne pliki z serwera. Druga, dotycząca wyłącznie edycji Enterprise, może ujawnić poufne informacje użytkownikowi, który ma dostęp do wybranych funkcji systemu.

Co ważne, próby wykorzystania pierwszej luki pojawiły się w sieci bardzo szybko po publikacji informacji o błędzie.

Najgroźniejsza luka: odczyt plików bez logowania

Podatność śledzona jako CVE-2026-85706 dotyczy interfejsu API obsługującego commity w repozytoriach. Problem polega na tym, że mechanizm nie ograniczał poprawnie ścieżek do plików i nie wymuszał uwierzytelnienia w wymagany sposób.

W praktyce oznacza to, że atakujący bez konta i bez hasła mógł w pewnych warunkach doprowadzić do odczytu dowolnych plików znajdujących się na serwerze GitLab. Zagrożenie obejmuje:

• wykradanie plików dziennika,
• dostęp do plików konfiguracyjnych,
• pozyskanie haseł, sekretów i innych wrażliwych danych,
• potencjalny wgląd w kod źródłowy oraz elementy używane w procesach CI/CD.

Luka dotyczy wydań od 18.7 do 19.1.8, a także gałęzi 19.2 i 19.3 sprzed wydania poprawek.

Druga podatność: wyciek informacji w Enterprise Edition

GitLab załatał też błąd oznaczony jako CVE-2026-87719, przypisany do wersji Enterprise Edition. Ta luka ma ocenę CVSS 9.9 i dotyczy użytkownika zalogowanego, który ma dostęp do funkcji Duo Chat.

W określonych warunkach można było przygotować specjalnie spreparowane żądanie, które prowadziło do obejścia mechanizmu serializacji i odczytu konfiguracji związanej z funkcją Advanced Search. Efektem mógł być wyciek ustawień i poufnych poświadczeń przechowywanych przez system.

Podatność obejmuje wydania od 18.3 wzwyż.

Ataki ruszyły niemal od razu

W sieci zaczęły się pojawiać próby skanowania i sprawdzania podatności praktycznie od razu po ujawnieniu problemu. Badacze bezpieczeństwa zwracają uwagę, że tego typu luki w GitLabie są szczególnie atrakcyjne dla napastników, ponieważ dają dostęp do zasobów o wysokiej wartości:

• kodu źródłowego,
• sekretów CI/CD,
• danych uwierzytelniających,
• konfiguracji środowiska,
• a pośrednio także do dalszych etapów ataku na łańcuch dostaw.

Największe ryzyko dotyczy samodzielnie utrzymywanych instancji GitLaba dostępnych z internetu. W przypadku usług hostowanych przez GitLab poprawki zostały już wdrożone, a instancje Dedicated nie są objęte problemem.

Co powinni zrobić administratorzy

Organizacje korzystające z własnych wdrożeń powinny jak najszybciej zainstalować poprawki. Jeśli publiczny dostęp do instancji nie jest konieczny, warto go ograniczyć do czasu aktualizacji.

W logach należy szukać podejrzanych żądań HTTP POST kierowanych do ścieżek podobnych do:

• /api/v4/projects/{id}/repository/commits/

Sygnałem ostrzegawczym mogą być także żądania zawierające parametr:

• file.path

Taki wzorzec może wskazywać na próbę wykorzystania podatności związanej z przechodzeniem po ścieżkach.

Presja czasu jest duża

Historia wcześniejszych luk w GitLabie pokazuje, że po publikacji łatki często bardzo szybko pojawiają się szerokie, nieselektywne ataki. Dlatego administratorzy nie powinni odkładać aktualizacji na później.

W tym przypadku okno reakcji jest wyjątkowo krótkie, a konsekwencje potencjalnego kompromitowania instancji mogą sięgać daleko poza sam GitLab.