CVE-2026-85706 w GitLab: odczyt plików bez logowania i pilna aktualizacja

GitLab opublikował krytyczną poprawkę dla CVE-2026-85706 — błędu typu path traversal w API commitów repozytorium. W określonych warunkach niezalogowany użytkownik mógł odczytać dowolne pliki z serwera GitLab. Podatność otrzymała maksymalną ocenę CVSS 10.0, a 11 września CISA dodała ją do katalogu Known Exploited Vulnerabilities.

To nie jest luka, którą warto zostawić na najbliższe zwykłe okno aktualizacyjne. GitLab zaleca natychmiastową aktualizację każdej podatnej instalacji self-managed. GitLab.com działa już na poprawionej wersji, a klienci GitLab Dedicated nie muszą wykonywać dodatkowych działań.

Które wersje GitLab są podatne

Według biuletynu GitLab problem dotyczy Community Edition i Enterprise Edition w następujących zakresach:

• od 18.7 do wydań wcześniejszych niż 19.1.8;
• linia 19.2 przed 19.2.6;
• linia 19.3 przed 19.3.2.

Wersjami naprawczymi są 19.1.8, 19.2.6 i 19.3.2. Jeżeli organizacja korzysta z jeszcze starszej lub niewspieranej gałęzi, bezpieczną decyzją nie jest zakładanie, że „nie ma jej na liście”, tylko przejście na aktualnie wspierane, poprawione wydanie zgodnie ze ścieżką producenta.

GitLab zaznacza, że jeśli przy konkretnej luce nie wskazano rodzaju instalacji, podatne są wszystkie formy wdrożenia produktu. Inwentaryzacja powinna więc objąć pakiety Linux, kontenery, Helm chart, instalacje ze źródeł oraz węzły pomocnicze, które mogą nadal uruchamiać starą wersję.

Dlaczego odczyt plików jest tak niebezpieczny

Path traversal pojawia się, gdy aplikacja przyjmuje fragment ścieżki od użytkownika, lecz nie zamyka go skutecznie w dozwolonym katalogu. Sekwencje prowadzące do katalogu nadrzędnego lub ich zakodowane warianty mogą sprawić, że operacja przeznaczona dla pliku repozytorium sięgnie gdzie indziej w systemie.

GitLab podaje dwa elementy problemu: niewłaściwe ograniczenie ścieżki i brak egzekwowania uwierzytelnienia w API commitów. Wektor CVSS oznacza atak sieciowy o niskiej złożoności, bez konta i bez działania użytkownika. Sam opis luki mówi o odczycie, a nie o bezpośrednim zapisie plików czy wykonaniu kodu.

Konsekwencje mogą jednak wykraczać poza treść jednego pliku. Serwer DevSecOps przechowuje konfigurację, informacje o integracjach i dane potrzebne wielu automatyzacjom. Jeżeli odczytany plik zawiera sekret, klucz albo dane połączenia, napastnik może próbować wykorzystać je w kolejnym kroku. To wniosek z modelu zagrożenia Breachroad, a nie stwierdzenie GitLab, że każdy atak prowadzi do przejęcia całej instancji.

CISA potwierdza realne wykorzystanie

11 września 2026 CISA dodała CVE-2026-85706 do katalogu KEV, który obejmuje luki z dowodami wykorzystania w rzeczywistych atakach. Dla amerykańskich cywilnych instytucji federalnych wskazano termin działania 14 września oraz wymóg triage’u śledczego wynikający z BOD 26-04.

Termin CISA nie jest polskim obowiązkiem prawnym. Jest jednak mocnym sygnałem priorytetu dla każdej organizacji posiadającej GitLab dostępny z internetu. Maksymalny wynik CVSS opisuje cechy podatności, a obecność w KEV odpowiada na inne pytanie: czy ktoś faktycznie jej używa. Tutaj oba sygnały wskazują ten sam kierunek.

Plan działania na dziś

Najpierw ustal właściciela każdej instancji i sprawdź jej dokładną wersję. Nie ograniczaj się do głównego adresu GitLab. Uwzględnij środowiska testowe, zapasowe, starsze instancje po migracji, węzły Geo i systemy udostępnione partnerom.

Następnie:

