CVE-2026-85706 w GitLabie jest aktywnie wykorzystywana. Własne instancje trzeba zaktualizować natychmiast

CVE-2026-85706 to luka typu path traversal o maksymalnej ocenie CVSS 3.1: 10.0 w samodzielnie utrzymywanych instalacjach GitLab Community Edition (CE) i Enterprise Edition (EE). W określonych warunkach nieuwierzytelniony użytkownik może dzięki niej odczytywać dowolne pliki dostępne na serwerze GitLab. Nie jest to wyłącznie problem teoretyczny: amerykańska agencja CISA umieściła podatność w katalogu znanych aktywnie wykorzystywanych luk (KEV), a badacze bezpieczeństwa odnotowali skanowanie publicznie dostępnych instancji krótko po publikacji poprawek. 32122

Najpilniejsze działanie: aktualizacja

Jeżeli samodzielnie utrzymywana instancja GitLaba działa w podatnej wersji, należy jak najszybciej przejść na jedną z wersji zawierających poprawkę:

• 19.1.8 lub nowszą,
• 19.2.6 lub nowszą,
• 19.3.2 lub nowszą.

Zagrożone są wersje GitLab CE/EE: od 18.7 do wersji wcześniejszych niż 19.1.8, 19.2 do wersji wcześniejszych niż 19.2.6 oraz 19.3 do wersji wcześniejszych niż 19.3.2. GitLab opublikował poprawki 10 września 2026 r. 37

CISA dodała CVE-2026-85706 do katalogu KEV 11 września, wyznaczając 14 września jako termin działania dla objętych tym wymogiem cywilnych agencji federalnych USA. Termin ten nie nakłada automatycznie obowiązków na firmy prywatne, ale dobrze obrazuje pilność problemu dla każdej samodzielnie zarządzanej instalacji dostępnej z internetu. 3

Na czym polega luka

Błąd występuje w API Repository Commits GitLaba. Zgodnie z opisem przyczyną jest połączenie niewłaściwego ograniczenia ścieżek kontrolowanych przez użytkownika z brakiem wymuszenia uwierzytelnienia. Nieuwierzytelniony podmiot może wykorzystać ten stan do odczytu dowolnych plików, do których dostęp ma usługa GitLab. 3

Jest to przede wszystkim luka prowadząca do ujawnienia plików, a nie potwierdzony samodzielny sposób na zdalne wykonanie kodu. Odczyt dowolnych plików może jednak — zależnie od konfiguracji serwera — ujawnić dane potrzebne do dalszego przejęcia środowiska: ustawienia aplikacji, tokeny, klucze SSH, dane dostępowe do bazy czy inne sekrety czytelne dla procesu GitLab. 925

Dlaczego aktywne wykorzystanie zmienia priorytety

WatchTowr poinformował o obserwacji prób wykorzystania luki w realnych warunkach, w tym o sondowaniach wykrytych 11 września przez jego sieć honeypotów. Wpis CISA w katalogu KEV jest kolejnym istotnym sygnałem: katalog ma wskazywać podatności, dla których istnieją dowody wykorzystania w środowisku produkcyjnym. 222

Publiczne doniesienia potwierdzają skanowanie i aktywność związane z wykorzystaniem luki, ale nie wskazują jednego sprawcy, wiarygodnej liczby poszkodowanych ani uniwersalnego łańcucha działań po włamaniu. Brak znanego raportu o naruszeniu nie powinien być traktowany jako dowód, że wystawiony serwer nie został sprawdzony lub zaatakowany.

Traktuj publicznie dostępne instancje jak możliwe zdarzenia ujawnienia sekretów

Aktualizacja zatrzymuje podatne zachowanie, ale nie cofnie danych, które mogły już zostać odczytane. W przypadku podatnego serwera dostępnego z internetu należy najpierw zabezpieczyć materiał dowodowy i ocenić, do jakich zasobów miał dostęp proces GitLaba, zanim rozpocznie się szeroko zakrojone porządki.

W pierwszej kolejności trzeba przejrzeć i zaplanować rotację poświadczeń, które mogły być dostępne, w tym:

• sekretów aplikacji GitLab i konfiguracji,
• danych dostępowych do bazy danych, Redis, magazynu obiektowego, rejestru, SMTP, usługi katalogowej oraz dostawcy tożsamości zapisanych w konfiguracji,
• zmiennych CI/CD, tokenów wdrożeniowych i dostępowych, tokenów runnerów, kluczy wdrożeniowych oraz poświadczeń montowanych dla zadań lub integracji,
• kluczy chmurowych, danych dostępowych do rejestrów pakietów, kluczy podpisujących oraz prywatnych kluczy SSH i TLS dostępnych dla hosta lub procesu GitLab.

Rotację trzeba przeprowadzić ostrożnie. Zmiana sekretów aplikacji lub ustawień związanych z szyfrowaniem może unieważnić sesje i zakłócić działanie zaszyfrowanych ustawień albo integracji. Najpierw zachowaj istotne logi i dowody konfiguracji, przygotuj procedurę odtworzeniową, a następnie wymieniaj najważniejsze poświadczenia w kontrolowanej kolejności.

Wykrywanie: czego szukać w logach

Przydatnym wstępnym wskaźnikiem jest żądanie HTTP POST do ścieżki Repository Commits API:

/api/v4/projects/<id>/repository/commits/

Raporty zalecają w szczególności szukanie żądań zawierających parametr file.path. W logach reverse proxy, load balancera, WAF-a oraz GitLab Rails należy przeanalizować nietypowe nieuwierzytelnione żądania, zakodowane dane przypominające przejście po ścieżkach, nieoczekiwane identyfikatory projektów, powtarzające się błędy, próby enumeracji i nietypowe rozmiary odpowiedzi. 212426

Warto też zbadać aktywność potencjalnie powiązaną z okresem możliwego ujawnienia: nowo utworzone lub użyte tokeny, rejestracje runnerów, zmienione zmienne CI/CD lub definicje pipeline’ów, nietypowe importy, aktywność GraphQL oraz nieoczekiwane połączenia wychodzące. Wytyczne publikowane wokół wydania zalecają również przegląd commitów, subskrypcji GraphQL, importów projektów i potoków CI/CD. 23

Brak trafień w logach nie jest rozstrzygający. Retencja może być zbyt krótka, logi aplikacyjne mogą nie zawierać niezbędnych szczegółów żądania, a jedynym źródłem śladów mogą być zapisy z proxy lub WAF-a.

Środki tymczasowe, gdy aktualizacja musi poczekać

Wymaganą metodą usunięcia problemu jest aktualizacja. Jeśli awaryjna aktualizacja nie może zostać wykonana od razu, należy ograniczyć dostęp do interfejsu WWW i API GitLaba do VPN-a lub zatwierdzonych sieci. Reguła reverse proxy albo WAF-a, która ściśle ogranicza podatną trasę Repository Commits API, może krótkoterminowo zmniejszyć ryzyko, lecz może także zepsuć prawidłową automatyzację. Nie zastępuje aktualizacji.

Praktyczna sekwencja działań dla każdego podatnego serwera:

1. Zidentyfikuj i uszereguj według priorytetu samodzielnie utrzymywane instancje dostępne z zewnątrz.
2. Zaktualizuj system do wersji 19.1.8, 19.2.6, 19.3.2 lub nowszej.
3. Zweryfikuj uruchomioną wersję po wdrożeniu zmiany.
4. Zabezpiecz i przeanalizuj logi pod kątem wskaźników wykorzystania luki.
5. Wymień potencjalnie ujawnione sekrety, uwzględniając uprawnienia serwera i wpływ na działalność.

Inne luki naprawione w tym wydaniu

W tym samym pakiecie poprawek opisano także dwa problemy dotyczące Enterprise Edition:

• CVE-2026-87719 to zgłaszana jako wymagająca uwierzytelnienia luka niebezpiecznej deserializacji, z oceną CVSS 9.9; według części raportów wiąże się z ujawnieniem konfiguracji i poświadczeń Advanced Search. 6
• CVE-2026-88765 to zgłaszane ryzyko zdalnego wykonania kodu po uwierzytelnieniu, związane z importem spreparowanego eksportu projektu Git; raportowana ocena CVSS wynosi 8.5. 625

Obie luki mają inne warunki wykorzystania i skutki niż CVE-2026-85706. Dla dostępnych z internetu, samodzielnie utrzymywanych instalacji GitLaba to właśnie nieuwierzytelniona i aktywnie wykorzystywana luka umożliwiająca odczyt plików powinna być pierwszym priorytetem działań ograniczających skutki incydentu.