Jeden Publiczny Projekt To Jedyny Warunek
CVE-2026-85706 niemal niczego nie wymaga od atakującego, by zadziałać. Luka tkwi w API commitów repozytoriów GitLaba, gdzie niewłaściwe ograniczenie ścieżek i brak kontroli uwierzytelniania pozwalają niezalogowanemu użytkownikowi wysłać żądanie z parametrem ścieżki pliku i odczytać dowolne pliki z serwera, bez żadnego logowania. Jake Knott z watchTowr ujął próg wejścia w jednym zdaniu: do wykorzystania wystarczy spełnić jeden warunek, musi istnieć co najmniej jeden publiczny projekt. Większość samodzielnie zarządzanych instancji GitLaba ma co najmniej jeden, niezależnie od tego, czy właściciel traktuje go jako publicznie dostępny, czy nie.
Luka ma ocenę CVSS na poziomie 10.0, maksimum dopuszczalne przez skalę, i dotyczy GitLab Community oraz Enterprise Edition w wersjach od 18.7 do 19.1.7, od 19.2 do 19.2.5 oraz od 19.3 do 19.3.1. Serwer wystawiony w ten sposób nie ujawnia jedynie kodu źródłowego. API commitów znajduje się wystarczająco blisko plików konfiguracyjnych, definicji pipeline'ów CI/CD i tokenów wdrożeniowych, by udany odczyt dał atakującemu dane uwierzytelniające pozwalające posunąć się dalej w głąb wszystkiego, co dana instancja GitLaba buduje i wdraża.
Łatka Istniała, Zanim Powstał Termin
| Data | Wydarzenie |
|---|---|
| 10 września | GitLab wydaje poprawkę w wersjach 19.1.8, 19.2.6 i 19.3.2 |
| 11 września, 06:00 UTC | Sieć honeypotów watchTowr wykrywa pierwsze próby w sieci |
| 11 września | CISA dodaje CVE-2026-85706 do swojego katalogu znanych wykorzystywanych podatności |
| 14 września | Termin dla amerykańskich cywilnych agencji federalnych na wdrożenie poprawki |
Między wydaniem poprawki a pierwszymi próbami trafiającymi w honeypoty watchTowr minęło mniej niż 24 godziny. Własny wpis CISA w katalogu pojawił się zaledwie kilka godzin później. Według oceny watchTowr atakujący zdążyli już poddać inżynierii wstecznej i odtworzyć podatność na podstawie samej łatki, ten sam schemat, który zamienia ujawnienie w wyścig w chwili, gdy staje się publiczne. Termin CISA wiąże wyłącznie amerykańskie cywilne agencje federalne, a nie firmę w Monachium czy Manchesterze, ale sam przebieg wykorzystania, na który on reaguje, nie zatrzymuje się na tej granicy.
Trzecia Luka, Którą Servola Śledzi Od Sierpnia
To nie pierwsza krytyczna luka w GitLabie tego lata, to trzecia aktywnie wykorzystywana w ciągu mniej więcej czterech tygodni. Servola opisała lukę w GitLabie powiązaną z krytycznymi błędami w Ray i oprogramowaniu Apple 18 sierpnia, a następnie lukę wstrzykiwania kodu GraphQL w samym GitLabie, CVE-2026-19478, 24 sierpnia, błąd, który własne doniesienia TheHackerNews na temat tej nowej luki wprost łączą jako wcześniejszy przypadek wykorzystania krótko po ujawnieniu. Trzy krytyczne CVE wymierzone w jedną szeroko samodzielnie hostowaną platformę w ciągu miesiąca to nie zbieg okoliczności, który można zbyć pechem. To sygnał, że powierzchnia ataku GitLaba oraz tempo, w jakim badacze i atakujący poddają dziś łatkę inżynierii wstecznej, wyprzedziły to, jak często większość właścicieli samodzielnie zarządzanych instancji w ogóle sprawdza, czy poprawka się pojawiła.
Żadna z tych trzech luk nie ma wspólnej przyczyny źródłowej. Wspólne jest im natomiast krótkie okno czasowe, każda została wykorzystana lub przetestowana w ciągu kilku dni od wydania poprawki, nie tygodni. Właściciel sprawdzający aktualizacje GitLaba raz w miesiącu przegapiłby bezpieczne okno we wszystkich trzech przypadkach.
Co Się Zmienia Dla Firmy Korzystającej Z Samodzielnie Hostowanego GitLaba
Konkretny krok jest niewielki: potwierdzić, że instancja działa na wersji 19.1.8, 19.2.6 lub 19.3.2 albo nowszej, a następnie sprawdzić logi dostępu pod kątem żądań POST do endpointu commitów repozytorium z parametrem ścieżki pliku, wskaźnika, którego szukania zaleca watchTowr. Większy krok to ten, który naprawdę zapobiega powtórce. Dyrektywa NIS2 już teraz wymaga od organizacji w UE wykazania, że potrafią zweryfikować, iż poprawka dotarła do każdego zarządzanego systemu, a nie tylko że GitLab ją opublikował. Samodzielnie hostowana instancja, w której nikt nie jest wyznaczony do obserwowania katalogu KEV CISA ani własnych biuletynów bezpieczeństwa GitLaba w czasie rzeczywistym, wciąż będzie odkrywać krytyczne luki z artykułu prasowego, a nie z alertu monitoringu, dokładnie tego rodzaju rygoru, jakiego oczekiwałby europejski regulator.
Firma, która traktuje każdy taki przypadek jak odosobnione ćwiczenie przeciwpożarowe, poradzi sobie dobrze z tym jednym, a kolejny przegapi w tym samym tempie. Firma, która wyznacza kogoś odpowiedzialnego za tempo łatania GitLaba tak samo, jak za swoje reguły zapory sieciowej, przestaje być trzy na trzy w spóźnionym wykrywaniu.
Czytaj dalej: Wykorzystane Tygodnie Przed Łatą PaperCut | Krytyczny błąd GitLab uderzył self-hosted, nie SaaS