1. wykonaj aktualizację do 19.3.2, 19.2.6, 19.1.8 albo nowszego wspieranego wydania;
2. potwierdź wersję na każdym węźle po zakończeniu zmiany;
3. sprawdź, czy publiczny reverse proxy, WAF lub reguła routingu nie prowadzi nadal do starego węzła;
4. zachowaj logi z okresu ekspozycji przed ich rotacją;
5. rozpocznij analizę, jeśli instancja była osiągalna z niezaufanej sieci.

Nie traktuj ukrycia adresu logowania, ograniczenia rejestracji użytkowników ani wymuszenia SSO jako zamiennika poprawki. Opisana ścieżka nie wymaga zalogowanego konta.

Aktualizacja może wymagać zaplanowanego przestoju

Biuletyn GitLab informuje, że patch zawiera migracje bazy danych. W instalacji jednowęzłowej aktualizacja spowoduje przerwę, ponieważ migracje muszą zakończyć się przed uruchomieniem GitLab. W środowisku wielowęzłowym producent przewiduje możliwość użycia procedury aktualizacji bez przestoju.

To ważne operacyjnie, ale nie powinno stać się pretekstem do wielodniowego odkładania zmiany. Właściciel usługi powinien jasno zakomunikować ryzyko, uzgodnić krótkie okno i przygotować plan powrotu zgodny z dokumentacją. Kopia zapasowa jest elementem bezpiecznej aktualizacji, nie kompensacją dla pozostawienia podatnej instancji online.

Jak podejść do triage’u po załataniu

Publiczny opis nie daje uniwersalnego ciągu znaków, który jednoznacznie identyfikuje każdy atak. Nie buduj więc pewności wyłącznie na braku jednego IOC. Zachowaj i przeanalizuj logi reverse proxy, aplikacji GitLab, systemu operacyjnego, WAF oraz dostawcy tożsamości.

Szukaj nietypowych żądań do API commitów, wariantów kodowania ścieżek, serii odpowiedzi o różnych rozmiarach oraz aktywności z tych samych źródeł przed i po potencjalnym odczycie. Porównaj zdarzenia z normalnym ruchem integracji i botów, aby nie uznać zwykłej automatyzacji za włamanie.

Jeżeli nie da się wykluczyć dostępu do plików zawierających sekrety, rotuj je według wpływu: poświadczenia administratorów i tokeny o szerokim zakresie, klucze integracji, dane runnerów, klucze wdrożeniowe oraz sekrety prowadzące do chmury. Sama aktualizacja zamyka wejście, ale nie unieważnia informacji skopiowanych wcześniej.

Sprawdź również nowe konta, tokeny, klucze SSH, hooki, integracje i zmiany konfiguracji. Odczyt pliku nie tworzy ich automatycznie; kontrola służy wykryciu ewentualnego dalszego użycia pozyskanych danych.

Czego nie wiemy

GitLab opisuje podatność zwięźle i zapowiada ujawnienie szczegółów zgłoszenia po 90 dniach. Publiczne źródła użyte w tym artykule nie określają skali ataków, branż ofiar ani kompletnego zestawu artefaktów śledczych. Katalog KEV potwierdza wykorzystanie, ale nie oznacza, że każda publiczna instancja została naruszona.

Dlatego właściwa kolejność brzmi: popraw, zachowaj dane, zbadaj, a następnie podejmij decyzję o rotacji i odbudowie na podstawie ekspozycji oraz dowodów. Czekanie na pełny raport techniczny zwiększa okres ryzyka.

Fakty źródłowe i wnioski Breachroad

Zakres wersji, CVSS 10.0, brak wymagania konta, możliwość odczytu dowolnych plików, wersje naprawcze i uwagi o migracjach pochodzą z krytycznego wydania GitLab 19.3.2, 19.2.6 i 19.1.8. Informacja o rzeczywistej eksploatacji, dacie dodania i wymaganym triage’u pochodzi z katalogu CISA KEV.

Wskazówki dotyczące kolejności rotacji sekretów, korelacji logów i sprawdzania dalszej aktywności są rekomendacjami Breachroad. Nie przedstawiamy ich jako oficjalnych IOC GitLab.

Poprzedni przykład błędu w tej platformie opisujemy w artykule CVE-2026-10053 w GitLab Package Registry. Zespołom technicznym pomagamy budować wspólny język ryzyka i reakcji podczas szkoleń z cyberbezpieczeństwa, a zakres publicznej instancji można dodatkowo ocenić w ramach testów penetracyjnych web i API.